OpenSSF Scorecard

En mars 2024, XZ Utils, un utilitaire de compression présent sur quasiment tous les serveurs Linux, a été compromis par une backdoor planquée pendant deux ans. L'attaquant avait gagné la confiance du mainteneur, obtenu les droits de commit, puis injecté du code malveillant permettant une exécution de code à distance via SSH. Cette attaque illustre parfaitement le dilemme de la supply chain logicielle : comment faire confiance à des dépendances maintenues par des inconnus ?

Les attaques supply chain explosent. Selon Sonatype, elles ont augmenté de 245% en trois ans. SolarWinds, Event-Stream, Polyfill.io, tj-actions... chaque incident montre que la popularité d'un projet ne garantit pas sa sécurité. Un package npm avec des millions de téléchargements peut être repris par un attaquant. Une action GitHub avec des milliers d'étoiles peut exfiltrer vos secrets.

Évaluer la posture de sécurité d'un projet avant de lui faire confiance est au cœur du référentiel Socle DevSecOps et de ses exigences sur les dépendances open source.

Le problème fondamental : on fait confiance aveuglément. On installe des centaines de dépendances sans vérifier qui les maintient, comment elles sont buildées, si les releases sont signées. On utilise des actions GitHub avec des tags mutables (@v1) qui peuvent changer à tout moment. On charge des scripts depuis des CDN tiers sans contrôle.

OpenSSF Scorecard apporte une réponse objective à cette question de confiance. Cet outil développé par l'Open Source Security Foundation analyse automatiquement un dépôt GitHub et attribue un score de 0 à 10 basé sur des critères de sécurité concrets : protection des branches, revues de code, signatures, vulnérabilités connues, patterns dangereux dans les workflows...

Ce que vous allez apprendre

Comprendre ce qu'évalue Scorecard et comment lire les résultats
Installer et utiliser la CLI sur un dépôt public
Brancher Scorecard dans une CI/CD, sur GitHub comme sur GitLab
Lire les 18 checks exécutés par défaut, leur poids, et la remédiation de chacun
Améliorer votre score avec un plan d'action progressif
Ancrage socle : Scorecard produit la preuve de SOCLE-INT-VER-3, l'analyse de composition étendue qui couvre licences, qualité et score de maintenance

Qu'est-ce que OpenSSF Scorecard ?

Scorecard est un outil automatisé qui mesure la posture de sécurité d'un projet open source. Il exécute une série de checks (contrôles heuristiques) et génère un score pour chacun d'eux.

Le projet est publié par l'OpenSSF, l'Open Source Security Foundation, et son dépôt s'appelle ossf/scorecard. Vous croiserez donc les deux graphies : OSSF Scorecard dans les noms de dépôt, d'action GitHub et d'image de conteneur, OpenSSF Scorecard dans la documentation et les communiqués. Elles désignent exactement le même outil.

L'idée est simple : plutôt que de faire confiance aveuglément à une dépendance, on vérifie objectivement si le projet suit les bonnes pratiques de sécurité.

Pourquoi c'est utile ?

Un score Scorecard ne remplace pas une revue de code : il répond à une question différente, et plus rapide à poser. Le projet qui produit cette dépendance travaille-t-il proprement ? Quatre usages en découlent, du plus courant au plus automatisé.

Évaluer une dépendance avant adoption : un score inférieur à 5 doit alerter
Auditer mes propres projets : identifier les faiblesses à corriger
Prouver ma maturité sécurité : afficher un badge de score dans mon README
Automatiser la surveillance : intégrer Scorecard dans la CI/CD

Ce que Scorecard évalue

Scorecard analyse des aspects variés de la sécurité d'un projet :

Catégorie	Exemples de checks
Protection du code	Branch Protection, Code Review, Signed Releases
Qualité du build	Pinned Dependencies, CI Tests, Fuzzing
Maintenance	Maintainers actifs, Réponse aux vulnérabilités
Sécurité opérationnelle	Dangerous Workflows, Token Permissions

Chaque check retourne un score de 0 à 10 avec une raison expliquant le résultat.

