cli.github.com<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nVous avez \u00e9galement besoin d’un compte GitHub<\/strong> avec acc\u00e8s au GitHub Container Registry (GHCR), et d’une application de base avec un Dockerfile<\/code>.<\/p>\nConfiguration de l’environnement<\/h2>\n
Nous allons cr\u00e9er une application Node.js minimale, la conteneuriser et la pousser vers GHCR. Cette image devient la cible de tous les exercices SBOM suivants.<\/p>\n
\u00c9tape 1 : Cr\u00e9er le d\u00e9p\u00f4t de test<\/h3>\nmkdir sbom-pipeline-lab && cd sbom-pipeline-lab\ngit init\n<\/code><\/pre>\n\u00c9tape 2 : Cr\u00e9er une application Node.js simple<\/h3>\ncat > package.json <<'EOF'\n{\n \"name\": \"sbom-lab-app\",\n \"version\": \"1.0.0\",\n \"description\": \"SBOM pipeline lab application\",\n \"main\": \"server.js\",\n \"dependencies\": {\n \"express\": \"^4.18.2\",\n \"lodash\": \"^4.17.21\",\n \"axios\": \"^1.6.0\"\n }\n}\nEOF\n<\/code><\/pre>\ncat > server.js <<'EOF'\nconst express = require('express');\nconst app = express();\n\napp.get('\/', (req, res) => {\n res.json({ status: 'ok', message: 'SBOM Pipeline Lab' });\n});\n\napp.listen(3000, () => console.log('Listening on port 3000'));\nEOF\n<\/code><\/pre>\n\u00c9tape 3 : Cr\u00e9er le Dockerfile<\/h3>\nFROM node:20-alpine\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm install --production\nCOPY . .\nEXPOSE 3000\nCMD [\"node\", \"server.js\"]\n<\/code><\/pre>\n\u00c9tape 4 : Construire et pousser l’image de conteneur<\/h3>\n# S'authentifier aupr\u00e8s de GHCR\necho $GITHUB_TOKEN | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin\n\n# Construire l'image\ndocker build -t ghcr.io\/YOUR_GITHUB_USERNAME\/sbom-lab-app:v1.0.0 .\n\n# Pousser vers GHCR\ndocker push ghcr.io\/YOUR_GITHUB_USERNAME\/sbom-lab-app:v1.0.0\n<\/code><\/pre>\nRemplacez YOUR_GITHUB_USERNAME<\/code> par votre nom d’utilisateur GitHub r\u00e9el tout au long de ce lab. Une fois le push termin\u00e9, notez le digest complet de l’image \u2014 vous en aurez besoin pour les op\u00e9rations de signature.<\/p>\n# Capturer le digest de l'image\nexport IMAGE=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io\/YOUR_GITHUB_USERNAME\/sbom-lab-app:v1.0.0)\necho $IMAGE\n# Sortie : ghcr.io\/YOUR_GITHUB_USERNAME\/sbom-lab-app@sha256:abc123...\n<\/code><\/pre>\nExercice 1 : G\u00e9n\u00e9rer un SBOM avec Syft<\/h2>\n
Syft est un outil open-source d’Anchore qui g\u00e9n\u00e8re des SBOMs en analysant les images de conteneurs, les syst\u00e8mes de fichiers et les archives. Il prend en charge plusieurs formats de sortie, notamment SPDX et CycloneDX \u2014 les deux standards SBOM dominants.<\/p>\n
G\u00e9n\u00e9rer un SBOM SPDX<\/h3>\nsyft $IMAGE -o spdx-json=sbom.spdx.json\n<\/code><\/pre>\nInspecter la sortie :<\/p>\n
cat sbom.spdx.json | jq '.packages | length'\n# Sortie : 287 (le nombre varie selon le contenu de l'image)\n\n# Afficher les paquets d\u00e9tect\u00e9s\ncat sbom.spdx.json | jq '.packages[] | {name: .name, version: .versionInfo, license: .licenseDeclared}' | head -40\n<\/code><\/pre>\nG\u00e9n\u00e9rer un SBOM CycloneDX<\/h3>\nsyft $IMAGE -o cyclonedx-json=sbom.cyclonedx.json\n<\/code><\/pre>\nInspecter la sortie CycloneDX :<\/p>\n
cat sbom.cyclonedx.json | jq '.components | length'\n\n# Afficher les composants avec les licences\ncat sbom.cyclonedx.json | jq '.components[] | {name: .name, version: .version, type: .type}' | head -40\n<\/code><\/pre>\nSPDX vs. CycloneDX : Diff\u00e9rences cl\u00e9s<\/h3>\n
\n\n\n| Caract\u00e9ristique<\/th>\n | SPDX<\/th>\n | CycloneDX<\/th>\n<\/tr>\n<\/thead>\n |
\n\nOrigine<\/strong><\/td>\n| Linux Foundation<\/td>\n | OWASP<\/td>\n<\/tr>\n | \nFocus principal<\/strong><\/td>\n| Conformit\u00e9 des licences et PI<\/td>\n | S\u00e9curit\u00e9 et analyse des risques<\/td>\n<\/tr>\n | \nNorme ISO<\/strong><\/td>\n| ISO\/IEC 5962:2021<\/td>\n | ECMA-424<\/td>\n<\/tr>\n | \nDonn\u00e9es de vuln\u00e9rabilit\u00e9<\/strong><\/td>\n| Support natif limit\u00e9<\/td>\n | Champ vulnerabilities<\/code> de premier ordre<\/td>\n<\/tr>\n\nFormats<\/strong><\/td>\n| JSON, RDF, XML, YAML, tag-value<\/td>\n | JSON, XML, Protobuf<\/td>\n<\/tr>\n | \nId\u00e9al pour<\/strong><\/td>\n| Conformit\u00e9 r\u00e9glementaire, audits de licences<\/td>\n | DevSecOps, suivi des vuln\u00e9rabilit\u00e9s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Pour ce lab, nous utilisons principalement SPDX JSON car c’est le format requis par de nombreuses normes d’approvisionnement gouvernementales et il s’associe bien avec les attestations Cosign. Cependant, les deux formats sont pris en charge par Grype et Cosign.<\/p>\n G\u00e9n\u00e9rer un r\u00e9sum\u00e9 lisible<\/h3>\nsyft $IMAGE -o syft-table\n<\/code><\/pre>\nCela affiche un tableau de tous les paquets avec le nom, la version et le type \u2014 utile pour une revue rapide pendant le d\u00e9veloppement.<\/p>\n Exercice 2 : Scanner le SBOM pour les vuln\u00e9rabilit\u00e9s avec Grype<\/h2>\nGrype est le scanner de vuln\u00e9rabilit\u00e9s d’Anchore. Il peut scanner les images de conteneurs directement, mais il peut \u00e9galement scanner un fichier SBOM \u2014 ce qui est nettement plus rapide car il saute l’\u00e9tape d’analyse de l’image.<\/p>\n Scanner le SBOM<\/h3>\ngrype sbom:.\/sbom.spdx.json\n<\/code><\/pre>\nExemple de sortie :<\/p>\n NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY\nlodash 4.17.21 npm CVE-2025-XXXXX Medium\nnode 20.10.0 20.11.1 apk CVE-2024-22019 High\nlibcrypto3 3.1.4-r1 3.1.4-r3 apk CVE-2024-0727 Medium\n<\/code><\/pre>\nFiltrer par s\u00e9v\u00e9rit\u00e9<\/h3>\n# Afficher uniquement les vuln\u00e9rabilit\u00e9s Critiques et Hautes\ngrype sbom:.\/sbom.spdx.json --fail-on critical\n\n# Sortie des r\u00e9sultats en JSON pour traitement CI\ngrype sbom:.\/sbom.spdx.json -o json > vulnerabilities.json\n\n# Compter les vuln\u00e9rabilit\u00e9s par s\u00e9v\u00e9rit\u00e9\ncat vulnerabilities.json | jq '[.matches[].vulnerability.severity] | group_by(.) | map({severity: .[0], count: length})'\n<\/code><\/pre>\nScan d’image vs. scan de SBOM<\/h3>\nIl existe une distinction importante entre le scan direct de l’image et le scan du SBOM :<\/p>\n # Scan direct de l'image \u2014 Grype t\u00e9l\u00e9charge et analyse les couches de l'image\ngrype $IMAGE\n\n# Scan du SBOM \u2014 Grype lit la liste de paquets pr\u00e9-g\u00e9n\u00e9r\u00e9e\ngrype sbom:.\/sbom.spdx.json\n<\/code><\/pre>\n\n\n\n| Approche<\/th>\n | Vitesse<\/th>\n | Pr\u00e9cision<\/th>\n | Cas d’utilisation<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Scan direct de l’image<\/td>\n | Plus lent (t\u00e9l\u00e9charge les couches)<\/td>\n | D\u00e9couvre tous les paquets<\/td>\n | Premi\u00e8re analyse, d\u00e9veloppement local<\/td>\n<\/tr>\n | \n| Scan du SBOM<\/td>\n | Rapide (lit le fichier JSON)<\/td>\n | Limit\u00e9 au contenu du SBOM<\/td>\n | Pipelines CI, scans r\u00e9p\u00e9t\u00e9s, audit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Le scan du SBOM est aussi complet que le SBOM lui-m\u00eame. Si Syft a manqu\u00e9 un paquet (par exemple, un binaire compil\u00e9 statiquement), Grype ne trouvera pas de vuln\u00e9rabilit\u00e9s pour celui-ci. Pour une couverture maximale, g\u00e9n\u00e9rez le SBOM avec le flag --catalogers all<\/code> de Syft.<\/p>\nExercice 3 : Attacher le SBOM comme attestation Cosign<\/h2>\nUne attestation est une d\u00e9claration sign\u00e9e concernant un artefact logiciel. En attachant le SBOM comme attestation, vous liez cryptographiquement le SBOM au digest sp\u00e9cifique de l’image \u2014 n’importe qui peut v\u00e9rifier que le SBOM a \u00e9t\u00e9 produit pour cette image exacte et qu’il n’a pas \u00e9t\u00e9 falsifi\u00e9.<\/p>\n Attacher l’attestation SBOM<\/h3>\nEn utilisant le flux keyless (Sigstore Fulcio) de Cosign :<\/p>\n cosign attest --predicate sbom.spdx.json \\\n --type spdxjson \\\n --yes \\\n $IMAGE\n<\/code><\/pre>\nCette commande :<\/p>\n \n- Ouvre un navigateur pour l’authentification OIDC (signature keyless via Fulcio)<\/li>\n
- Cr\u00e9e une attestation in-toto avec votre SBOM comme pr\u00e9dicat<\/li>\n
- Signe l’attestation et l’enregistre dans le journal de transparence Rekor<\/li>\n
- Pousse l’attestation vers le registre aux c\u00f4t\u00e9s de l’image<\/li>\n<\/ol>\n
|
| | | | | | | |