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

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 à elles seules le niveau 2 du build SLSA v1.0.

Cela fournit un lien entre votre artefact et ses instructions de génération, mais vous pouvez effectuer cette étape en exigeant que les builds utilisent des instructions de build connues et approuvées. Pour ce faire, vous pouvez utiliser votre build dans un flux de travail réutilisable que de nombreux référentiels de votre organisation partagent. Les flux de travail réutilisables peuvent fournir une isolation entre le processus de génération et le flux de travail appelant afin de répondre au niveau 3 du build SLSA v1.0. Pour plus d’informations, consultez « Utilisation d’attestations d’artefacts et de flux de travail réutilisables pour atteindre le niveau 3 du build SLSA v1 ».

Pour plus d’informations sur les niveaux SLSA, consultez Niveaux de sécurité 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.

Que faut-il attester

La génération d’attestations seules ne fournit aucun avantage de sécurité ; les attestations doivent être vérifiées pour que l’avantage soit réalisé. Voici quelques instructions pour savoir comment penser à quoi signer et à quelle fréquence :

Vous devriez signer :

Le logiciel que vous publiez sur lequel vous vous attendez à ce que les utilisateurs exécutent gh attestation verify ....
Les fichiers binaires exécutés par les utilisateurs, les packages que les utilisateurs téléchargent ou les manifestes qui incluent des hachages de contenu détaillé.

Vous ne devriez pas signer :

Builds fréquentes qui sont uniquement destinées aux tests automatisés.
Fichiers individuels tels que le code source, les fichiers de documentation ou les images incorporées.

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.