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 :

  • 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 « 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'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.

Comment GitHub génère des attestations d'artefacts

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.

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 :

  • 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.

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 Using artifact attestations to establish provenance for builds.