Utilisation d’attestations d’artefact pour établir la provenance des builds

Note

Les attestations d’artefact sont en version bêta publique et peuvent être modifiées.

Informations sur les attestations d’artefacts

Les attestations d’artefact vous permettent de créer des garanties de provenance et d’intégrité non vérifiables pour le logiciel que vous créez. En retour, les personnes qui utilisent votre logiciel peuvent vérifier où et comment il a été conçu.

Lorsque vous générez des attestations d’artefact avec votre logiciel, vous créez des revendications signées par chiffrement qui établissent la provenance de votre build et incluent les informations suivantes :

Lien vers le flux de travail associé à l’artefact.
Le référentiel, l’organisation, l’environnement, le commit SHA et l’événement de déclenchement de l’artefact.
Autres informations du jeton OIDC utilisées pour établir la provenance. Pour plus d’informations, consultez « À propos du renforcement de la sécurité avec OpenID Connect ».

Vous pouvez également générer des attestations d’artefact qui incluent une nomenclature logicielle (SBOM). L’association de vos builds à une liste des dépendances open source utilisées assure la transparence et permet aux consommateurs de se conformer aux normes de protection des données.

Informations sur les niveaux SLSA pour les attestations d’artefacts

Le cadre SLSA est une norme sectorielle utilisée pour évaluer la sécurité de la chaîne d’approvisionnement. Il est organisé en niveaux. Chaque niveau représente un degré croissant de sécurité et de fiabilité pour une chaîne d’approvisionnement logicielle. Les attestations d’artefacts fournissent le niveau 2 du build SLSA v1.0.

Vous pouvez utiliser les attestations d’artefacts pour atteindre le niveau 3 du build SLSA v1.0. Cependant, nous vous recommandons fortement de vous concentrer d’abord sur l’adoption générale du niveau 2 du build dans votre organisation. Il est de loin préférable d’atteindre régulièrement le niveau 2 dans l’ensemble de vos builds plutôt que d’avoir une petite partie de vos builds qui atteignent le niveau 3. Pour atteindre le niveau 3 du build, nous recommandons de normaliser votre processus de build avec des flux de travail réutilisables, d’auditer les flux de travail réutilisables pour s’assurer qu’ils répondent aux exigences du niveau 3, puis de mettre à jour votre stratégie de vérification afin d’exiger ces flux de travail réutilisables audités.

Pour plus d’informations, consultez la section Provenance de la documentation de SLSA.

Informations sur l’utilisation de Sigstore pour les attestations d’artefact

Pour générer des attestations d’artefacts, GitHub utilise Sigstore, un projet open source qui offre une solution complète pour la signature et la vérification d’artefacts logiciels par le biais d’attestations.

Les référentiels publics qui génèrent des attestations d’artefacts utilisent l’instance de bien public Sigstore. Une copie du regroupement Sigstore généré est stockée sur GitHub et est également écrite dans un journal de transparence immuable accessible au public sur Internet.

Les référentiels privés qui génèrent des attestations d’artefacts utilisent l’instance Sigstore de GitHub. L’instance Sigstore de GitHub utilise la même codebase que l’instance de bien public Sigstore, mais elle ne dispose pas d’un journal de transparence et ne se fédère qu’avec GitHub Actions.

Informations sur la vérification des attestations d’artefacts

