Intégrité de la chaîne d'approvisionnement
Les contrôles de chaîne d’approvisionnement de NextPDF s’exercent en deux points : des contrôles CI exécutés sur chaque pull request modifiant les dépendances et sur chaque tag de version, et le workflow de release, qui configure la génération de provenance, la signature keyless et l’émission de SBOM.
| Contrôle | Type |
|---|---|
SBOM CycloneDX 1.7 du build | Contrôle CI, bloquant |
| Déclaration in-toto engageant les entrées du build | Contrôle CI, bloquant |
| Comparaison des empreintes SHA-256 des dépendances à une référence épinglée | Contrôle CI, bloquant |
| Vérification de cohérence OpenVEX par rapport à la politique d’avis de sécurité des dépendances | Contrôle CI, bloquant |
| Vérification de déterminisme inter-fixtures | Vérification CI, best effort |
Génération de provenance via slsa-github-generator épinglé | Configuration de workflow — workflow de release |
Signature keyless Sigstore cosign avec journalisation de transparence Rekor | Configuration de workflow — workflow de release |
Émission de SBOM CycloneDX 1.7 et SPDX 2.3 | Configuration de workflow — workflow de release |
Matrice php-fuzzer nocturne sur les chemins d’analyse et d’écriture | CI planifiée |
Contrôles CI
Section intitulée « Contrôles CI »Chaque pull request touchant aux dépendances et chaque tag de version exécutent :
| Vérification | Ce qu’elle fait | Contrôle |
|---|---|---|
| Inventaire | Émet un SBOM CycloneDX 1.7 du build | Bloquant |
| Enregistrement des entrées de build | Émet une déclaration in-toto engageant les entrées du build | Bloquant |
| Intégrité des dépendances | Compare les empreintes SHA-256 des octets à une référence épinglée | Bloquant |
| Cohérence VEX | Exige que chaque entrée de la politique d’avis de sécurité des dépendances ait une déclaration correspondante dans le document OpenVEX v0.2.0 du dépôt | Bloquant |
| Reproductibilité | Exécute une vérification de déterminisme sur les fixtures | Best effort |
Le contrôle d’intégrité des dépendances compare les empreintes SHA-256 des octets de l’arbre de dépendances à une référence épinglée dans le dépôt, indépendamment des métadonnées des paquets.
Configuration du workflow de release
Section intitulée « Configuration du workflow de release »Provenance — configuration du workflow
Section intitulée « Provenance — configuration du workflow »Le workflow de release épingle le workflow réutilisable canonique
slsa-github-generator, configuré pour générer la provenance in-toto dans un
builder isolé et éphémère, et configure slsa-verifier pour vérifier, au sein
du même workflow, la sortie du générateur.
Signature et transparence — configuration du workflow
Section intitulée « Signature et transparence — configuration du workflow »Le workflow de release configure la signature keyless Sigstore cosign du lot
d’artefacts, avec journalisation de transparence dans Rekor. La signature
keyless dérive un certificat de courte durée de l’identité OIDC du workflow
(https://token.actions.githubusercontent.com) ; ce chemin de signature de
release est donc configuré sans clé de signature d’artefacts de longue durée.
SBOM — configuration du workflow
Section intitulée « SBOM — configuration du workflow »Le workflow de release configure l’émission de SBOM au double format — un
document CycloneDX 1.7 et un document SPDX 2.3.
Une matrice php-fuzzer nocturne, associée à un harnais AST/arbre de
structure, exerce les chemins d’analyse et d’écriture.