Résumé

  • OSPS Baseline autorise l’auto-attestation d’un projet et présente la conformité comme un état ponctuel rattaché à une version et à un niveau de maturité.
  • Une déclaration exploitable doit identifier le périmètre, la version, le niveau, la date, l’attestant, les preuves par contrôle, les exceptions et le déclencheur d’un nouvel examen.

Analyse

Le danger tient parfois à une cellule trop bien rangée. Une équipe d’achat reçoit la ligne d’un composant et lit simplement « OSPS : conforme ». Elle peut comparer ce champ, l’exporter et l’insérer dans un dossier de décision. Mais elle ne sait pas quel texte a été appliqué, ni à quel projet exact, ni quand les preuves ont été examinées.

La documentation officielle évite précisément cette ambiguïté. La page d’accueil désigne v2026.08.28 comme version courante pour les nouveaux travaux de conformité, maintient les versions antérieures comme références historiques et distingue le texte en cours d’élaboration. La FAQ permet aux projets de s’auto-attester, qualifie la conformité d’état à un instant donné et recommande d’indiquer une date d’observation, une version et un niveau.

Une affirmation ne voyage pas sans coordonnées

La version fige l’obligation consultée. Le processus de maintenance emploie une date au format YYYY-MM-DD, conserve les éditions passées et réserve un nouvel identifiant aux changements substantiels de sens. Une modification plus limitée, y compris le déplacement d’un contrôle vers un autre niveau, peut conserver l’identifiant. Citer seulement OSPS-… ne suffit donc pas à retrouver l’exigence historique.

Le niveau fixe l’ensemble applicable. Dans l’édition 2026.08.28, le niveau 1 vise tout projet, avec ou sans code ; le niveau 2, un projet logiciel comptant au moins deux mainteneurs et quelques utilisateurs réguliers ; le niveau 3, un projet logiciel suivi par de nombreux utilisateurs réguliers. Une mention sans niveau efface la règle de sélection.

La date borne la durée de confiance. Les droits des collaborateurs, les protections de branche, les canaux de publication, les contacts de sécurité et les procédures changent. Une preuve relative à une livraison signée n’englobe pas automatiquement la suivante. L’état ponctuel évite qu’une photographie ancienne devienne, par simple copie, une promesse actuelle.

Enfin, le périmètre empêche le nom d’un projet de recouvrir des objets différents. Dépôt principal, sous-projets, site, registre de paquets, chaîne de compilation et branches de maintenance peuvent relever de responsables et de preuves distincts. Les contrôles OSPS nomment eux-mêmes plusieurs sujets : projet, dépôt faisant autorité, système de gestion de versions, pipeline ou livraison officielle. La preuve doit rester attachée au bon sujet.

L’auto-attestation rend visible ce que le scanner ignore

Une auto-attestation n’est ni un audit indépendant ni un élément sans valeur. Elle offre aux mainteneurs un moyen de décrire des configurations auxquelles le public n’a pas accès. La FAQ reconnaît que de nombreux contrôles sont observables publiquement, tandis que d’autres concernent des paramètres privilégiés. Un utilisateur en aval peut accepter cette déclaration ou convenir d’une autre vérification.

Il faut donc enregistrer l’auteur de l’affirmation et la frontière de la preuve. Un fichier de politique, l’historique d’un dépôt ou un manifeste de livraison peuvent être publics. Une configuration sensible peut être consultée sous confidentialité par une fondation, un financeur ou un client. Dire « vérifié » exige de nommer le vérificateur, la méthode, l’objet et la date ; l’absence de preuve publique n’autorise ni réussite implicite ni échec automatique.

Les correspondances avec d’autres référentiels demandent la même retenue. L’édition 2026.08.28 les présente comme des références qui ne garantissent pas une équivalence exacte et ne créent aucun lien fonctionnel. La FAQ précise qu’elles ne valent ni conformité aux catalogues cités, ni audit, ni certification. Une jointure de tableau ne peut transformer une auto-attestation OSPS en conformité ISO, NIST ou réglementaire.

Transformer l’étiquette en reçu

Le reçu peut rester bref. Il relie le nom canonique du projet aux dépôts et livraisons examinés ; indique version, niveau et date ; identifie l’attestant et son pouvoir ; énumère les contrôles applicables ; associe à chacun une preuve et son heure d’observation ; marque les éléments restreints, les exceptions et les non-applicabilités ; puis fixe le changement ou l’échéance qui imposera un réexamen.

Ce reçu ne garantit pas l’absence de vulnérabilité. Il ne recommande pas une dépendance, ne certifie pas un binaire et ne prédit pas un déploiement. Il permet simplement à un tiers de comprendre ce qui a été déclaré, par rapport à quel texte et pendant quelle fenêtre.

Le partage des rôles devient alors lisible. Les mainteneurs du Baseline publient les critères ; un projet décrit son état ; un examinateur peut contrôler certaines preuves ; le responsable d’un produit décide encore s’il adopte une version pour un usage précis. Le langage commun éclaire la décision sans la confisquer.

La cellule verte devrait donc devenir un lien : « OSPS v2026.08.28, niveau 2, examiné le 2026-09-07 ». Le détail se trouve derrière. La concision n’efface plus le dossier ; elle en devient l’entrée.

Sources

  1. Index des versions d’OSPS Baseline
  2. OSPS Baseline, version 2026.08.28
  3. FAQ d’OSPS Baseline
  4. Processus de maintenance d’OSPS Baseline
  5. Gouvernance du projet OSPS Baseline