Installation

Scorecard peut s'installer de plusieurs façons selon l'environnement.

# Récupérer la dernière version disponible
VERSION=$(curl -s https://api.github.com/repos/ossf/scorecard/releases/latest | grep tag_name | cut -d '"' -f 4)

# Télécharger la release
wget "https://github.com/ossf/scorecard/releases/download/${VERSION}/scorecard_${VERSION#v}_linux_amd64.tar.gz"

# Extraire et installer
tar xzf scorecard_*_linux_amd64.tar.gz
sudo install scorecard /usr/local/bin/scorecard

# Vérifier l'installation
scorecard version

# Installation via Homebrew
brew install scorecard

# Vérifier l'installation
scorecard version

# Utiliser l'image officielle, épinglée par digest
docker run -it \
  gcr.io/openssf/scorecard:v5.5.0@sha256:b9a535801cb5fc8e7b2bea4cf45dd2db9a342cab8cc32bb5be2ac1355a95356f \
  --repo=github.com/org/projet

Utilisation de base

Configurer l'authentification GitHub

Type de token et permissions :

Type de token	Scope requis	Limitation
Classic token	`public_repo` (ou `repo` pour dépôts privés)	Accès complet à tous les checks
Fine-grained token	`Contents: read`, `Metadata: read`	Ne peut pas lire les règles de protection de branche classiques

# Créer un token classique sur https://github.com/settings/tokens
# Scope minimal : public_repo (ou repo pour les dépôts privés)

# Exporter le token
export GITHUB_AUTH_TOKEN=ghp_xxxxxxxxxxxx

Analyser un projet GitHub

Une fois le token configuré, la commande de base analyse un dépôt :

# Analyser un projet public
scorecard --repo=github.com/kubernetes/kubernetes

Comprendre la sortie

Scorecard affiche un résumé par check. Voici un exemple réel sur le projet Kubernetes :

Aggregate score: 6.8 / 10

Check scores:
|---------|------------------------|-----------------------------------------------------------------------|
|  SCORE  |          NAME          |                                REASON                                 |
|---------|------------------------|-----------------------------------------------------------------------|
| 10 / 10 | Binary-Artifacts       | no binaries found in the repo                                         |
| 10 / 10 | CI-Tests               | 13 out of 13 merged PRs checked by a CI test                          |
|  5 / 10 | CII-Best-Practices     | badge detected: Passing                                               |
|  8 / 10 | Code-Review            | Found 13/16 approved changesets                                       |
| 10 / 10 | Contributors           | project has 37 contributing companies or organizations                |
|  0 / 10 | Dependency-Update-Tool | no update tool detected                                               |
| 10 / 10 | Fuzzing                | project is fuzzed                                                     |
| 10 / 10 | License                | license file detected                                                 |
| 10 / 10 | Maintained             | 30 commit(s) and 4 issue activity found in the last 90 days           |
|  0 / 10 | Pinned-Dependencies    | dependency not pinned by hash detected                                |
|  0 / 10 | SAST                   | SAST tool is not run on all commits                                   |
| 10 / 10 | Security-Policy        | security policy file detected                                         |
|  8 / 10 | Vulnerabilities        | 2 existing vulnerabilities detected                                   |
|---------|------------------------|-----------------------------------------------------------------------|

Formats de sortie

Scorecard supporte plusieurs formats pour l'intégration dans d'autres outils :

# Format JSON pour traitement automatisé
scorecard --repo=github.com/org/projet --format=json > scorecard.json

# Format SARIF pour GitHub Security
scorecard --repo=github.com/org/projet --format=sarif > scorecard.sarif

Les checks en détail

Scorecard compte une vingtaine de checks, dont 18 exécutés par défaut. Chaque check évalue un aspect de la sécurité et attribue un score de 0 à 10. Voici la liste complète avec les critères d'évaluation et les actions pour améliorer chaque score.

Le score global est une moyenne pondérée

Le score affiché n'est pas la moyenne simple des checks : chaque check porte un poids de 1 à 10. Sans cette table, on ne sait pas par où commencer, et corriger un check à 1 coûte le même temps de lecture qu'un check à 10 pour un effet dix fois moindre.

Poids	Checks
10	Binary-Artifacts, Branch-Protection, Code-Review, Dangerous-Workflow, Maintained, Signed-Releases, Token-Permissions, Vulnerabilities
7,5	Dependency-Update-Tool, Packaging, Pinned-Dependencies, SAST
5	CI-Tests, Contributors, Fuzzing, License
1	CII-Best-Practices, Security-Policy, Webhooks

Deux poids surprennent, et ils changent l'ordre des priorités. Security-Policy pèse 1, alors qu'il se range naturellement à côté de License qui pèse 5. Et Signed-Releases pèse 10, autant que Branch-Protection : signer ses releases vaut autant que protéger sa branche principale.

Un check non évalué n'est pas un zéro

L'API rend -1 quand un check n'a pas pu être évalué, faute de release à inspecter pour Signed-Releases, ou faute de droits suffisants pour lire une protection de branche classique. Ce -1 est exclu du dénominateur : il ne pénalise pas le score global.

La conséquence est contre-intuitive et mérite d'être retenue : rendre une donnée lisible mais fausse note moins bien que la laisser illisible. Tant qu'un réglage n'est pas exposé, il sort du calcul. Une fois exposé et mal réglé, il entre au dénominateur et peut casser un palier. Un ruleset à moitié configuré peut donc noter moins bien qu'une absence totale de ruleset.

Sur ossf/scorecard, sigstore/cosign et kubernetes/kubernetes, Branch-Protection rend d'ailleurs -1 avec le message « some github tokens can't read classic branch protection rules ». Ces trois projets ne sont pas mal protégés : ils ne sont simplement pas mesurables avec un jeton public.

Checks critiques (risque élevé)

Binary-Artifacts

Risque : Code non auditable dans le dépôt.

Vérifie l'absence de fichiers binaires exécutables (.exe, .class, .pyc, JS minifié...) dans le code source. Les binaires ne peuvent pas être relus et peuvent contenir du code malveillant ou obsolète.

Score 10/10 : Aucun binaire trouvé dans le dépôt.

Remédiation : Supprimer les binaires et les générer à partir du code source lors du build.

Branch-Protection

Risque : Injection de code malveillant sans contrôle.

Vérifie que les branches principales (main, master) sont protégées via les règles de protection GitHub.

Barème par paliers :

Points	Exigences
3/10	Interdiction du force push et de la suppression de branche
6/10	+ PR obligatoire, au moins 1 reviewer requis, branche à jour avant fusion, approbation du dernier push
8/10	+ Au moins 1 check de statut CI requis
9/10	+ Au moins 2 reviewers, revue par les code owners avec un fichier `CODEOWNERS` présent
10/10	+ Invalidation des approbations après nouveau commit, admins inclus

Ces paliers sont séquentiels, et c'est la subtilité qui coûte le plus cher. Scorecard construit le score palier par palier et s'arrête au premier palier incomplet : tout ce qui est acquis au-dessus ne compte pas du tout. Lire le tableau comme un cumul partiel, « j'ai coché deux lignes sur cinq, j'ai donc une partie des points », donne une conclusion fausse.

Mesuré sur un dépôt au ruleset pourtant fourni : require_last_push_approval laissé à false suffit à bloquer le palier 6/10. Le score tombe à 5/10, et deux réglages nettement plus contraignants déjà activés, la revue par code owners et l'invalidation des approbations, ne rapportent rien tant que ce seul booléen manque.

Remédiation : Configurer un ruleset dans Settings > Rules > Rulesets, de préférence aux règles classiques de Settings > Branches. La raison est donnée plus bas, dans la section sur le jeton d'authentification : un ruleset se lit sans droit d'administration.

Code-Review

Risque : Vulnérabilités ou code malveillant non détectés.

Mesure si les changements passent par une revue humaine avant intégration. Analyse les 30 derniers commits pour vérifier qu'ils ont été approuvés.

Barème :

-7 points si un changement humain n'est pas revu
-3 points supplémentaires si plusieurs changements ne sont pas revus
-3 points si des changements de bots ne sont pas revus

Remédiation : Rendre les revues obligatoires via les règles de protection de branche.

Dangerous-Workflow

Risque : Compromission du dépôt (critique).

Détecte les patterns dangereux dans les workflows GitHub Actions :

Checkout non sécurisé : pull_request_target ou workflow_run avec checkout explicite de la PR, permet à l'auteur de la PR d'exécuter du code arbitraire avec les secrets du dépôt
Injection de script : Variables de contexte GitHub non sanitisées dans des scripts inline (ex: ${{ github.event.issue.title }})

Score 10/10 : Aucun pattern dangereux détecté.

Remédiation : Consulter le guide GitHub Security Lab et le guide OWASP Top 10 CI/CD.

Signed-Releases

Risque : Installation de releases malveillantes.

Vérifie que les releases sont signées cryptographiquement. Analyse les 5 dernières releases pour la présence de fichiers de signature.

Extensions recherchées : .minisig, .asc (PGP), .sig, .sign, .sigstore, .sigstore.json, .intoto.jsonl (SLSA).

Barème :

8/10 : Signature présente pour chaque release
10/10 : Attestation SLSA (.intoto.jsonl) présente

Remédiation : Utiliser Cosign pour signer les releases. Voir aussi SLSA.

Token-Permissions

Risque : Tokens avec permissions excessives.

Vérifie que les workflows GitHub Actions suivent le principe du moindre privilège pour les tokens GITHUB_TOKEN.

Score optimal : Permissions définies en read-only au niveau global, et permissions d'écriture déclarées uniquement au niveau des jobs qui en ont besoin.

# ✅ Bonne pratique
permissions:
  contents: read  # Par défaut en lecture seule

jobs:
  deploy:
    permissions:
      contents: write  # Écriture uniquement pour ce job

Remédiation : Utiliser l'outil StepSecurity pour déterminer les permissions minimales nécessaires.

Vulnerabilities

Risque : Vulnérabilités connues exploitables.

Vérifie via OSV (Open Source Vulnerabilities) si le projet ou ses dépendances ont des vulnérabilités ouvertes non corrigées.

Score : Dépend du nombre et de la sévérité des vulnérabilités détectées.

Remédiation : Corriger les vulnérabilités dans le code ou mettre à jour les dépendances vers des versions non vulnérables. Voir le guide CVE, CVSS et EPSS pour prioriser.

Checks de qualité de build

CI-Tests

Risque : Bugs et vulnérabilités non détectés.

Vérifie si le projet exécute des tests automatisés avant de merger les PR. Analyse les 30 derniers commits pour la présence de checks CI.

Systèmes détectés : GitHub Actions, Travis CI, CircleCI, Jenkins, AppVeyor, BuildKite, Woodpecker, et tout système contenant "test" ou "e2e" dans le nom.

Score 10/10 : Tous les commits récents sont passés par des tests CI.

Remédiation : Intégrer des tests avec GitHub Actions ou un autre système CI.

Dependency-Update-Tool

Risque : Dépendances obsolètes avec vulnérabilités connues.

Vérifie si le projet utilise un outil de mise à jour automatique des dépendances.

Outils détectés :

Score 10/10 : Fichier de configuration d'un de ces outils détecté.

Remédiation : Activer Dependabot dans les paramètres GitHub ou configurer Renovate à la racine du projet.

Fuzzing

Risque : Vulnérabilités non découvertes dans le code.

Vérifie si le projet utilise le fuzzing (tests avec données aléatoires) pour découvrir des bugs.

Méthodes détectées :

Inclusion dans OSS-Fuzz
ClusterFuzzLite dans le dépôt
Tests de fuzzing natifs Go (func FuzzXxx)
Bibliothèques de property-based testing (QuickCheck, fast-check, FsCheck...)

Remédiation : Intégrer le projet à OSS-Fuzz ou utiliser le fuzzing natif du langage. Pour écrire les harnais concrets qui satisfont ce contrôle, voir les guides pratiques en Python avec Atheris et en Go natif.

Pinned-Dependencies

Risque : Dépendances compromises (attaque supply chain).

Vérifie que les dépendances sont épinglées sur des hashes plutôt que des versions ou tags mutables.

Éléments analysés :

Actions GitHub (doivent utiliser un SHA, pas @v1)
Images Docker (doivent utiliser un digest)
Dépendances dans les scripts shell et Dockerfiles

# ❌ Tag mutable - peut changer sans préavis
- uses: actions/checkout@v4

# ✅ SHA épinglé - immuable, version en commentaire
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1

Remédiation : Utiliser StepSecurity pour épingler automatiquement les actions. Utiliser Renovate avec pinDigests: true pour les images Docker.

SAST

Risque : Bugs et vulnérabilités dans le code source.

Vérifie si le projet utilise l'analyse statique de sécurité (SAST) sur les PR.

Outils détectés :

CodeQL (github-code-scanning)
SonarCloud
Action github/codeql-action dans les workflows

Remédiation : Activer CodeQL via Settings > Security > Code scanning ou ajouter l'action github/codeql-action dans un workflow.

Checks de gouvernance

CII-Best-Practices

Risque : Non-respect des bonnes pratiques de sécurité.

Vérifie si le projet a obtenu un badge OpenSSF Best Practices.

Barème :

2/10 : Badge en cours d'obtention
5/10 : Badge "Passing"
7/10 : Badge "Silver"
10/10 : Badge "Gold"

Remédiation : S'inscrire sur bestpractices.dev et remplir le questionnaire. Ce dernier compte 67 critères au niveau passing : la marche à suivre pour ne pas y passer la journée est détaillée dans Obtenir le badge OpenSSF Best Practices sans y passer la journée.

Contributors

Risque : Projet dépendant d'une seule organisation.

Vérifie si le projet a des contributeurs de plusieurs organisations différentes (basé sur le champ "Company" des profils GitHub).

Score 10/10 : Au moins 3 organisations différentes parmi les 30 derniers commits, avec au moins 5 commits chacune.

Remédiation : Encourager les contributeurs à renseigner leur organisation dans leur profil GitHub.

License

Risque : Obstacle à l'audit de sécurité et risque juridique.

Vérifie la présence d'une licence dans le dépôt.

Barème :

6/10 : Fichier LICENSE, COPYING ou COPYRIGHT détecté
9/10 : + Fichier à la racine du projet
10/10 : + Licence reconnue FSF ou OSI (identifiant SPDX)

Remédiation : Ajouter un fichier LICENSE à la racine avec une licence SPDX.

Maintained

Risque : Vulnérabilités non corrigées dans un projet abandonné.

Évalue l'activité récente du projet sur les 90 derniers jours.

Score 10/10 : Au moins 1 commit par semaine sur les 90 derniers jours.

Score partiel : Activité sur les issues par des collaborateurs/mainteneurs.

Score 0 : Projet archivé.

Security-Policy

Risque : Signalement non sécurisé des vulnérabilités.

Vérifie la présence d'un fichier SECURITY.md expliquant comment signaler les vulnérabilités de façon responsable.

Barème :

6/10 : Email ou URL de contact présent
9/10 : + Texte explicatif au-delà des simples liens
10/10 : + Mentions de délais de divulgation (ex: "90 days")

Remédiation : Créer un fichier SECURITY.md à la racine avec les instructions de signalement. Sur GitHub, utiliser Settings > Security > Security advisories.

Autres checks

Packaging

Vérifie si le projet publie des packages via GitHub Packages ou des actions de publication vers npm, PyPI, etc.

SBOM (expérimental)

Vérifie la présence d'un SBOM dans le code source ou les artefacts de release.

Ce check n'est pas exécuté par défaut : il n'apparaît ni dans la sortie de la CLI ni dans la réponse de l'API securityscorecards.dev. Un lecteur qui cherche son score SBOM ne le trouvera pas, et ce n'est pas une erreur de configuration.

Webhooks (expérimental)

Vérifie que les webhooks configurés utilisent un secret pour authentifier les requêtes.

Ce check n'est pas exécuté par défaut non plus, et son poids est de 1 quand il l'est. C'est l'un des deux checks qui expliquent l'écart entre la vingtaine décrite ici et les 18 checks que rend l'API.

Intégration CI/CD

GitHub Actions

L'intégration native permet d'exécuter Scorecard automatiquement et de publier les résultats dans l'onglet Security de GitHub :

name: Scorecard Analysis

on:
  push:
    branches: [ "main" ]
  schedule:
    # Analyse hebdomadaire le dimanche à minuit
    - cron: '0 0 * * 0'

permissions:
  # Nécessaire pour publier les résultats
  security-events: write
  id-token: write

jobs:
  analysis:
    name: Scorecard analysis
    runs-on: ubuntu-24.04

    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Run analysis
        uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
        with:
          results_file: results.sarif
          results_format: sarif
          publish_results: true

      - name: Upload to code-scanning
        uses: github/codeql-action/upload-sarif@e4fba868fa4b1b91e1fdab776edc8cfbe6e9fb81  # v4.37.3
        with:
          sarif_file: results.sarif

GitLab CI

Pour GitLab, on utilise la CLI directement :

scorecard:
  stage: security
  image: gcr.io/openssf/scorecard:v5.5.0@sha256:b9a535801cb5fc8e7b2bea4cf45dd2db9a342cab8cc32bb5be2ac1355a95356f
  variables:
    GITHUB_AUTH_TOKEN: $GITLAB_TOKEN
  script:
    - scorecard --repo=gitlab.com/$CI_PROJECT_PATH --format=json > scorecard.json
  artifacts:
    reports:
      codequality: scorecard.json
    paths:
      - scorecard.json
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Afficher le badge de score

Après publication des résultats, on peut intégrer un badge dans le README pour montrer l'effort de sécurisation :

![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/mon-org/mon-projet/badge)

Le badge se met à jour automatiquement après chaque analyse.

Améliorer mon score

Commencez par lire votre rapport, pas cette liste. L'ordre optimal dépend de votre point de départ, et plusieurs de ces étapes peuvent ne rien rapporter du tout parce que le check est déjà au maximum. Mesuré sur cinq dépôts réels, les étapes 2, 3 et 5 étaient déjà à 10/10 quand le score global plafonnait à 6,9. Croisez donc votre rapport avec la table des poids donnée plus haut : un check à 10 qui traîne à 3 vaut dix fois un check à 1 qui traîne à 0.

Voici le plan d'action, par ordre de gain généralement décroissant :

Activer la protection de branche

Dans les paramètres GitHub, configurer :
- Revue obligatoire par au moins 1 personne
- Statuts CI requis avant merge
- Interdiction des force push
Épingler les dépendances

Remplacer tous les tags mutables par des SHA dans les workflows GitHub Actions et les Dockerfiles.
Signer les releases

Utiliser Cosign pour signer les artefacts et publier des attestations de provenance.
Activer Dependabot ou Renovate

Configurer la mise à jour automatique des dépendances pour recevoir les correctifs de sécurité.
Auditer les workflows

Vérifier l'absence de patterns dangereux et minimiser les permissions des tokens.

Obtenir le badge OpenSSF Best Practices sans y passer la journée

CII-Best-Practices est le seul check qu'aucun réglage du dépôt ne satisfait. Il lit une fiche hébergée sur bestpractices.dev, et cette fiche se remplit à la main : 67 critères au niveau passing, dont 43 obligatoires, relevés dans le fichier criteria/criteria.yml du projet. C'est le check dont la remédiation tient en une phrase et demande une demi-journée. Deux mécanismes officiels réduisent ce coût, et aucun des deux n'apparaît sur la page d'accueil du service. La documentation du BadgeApp est pourtant explicite sur l'ordre de préférence :

We do support POST for changing project data, but we generally recommend using automation proposals URLs or the .bestpractices.json file instead.

Pré-remplir avec `.bestpractices.json`

Déposé à la racine du dépôt, ou dans .project.d/bestpractices.json, ce fichier est lu par le service pour pré-remplir les réponses. Chaque critère y occupe deux clés, <critere>_status et <critere>_justification. Le statut accepte ?, N/A, Unmet ou Met, et un ? signifie « je ne sais pas » : il est ignoré entièrement, ce qui permet de livrer un fichier partiel sans rien casser et de le compléter au fil du temps.

{
  "release_notes_status": "Met",
  "release_notes_justification": "Chaque version publie ses notes sur la page Releases du dépôt",
  "floss_license_osi_status": "Unmet",
  "floss_license_osi_justification": "Le contenu est sous CC BY-SA 4.0, licence libre mais non approuvée par l'OSI",
  "warnings_status": "?"
}

Pré-remplir par une URL de proposition

Une URL d'édition transporte les réponses dans ses paramètres. Le service les affiche surlignées dans le formulaire, un humain relit, puis enregistre :

https://www.bestpractices.dev/en/projects/<ID>/passing/edit?release_notes_status=Met&release_notes_justification=...

Trois règles conditionnent le résultat, et aucune ne se devine :

Règle	Ce qui se passe sinon
La fiche doit exister au préalable	Une URL d'édition visant un dépôt non enregistré répond `404`. La recherche par URL ne crée aucune fiche.
Les noms de critères s'écrivent en tirets bas, jamais en points ni en crochets	La clé est ignorée en silence, sans le moindre message d'erreur.
Sans paramètre `overrides`, seuls les champs encore inconnus sont remplis	Sur un champ déjà renseigné, la proposition signale un désaccord et ne change rien.

Tout voyage dans la chaîne de requête, dont la longueur est bornée par le serveur : réservez la proposition d'URL à une poignée de critères, et passez par le fichier pour le questionnaire complet.

Deux pièges dans leur propre documentation

Ces deux détails coûtent une demi-heure chacun à qui les découvre seul. Le projet renvoie, depuis docs/api.md, vers un fichier basepractices-json.md qui n'existe pas : le bon nom est bestpractices-json.md. Et le fichier d'exemple docs/self.json porte encore description_sufficient et contribution_criteria, deux identifiants retirés du référentiel. Une clé périmée étant ignorée sans avertissement, un fichier recopié depuis cet exemple fonctionne à moitié sans que rien ne le signale.

Ce qui plafonne, et ce qui ne plafonne pas

Deux points évitent de chercher longtemps une erreur qui n'existe pas. Le critère release_notes est obligatoire : sans version publiée, le badge passing reste hors d'atteinte, quelles que soient les autres réponses. En revanche floss_license_osi, qu'une licence Creative Commons ne peut pas satisfaire puisqu'elle n'est pas approuvée par l'OSI, n'est que suggéré : y répondre Unmet en le justifiant suffit, le badge reste accessible. C'est une nuance qui compte pour un dépôt de contenu ou un catalogue de labs. Dernier point à anticiper, le questionnaire et les justifications s'écrivent en anglais, et d'autres les liront.

Trois checks hors de portée d'un mainteneur seul

Un projet personnel bien tenu plafonne structurellement autour de 7/10, et savoir pourquoi évite de chercher longtemps ce qu'on aurait mal fait. Trois checks, tous de poids élevé, ne dépendent pas de la rigueur du mainteneur mais de la taille de l'équipe.

Check	Pourquoi il résiste
Code-Review	Il compte les changesets approuvés. Outrepasser sa propre protection en tant qu'administrateur ne crée aucune approbation, et personne d'autre ne relit.
Maintained	Il pénalise tout dépôt de moins de 90 jours, quelle que soit l'activité. Le temps est le seul remède.
Contributors	Il compte les organisations distinctes parmi les contributeurs, pas les personnes. Un dépôt à un seul auteur ne peut pas monter.

Ces trois-là ne figurent pas dans le plan ci-dessus, et c'est volontaire : aucun réglage ne les débloque.

Scorecard dans une stratégie DevSecOps

Scorecard s'intègre naturellement dans une approche de sécurité supply chain plus large :

Outil	Rôle
Scorecard	Évaluer la posture sécurité des projets et dépendances
Trivy	Scanner les vulnérabilités dans les images et le code
Grype	Analyser les SBOM pour détecter les CVE
Cosign	Signer et vérifier les artefacts
Dependency Track	Suivre les vulnérabilités dans le temps

La combinaison de ces outils permet une défense en profondeur : Scorecard vérifie les pratiques de développement en amont, tandis que les scanners détectent les vulnérabilités dans les artefacts produits.

À retenir

Scorecard apporte une réponse objective à la question de la confiance dans un projet open source, en quelques secondes.
Analysez vos dépendances critiques avant adoption : un score inférieur à 5 doit alerter.
Branchez Scorecard dans votre CI/CD pour surveiller vos propres projets dans la durée, avec une planification hebdomadaire.
Les trois checks qui font bouger le score le plus vite sont Branch-Protection, Pinned-Dependencies et Token-Permissions.
Affichez le badge pour rendre visible l'effort de sécurité, et combinez Scorecard avec des scanners d'artefacts comme Trivy et Cosign pour une défense en profondeur.
Un bon score Scorecard ne garantit pas l'absence de vulnérabilités, mais il réduit significativement le risque de maintainer takeover et d'attaques supply chain comme celle de XZ Utils.
Preuve attendue par SOCLE-INT-VER-3 : une analyse de composition étendue, licences et score de maintenance compris. Le rapport JSON de scorecard --format json la constitue.

Pour aller plus loin

Après avoir maîtrisé Scorecard, approfondis ta stratégie supply chain :

Guides supply chain

Inventaire logiciel : Génère et exploite des SBOM avec Syft
Signature d'artefacts : Signe tes images et attestations avec Cosign
Framework SLSA : Implémente des niveaux de maturité avec SLSA
Risques OWASP : Consulte le Top 10 CI/CD Security Risks
Vue d'ensemble : Comprends les attaques supply chain

Scanners de vulnérabilités

Images et IaC : Trivy pour un scan complet
Conteneurs : Grype pour l'analyse des images Docker
Suivi continu : Dependency Track pour la gestion dans le temps

Détection de secrets

Git : Gitleaks et TruffleHog pour détecter les fuites
Fondamentaux : Gestion des secrets

Ressources

OpenSSF Scorecard - Documentation officielle
GitHub ossf/scorecard
GitHub Action Scorecard
Scorecard Monitor - Suivi multi-projets
Open Source Malware, Base de données communautaire des packages malveillants (npm, PyPI, NuGet)

OpenSSF Scorecard

Ce que vous allez apprendre

Qu'est-ce que OpenSSF Scorecard ?

Pourquoi c'est utile ?

Ce que Scorecard évalue

Installation

Utilisation de base

Configurer l'authentification GitHub

Analyser un projet GitHub

Comprendre la sortie

Formats de sortie

Les checks en détail

Le score global est une moyenne pondérée

Un check non évalué n'est pas un zéro

Checks critiques (risque élevé)

Binary-Artifacts

Branch-Protection

Code-Review

Dangerous-Workflow

Signed-Releases

Token-Permissions

Vulnerabilities

Checks de qualité de build

CI-Tests

Dependency-Update-Tool

Fuzzing

Pinned-Dependencies

SAST

Checks de gouvernance

CII-Best-Practices

Contributors

License

Maintained

Security-Policy

Autres checks

Packaging

SBOM (expérimental)

Webhooks (expérimental)

Intégration CI/CD

GitHub Actions

GitLab CI

Afficher le badge de score

Améliorer mon score

Obtenir le badge OpenSSF Best Practices sans y passer la journée

Pré-remplir avec .bestpractices.json

Pré-remplir par une URL de proposition

Deux pièges dans leur propre documentation

Ce qui plafonne, et ce qui ne plafonne pas

Trois checks hors de portée d'un mainteneur seul

Scorecard dans une stratégie DevSecOps

À retenir

Pour aller plus loin

Guides supply chain

Scanners de vulnérabilités

Détection de secrets

Ressources

Pré-remplir avec `.bestpractices.json`