Skip to main content

Attestations d’artefacts

Comprendre les avantages de l’utilisation et de la sécurité des attestations d’artefact.

Vue d’ensemble

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 :

  • Un lien vers le flux de travail associé à l'artefact
  • Le référentiel, l'organisation, l'environnement, le SHA de validation et l'événement déclencheur pour l'artefact
  • Autres informations du jeton OIDC utilisées pour établir la provenance. Pour plus d’informations, consultez « 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.

Niveaux SLSA pour les attestations d'artéfacts

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 faire réaliser votre processus de build au sein d'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 construction et le workflow appelant pour répondre au niveau de construction 3 de SLSA v1.0. Pour plus d’informations, consultez « Utiliser les attestations d’artefacts et les workflows réutilisables pour atteindre le niveau de build 3 de SLSA v1. ».

Pour plus d’informations sur les niveaux SLSA, consultez Niveaux de sécurité SLSA.

Comment GitHub génère des attestations d’artefact

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

          **Les référentiels publics** qui génèrent des attestations d’artefacts utilisent l’[instance de bien public Sigstore](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/). Une copie du bundle Sigstore généré est stockée avec GitHub et est également écrite dans un journal de transparence immuable accessible en lecture publique sur Internet.

          ** Dépôts privés** qui génèrent des attestations d'artefact utilisent l'instance Sigstore de GitHub. l'instance Sigstore de GitHub utilise la même base de code que la sigstore Public Good Instance, mais elle n'a pas de journal de transparence et fédère uniquement avec GitHub Actions.

Quand générer des attestations

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 :

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

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.

Avertissement

Il est important de se rappeler que les attestations d’artefact ne sont pas une garantie qu’un artefact est sécurisé. Au contraire, les attestations d’artefacts vous relient au code source et aux instructions de conception qui les ont produites. Il vous appartient de définir les critères de votre stratégie, de l’évaluer en évaluant le contenu et de prendre une décision éclairée en matière de risque lorsque vous consommez des logiciels.

Étapes suivantes

Pour commencer à générer et à vérifier les attestations d’artefact pour vos builds, consultez Utilisation d’attestations d’artefact pour établir la provenance des builds.