Résumé

  • SLSA v1.2 présente la provenance comme une preuve à inspecter face à des attentes ; une attestation ne produit aucune décision par elle-même.
  • La spécification sépare l’attestation liée à un artefact, la racine de confiance, les attentes attachées au nom d’un paquet et l’acceptation effectuée par un écosystème, un consommateur ou un moniteur.
  • Un reçu d’attentes et de réponse peut empêcher qu’une attestation valable soit lue comme une approbation générale d’une version.

Une preuve attachée à l’artefact

Le modèle de provenance de SLSA ne parle pas abstraitement d’un projet « sûr ». Il décrit une attestation selon laquelle une plateforme de construction donnée a produit des artefacts par l’exécution d’une buildDefinition. Le sujet peut être relié à un condensat précis ; le constructeur, le type de construction, les paramètres et les dépendances peuvent être examinés. C’est exactement le genre de trace qui permet de comparer une construction réelle à ce que l’on attendait d’elle.

La règle de distribution renforce cette précision : les attestations devraient être attachées aux artefacts, non aux versions. Une même version peut contenir plusieurs artefacts, pour plusieurs architectures ou environnements, produits à des dates différentes. D’autres artefacts et attestations peuvent encore être ajoutés. Le mot « release » ne fournit donc pas, à lui seul, le lien exact entre un binaire et sa provenance.

Cette limitation ne diminue pas la valeur de l’attestation. Elle empêche surtout de lui faire dire trop. La page de vérification SLSA rappelle que la provenance ne fait rien tant que quelqu’un ne l’inspecte pas. Il faut conserver cette séquence : une preuve est émise ; un vérificateur l’évalue ; une partie autorisée décide ensuite d’accepter, de refuser ou de surveiller.

Les attentes ne sortent pas de l’enveloppe

SLSA demande au vérificateur de configurer ses racines de confiance : les identités de constructeurs reconnues et le niveau SLSA auquel chacune est jugée fiable. Il doit vérifier la signature, rapprocher le subject du condensat de l’artefact, puis comparer buildType et externalParameters aux valeurs attendues.

Une attestation correctement signée ne choisit pas ces valeurs attendues. SLSA prévoit que des vérificateurs différents puissent utiliser des racines de confiance différentes. Il distingue aussi les attentes, liées au nom d’un paquet, de la provenance, liée à l’artefact. Un écosystème peut fixer un dépôt source canonique ; un consommateur peut appliquer sa propre règle ; un producteur peut publier des attentes à travers un canal authentifié ; une politique de confiance au premier usage peut faire de l’état initial le point de comparaison.

Ces mécanismes répondent à une autre question : quelles valeurs sont admises pour ce paquet, dans ce contexte ?

Les paramètres externes illustrent nettement la frontière. Ils sont sous contrôle externe, doivent être consignés, puis vérifiés en aval. Leur présence n’équivaut pas à une autorisation. SLSA conseille de rejeter les paramètres non reconnus. De même, une identité de constructeur dans une attestation n’oblige pas chaque écosystème à lui accorder confiance. L’authenticité établit un lien entre une déclaration et son émetteur ; la confiance reste une décision de politique.

Le point d’acceptation a son propre titulaire

La vérification peut être effectuée lors du dépôt dans un écosystème de paquets, lors du téléchargement ou de l’usage par un consommateur, ou dans un moniteur. Ces emplacements peuvent se compléter. L’écosystème peut décider de l’admission dans un registre ; le consommateur peut décider d’installer ou de déployer ; le moniteur peut publier une divergence. SLSA souligne toutefois qu’une détection a peu d’utilité sans action humaine ou automatisée.

Il est donc parfaitement possible qu’un même artefact soit accepté par une politique, écarté par une autre, ou signalé en attente de traitement. Ce n’est pas une contradiction de la provenance : c’est la conséquence normale de décisions possédant des propriétaires différents. Le document de distribution dit lui-même que la provenance donne à un dépôt l’élément nécessaire pour vérifier une politique potentielle exigeant un niveau SLSA. L’élément n’est pas la politique, ni son exécution, ni le procès-verbal d’une admission.

Une annonce « provenance SLSA disponible » est ainsi une affirmation utile et bornée. Elle ne veut pas dire que toute version est acceptée partout, que chaque consommateur a adopté la même source de confiance, ni qu’un échec entraînera une remédiation déterminée.

Un reçu d’attentes et de réponse

Le contrôle minimal n’est pas une nouvelle norme SLSA. C’est un reçu tenu par l’écosystème, le consommateur ou le moniteur qui évalue la provenance. Il devrait indiquer le condensat de l’artefact et la référence de l’attestation, l’identité du vérificateur et la version de la règle, l’entrée de racine effectivement utilisée, le dépôt source attendu, le buildType, les paramètres externes admis, l’instant du contrôle et le résultat.

En cas d’échec, le reçu devrait dire ce qui s’est passé : rejet, quarantaine, alerte, exception temporaire ou attente ; il devrait aussi nommer qui peut modifier cet état. Lorsqu’une attente change, le reçu devrait relier la décision autorisée au lieu de réécrire silencieusement l’ancien résultat.

Cette trace ne proclame ni sûreté universelle, ni exhaustivité des dépendances, ni délai de remédiation. Elle rend toutefois les frontières vérifiables : preuve authentique contre artefact accepté ; changement de politique contre rotation de signature ; décision d’un registre contre décision de déploiement ; alerte de moniteur contre remédiation terminée.

Préserver le choix sans emprunter l’autorité d’autrui

La méthode de Heng Lu compte ici comme méthode, non comme preuve sur SLSA : un instrument de coordination doit exposer sa compétence limitée au lieu de déclarer vraie une réalité qui n’a pas été adoptée. SLSA décrit comment produire, distribuer et vérifier une provenance ; il ne confond pas ces opérations avec le choix du constructeur digne de confiance, l’attente propre à un paquet ou la réponse à une divergence.

Le raccourci coûteux consiste à fondre dans une seule formule l’authenticité de construction, l’approbation du paquet, l’achèvement d’une version et l’efficacité d’une réponse. Cette formule se défait mal lorsqu’une racine change, qu’une architecture est ajoutée, qu’une exception expire ou qu’un moniteur détecte un écart. Le reçu garde la preuve, l’attente et la décision séparément lisibles, sans empêcher leur coopération.

Sources

  1. SLSA v1.2 — Build: Verifying artifacts
  2. SLSA v1.2 — Build: Provenance
  3. SLSA v1.2 — Build: Distributing provenance