Si vous utilisez un logiciel qui publie des attestations d’artefacts, vous pouvez utiliser GitHub CLI pour vérifier ces attestations. Dans la mesure où les attestations vous donnent des informations sur l’emplacement et la manière dont le logiciel a été conçu, vous pouvez utiliser ces informations pour créer et appliquer des stratégies de sécurité qui renforcent la sécurité de votre chaîne d’approvisionnement. Pour plus d’informations, consultez « [Vérification des attestations d’artefacts avec le pour générer des attestations d’artefacts qui établissent la provenance du build pour des artefacts tels que les binaires et les images de conteneurs.

Pour générer une attestation d’artefact, vous devez :

Vérifier que vous disposez des autorisations appropriées configurées dans votre flux de travail.
Inclure une étape dans votre flux de travail qui utilise l’action attest-build-provenance.

Lorsque vous exécutez vos flux de travail mis à jour, ils génèrent vos artefacts et génèrent une attestation d’artefact qui établit la provenance du build. Vous pouvez afficher les attestations sous l’onglet Actions de votre référentiel. Pour plus d’informations, consultez le référentiel attest-build-provenance.

Génération d’une provenance de build pour les fichiers binaires

Dans le flux de travail qui génère le fichier binaire que vous souhaitez attester, ajoutez les autorisations suivantes.
```
permissions:
  id-token: write
  contents: read
  attestations: write
```
Après l’étape de génération du fichier binaire, ajoutez l’étape suivante.
```
- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'
```
La valeur du paramètre subject-path doit être définie sur le chemin d’accès au fichier binaire que vous souhaitez attester.

Génération d’une provenance de build pour les images conteneur

Dans le flux de travail qui génère l’image conteneur que vous souhaitez attester, ajoutez les autorisations suivantes.
```
permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write
```
Après l’étape de génération de l’image, ajoutez l’étape suivante.
```
- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: 'sha256:fedcba0...'
    push-to-registry: true
```
La valeur du paramètre subject-name doit spécifier le nom complet de l’image. Par exemple, ghcr.io/user/app ou acme.azurecr.io/user/app. N’incluez pas de balise dans le nom de l’image.

La valeur du paramètre subject-digest doit correspondre au résumé SHA256 du sujet de l’attestation, sous la forme sha256:HEX_DIGEST. Si votre flux de travail utilise docker/build-push-action, vous pouvez utiliser la sortie digest de cette étape pour fournir la valeur. Pour plus d’informations sur l’utilisation des sorties, consultez « Workflow syntax for GitHub Actions. »

Génération d’une attestation pour une nomenclature logicielle (SBOM)

Vous pouvez générer des attestations SBOM signées pour les artefacts de flux de travail.

Pour générer une attestation pour un SBOM, vous devez :

Vérifier que vous disposez des autorisations appropriées configurées dans votre flux de travail.
Créez un SBOM pour votre artefact. Pour plus d’informations, consultez anchore-sbom-action dans la GitHub Marketplace.
Inclure une étape dans votre flux de travail qui utilise l’action attest-sbom.

Lorsque vous exécutez vos flux de travail mis à jour, ils génèrent vos artefacts et génèrent une attestation SBOM. Vous pouvez consulter les attestations dans l’onglet Actions de votre référentiel. Pour plus d’informations, consultez le référentiel d’actions attest-sbom.

Génération d’une attestation SBOM pour les fichiers binaires

Dans le flux de travail qui génère le fichier binaire que vous souhaitez attester, ajoutez les autorisations suivantes.
```
permissions:
  id-token: write
  contents: read
  attestations: write
```
Après l’étape de génération du fichier binaire, ajoutez l’étape suivante.
```
- name: Generate SBOM attestation
  uses: actions/attest-sbom@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'
    sbom-path: 'PATH/TO/SBOM'
```
La valeur du paramètre subject-path doit être définie sur le chemin d’accès du fichier binaire décrit par SBOM. La valeur du paramètre sbom-path doit être définie sur le chemin d’accès du fichier SBOM que vous avez généré.

Génération d’une attestation SBOM pour les images conteneur

Dans le flux de travail qui génère l’image conteneur que vous souhaitez attester, ajoutez les autorisations suivantes.
```
permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write
```
Après l’étape de génération de l’image, ajoutez l’étape suivante.
```
- name: Generate SBOM attestation
  uses: actions/attest-sbom@v1
  with:
    subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
    subject-digest: 'sha256:fedcba0...'
    sbom-path: 'sbom.json'
    push-to-registry: true
```
La valeur du paramètre subject-name doit spécifier le nom complet de l’image. Par exemple, ghcr.io/user/app ou acme.azurecr.io/user/app. N’incluez pas de balise dans le nom de l’image.

La valeur du paramètre subject-digest doit correspondre au résumé SHA256 du sujet de l’attestation, sous la forme sha256:HEX_DIGEST. Si votre flux de travail utilise docker/build-push-action, vous pouvez utiliser la sortie digest de cette étape pour fournir la valeur. Pour plus d’informations sur l’utilisation des sorties, consultez « Workflow syntax for GitHub Actions. »

La valeur du paramètre sbom-path doit être définie sur le chemin d’accès du fichier SBOM au format JSON que vous souhaitez attester.

Vérifier les attestations d’artefacts avec le GitHub CLI

Pour vérifier les attestations d’artefact pour les fichiers binaires, utilisez la commande GitHub CLI suivante.

Bash

gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME

gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME

Pour vérifier les attestations d’artefacts pour les images conteneurs, vous devez fournir le FQDN de l’image préfixé par oci:// au lieu du chemin d’accès à un fichier binaire. Vous pouvez utiliser la commande GitHub CLI suivante.

Bash

docker login ghcr.io

gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME

docker login ghcr.io

gh attestation verify oci://ghcr.io/ORGANIZATION_NAME/IMAGE_NAME:test -R ORGANIZATION_NAME/REPOSITORY_NAME

Pour plus d’informations, consultez la section attestation du manuel GitHub CLI.

Utilisation d’attestations d’artefact pour établir la provenance des builds

Dans cet article