# GitHub lance Security Insights pour standardiser les pratiques de sécurité

_Publié le 6 novembre 2026 — https://ip73.fr/2026/11/06/github-lance-security-insights-pour-standardiser-les-pratiques-de/_

GitHub vient de publier la spécification Security Insights, un format YAML destiné à ce que les projets open source puissent documenter leurs pratiques de sécurité dans un langage compréhensible par des outils automatisés. Ce fichier se positionne entre un simple fichier `SECURITY.md` en texte brut et un SBOM, qui est déjà un inventaire lisible par machine de ce que contient le logiciel.

L'objectif est clair : les mainteneurs de projet doivent pouvoir communiquer leur posture de sécurité de façon structurée. Pour les chercheurs en sécurité, cela simplifie l'identification des vulnérabilités potentielles, et les organisations utilisatrices peuvent évaluer la robustesse des dépendances qu'elles intègrent. Cette démarche s'inscrit dans le travail d'OpenSSF, qui promeut également la vérifiabilité des artefacts.

La spécification exige que ce fichier, nommé `security-insights.yaml` ou `.yml`, soit placé à la racine du dépôt ou dans un répertoire dédié comme `.github/` ou `.gitlab/`. Ce document représente une « photographie » de l'état du projet au moment du *commit* ou de la *release*, et non son état actuel en temps réel. Les exemples fournis couvrent les structures pour projets mono-dépôt et multi-dépôts, permettant de gérer la complexité des architectures modernes.

## Automatiser l'audit de la posture de sécurité

L'adoption de ce standard ouvre la porte à une ingestion massive et automatisée des données de sécurité. Selon l'annonce de github.com, des outils communautaires existent déjà pour lire, valider et manipuler ces données. On trouve `si-tooling`, mais aussi des outils de la Fondation Linux comme `CLOMonitor` ou `LFX Insights`. Ces derniers servent à vérifier si un projet a effectivement rapporté sur certains facteurs de sécurité, en se basant sur l'OSPS Baseline, un ensemble de critères minimums pour les projets open source.

Ce besoin de traçabilité fait partie d'un effort plus vaste pour sécuriser la chaîne d'approvisionnement logicielle. Les acteurs du secteur, comme Sylva, illustrent déjà la complexité de ce processus. Ils emploient des outils tels que Sigstore pour signer et attester leurs artefacts, visant des niveaux de maturité comme SLSA Level 3. Leur expérience révèle toutefois que prouver l'intégrité d'un composant imbriqué, par exemple un *Helm chart* contenant plusieurs images tierces, demeure un défi technique majeur.

## Au-delà de la documentation : la mesure de la maturité

Les équipes qui ont suivi ce chemin ont constaté que même si des indicateurs montrent une amélioration, certaines limites spécifiques à leur plateforme, comme l'utilisation de GitLab au lieu de GitHub, peuvent fausser la perception de leur posture de sécurité. Des écarts entre les changements révisés et le score rapporté par l'outil sont parfois notables.

Ce nouveau standard de GitHub ne vise pas à résoudre tous les problèmes de confiance dans les dépendances, mais il offre une grammaire commune.

## Sources

- [GitHub - ossf/security-insights: Machine-readable specification for the attestation of security-relevant data.](https://github.com/ossf/security-insights-spec), github.com
- [From Sigstore to CRA readiness: Sylva’s journey with OpenSSF](https://openssf.org/blog/2026/11/06/from-sigstore-to-cra-readiness-sylvas-journey-with-openssf/), OpenSSF, 6 novembre 2026