Renforcer le pipeline : Mettre en œuvre des pratiques de chaîne d'approvisionnement sécurisée dans GitHub Actions

Le cycle de vie moderne du développement logiciel est de plus en plus complexe, reposant sur un vaste réseau de dépendances tierces, d'images de conteneurs et de workflows automatisés. Avec l'augmentation des attaques sophistiquées contre la chaîne d'approvisionnement, telles que la vulnérabilité Log4j et les outils de construction compromis récemment, garantir l'intégrité de vos artefacts n'est plus une option, c'est une nécessité. GitHub Actions propose des primitives puissantes pour vous aider à construire un pipeline CI/CD « digne de confiance ». Dans ce guide, nous explorerons comment mettre en œuvre la génération de la Nomenclature Logicielle (SBOM) et la signature des artefacts au sein de vos workflows GitHub Actions afin de vérifier la provenance et l'intégrité.

L'importance des SBOM dans le DevOps

Une Nomenclature Logicielle (SBOM, Software Bill of Materials) est essentiellement un inventaire de tous les composants, bibliothèques et dépendances inclus dans votre logiciel. Considérez-la comme une étiquette nutritionnelle pour votre application. Lorsqu'une nouvelle vulnérabilité émerge dans une bibliothèque courante, une SBOM vous permet d'identifier instantanément si vous êtes affecté et quelles versions spécifiques sont utilisées. Sans cette visibilité, la correction des vulnérabilités devient un jeu de devinettes qui peut laisser votre infrastructure exposée.

Générer automatiquement une SBOM dans le cadre de votre processus de construction garantit que vous disposez toujours d'un enregistrement actuel et précis de vos dépendances. Cela ne concerne pas uniquement les équipes de sécurité ; c'est essentiel pour les cadres de conformité tels que le NIST SSDF (Secure Software Development Framework) et les directives exécutives exigeant la transparence des logiciels.

Générer des SBOM avec GitHub Actions

GitHub propose un outil natif pour générer des SBOM : l'action anchore/sbom-action. Cette action utilise Grype, un scanner de vulnérabilités puissant, pour créer une SBOM au format CycloneDX ou SPDX. L'intégrer dans votre workflow est simple. Vous devez simplement spécifier le chemin vers le répertoire contenant votre code source et choisir le format de sortie souhaité.

Voici un exemple pratique de la manière d'intégrer la génération de SBOM dans un workflow de construction standard :

name: Build and Generate SBOM

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build Application
        run: echo "Building application..."
      
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          path: ./my-app-directory
          format: cyclonedx-json
          artifact-name: my-app-sbom.cdx.json
          output-file: sbom-output.json

Dans cet extrait, le paramètre artifact-name garantit que la SBOM est téléchargée en tant qu'artefact de construction, vous permettant de la télécharger depuis l'interface utilisateur de GitHub Actions ou de la référencer dans les étapes suivantes.

Signature des artefacts pour la vérification de l'intégrité

Tandis qu'une SBOM vous indique ce qui se trouve à l'intérieur de votre artefact, sa signature vous garantit qu'il n'a pas été altéré depuis la fin de la construction. En signant vos artefacts, vous créez une garantie cryptographique de l'intégrité. Si un attaquant intercepte votre pipeline de construction et remplace un binaire par un malveillant, la vérification de la signature échouera, alertant votre système de déploiement pour qu'il rejette le code compromis.

Pour les images de conteneurs et les fichiers génériques, sigstore devient la norme de l'industrie pour la signature. Sigstore fournit une infrastructure transparente, publique et ouverte pour signer les chaînes d'approvisionnement logicielles. GitHub Actions prend en charge nativement la signature des artefacts à l'aide de Sigstore, ce qui élimine le besoin de gérer une infrastructure complexe de stockage de clés.

Voici comment signer un artefact généré dans une étape précédente :

- name: Sign Artifact
  uses: sigstore/gh-action-sigstore-python@v2.1.1
  with:
    inputs: |
      ./my-app-binary

Cette étape produit des entrées de signature et de journal de transparence des certificats (CT), créant un enregistrement immuable qui lie le hachage de commit spécifique à la sortie binaire. Il s'agit d'une exigence fondamentale pour atteindre les niveaux supérieurs du cadre SLSA (Supply-chain Levels for Software Artifacts).

Conclusion

La mise en œuvre de la génération de SBOM et de la signature des artefacts dans GitHub Actions transforme votre pipeline CI/CD d'un simple outil d'automatisation en une frontière de sécurité robuste. Ces pratiques ne nécessitent pas une refonte complète de vos workflows existants ; elles peuvent plutôt être adoptées de manière incrémentale pour améliorer votre posture de sécurité au fil du temps. En faisant de la transparence et de l'intégrité des citoyens de première classe dans votre processus de développement, vous protégez non seulement votre propre infrastructure, mais aussi l'intégrité de l'écosystème plus large qui dépend de votre logiciel. Commencez à intégrer ces contrôles dès aujourd'hui pour rester à la pointe des menaces émergentes.