OpenSSF Scorecard

Mise à jour : 14/12/2025

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.

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…

Dans ce guide, je présente :

Ce qu’évalue Scorecard et comment interpréter les résultats
L’installation et l’utilisation en ligne de commande
L’intégration dans les pipelines CI/CD
Les actions concrètes pour améliorer le score de mes projets

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.

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 ?

É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
docker run -it gcr.io/openssf/scorecard:stable --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 exécute 19 checks répartis en plusieurs catégories. Chaque check évalue un aspect spécifique 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.

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	+ Au moins 1 reviewer requis, PR obligatoire avant merge
8/10	+ Au moins 1 check de statut CI requis
9/10	+ Au moins 2 reviewers, revue par code owners
10/10	+ Invalidation des approbations après nouveau commit, admins inclus

Remédiation : Configurer les règles de protection dans *Settings > Branches

Branch protection rules* sur GitHub.

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.

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
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

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.

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

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

Webhooks

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

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-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
        with:
          persist-credentials: false

      - name: Run analysis
        uses: ossf/scorecard-action@62b2cac7ed8198b15735ed49ab1e5cf35480ba46
        with:
          results_file: results.sarif
          results_format: sarif
          publish_results: true

      - name: Upload to code-scanning
        uses: github/codeql-action/upload-sarif@17573ee1cc1b9d061760f3a006fc4c4f1698e080
        with:
          sarif_file: results.sarif

GitLab CI

Pour GitLab, on utilise le CLI directement :

scorecard:
  stage: security
  image: gcr.io/openssf/scorecard:stable
  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

Voici un plan d’action progressif pour améliorer le score d’un projet :

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.

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.

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

Conclusion

Scorecard apporte une réponse objective à la question de la confiance dans un projet open source. En quelques secondes, on obtient un diagnostic complet des pratiques de sécurité.

Ma checklist Scorecard :

Analyser mes dépendances critiques avant adoption (score > 5 minimum)
Intégrer Scorecard dans ma CI/CD pour surveiller mes propres projets
Améliorer progressivement mon score en suivant les recommandations
Afficher le badge pour montrer mon engagement sécurité
Combiner avec 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.

Ressources

OpenSSF Scorecard - Documentation officielle ↗
GitHub ossf/scorecard ↗
GitHub Action Scorecard ↗
Scorecard Monitor ↗ - Suivi multi-projets