OpenSSF Scorecard

OpenSSF Scorecard est un ensemble standard de vérifications automatisées de la posture de sécurité d’un dépôt open source. fremforge l’exécute chaque semaine sur chaque dépôt de votre organisation et affiche le résultat dans une colonne de /<org>/_admin/repos-overview.

Les vérifications

Les vérifications de Scorecard couvrent la sécurité du build, l’hygiène des vulnérabilités et la maturité du projet. Les principales :

• Branch-Protection : la branche par défaut est-elle protégée par des relectures et des vérifications de statut requises ?
• Code-Review : quelle part des fusions récentes a fait l’objet d’une revue de code ?
• Pinned-Dependencies : les dépendances de la CI sont-elles épinglées à des versions ou des SHA précis ?
• Token-Permissions : la CI utilise-t-elle des jetons au moindre privilège ?
• Signed-Releases : les artefacts de version sont-ils signés cryptographiquement ?
• SAST : le projet exécute-t-il un analyseur statique dans sa CI ?
• Vulnerabilities : l’arbre de dépendances contient-il des CVE connues ?
• Maintained : le dépôt connaît-il une activité récente de commits ou de tickets ?

Chaque vérification renvoie un score de 0 à 10. Le score global est la moyenne pondérée. Un 10 parfait est rare ; un « bon » score se situe entre 7 et 9.

Comment fremforge l’exécute

Scorecard n’est pas un workflow de CI par dépôt. Il s’exécute chaque semaine sur une infrastructure de plateforme isolée : aucun fichier de workflow n’arrive dans vos dépôts, et vous ne dépensez aucune minute de runner pour lui. Le mécanisme :

1. Une fois par semaine, fremforge met chaque tenant actif en file pour une analyse. Les tenants ayant une exécution en cours sont ignorés.
2. Une analyse est pilotée par un bot en lecture seule, propre à chaque tenant, qui peut lire vos dépôts mais pas y écrire.
3. L’analyse liste les dépôts du tenant et compare le HEAD actuel de la branche par défaut de chaque dépôt avec le HEAD enregistré lors de la dernière analyse. Les dépôts dont le HEAD n’a pas bougé sont ignorés : le score ne peut pas avoir changé, il n’y a donc rien à recalculer.
4. Pour chaque dépôt modifié, l’analyse le clone superficiellement dans un répertoire de travail temporaire sur une infrastructure de plateforme isolée, exécute le binaire scorecard --local sur la copie locale et stocke le JSON de score obtenu (y compris la nouvelle référence HEAD).
5. Les exécutions bloquées par un worker qui a planté sont remises à l’état d’échec, de sorte que le tenant est remis en file au prochain déclenchement hebdomadaire.

fremforge stocke le résultat par (tenant, repo) et affiche le score global dans une colonne de la page Dépôts (/<org>/_admin/repos-overview). Cliquez sur une ligne pour voir le détail par vérification.

L’API d’ingestion /scorecard/results existe toujours pour tout envoi externe ou piloté par un workflow, mais ce n’est plus le chemin par défaut : c’est l’analyse hebdomadaire côté plateforme décrite ci-dessus qui l’est.

Interpréter le score

Le score est un indicateur de tendance, pas un critère de conformité. Un dépôt noté 6,5 qui comprend une bibliothèque maintenue avec protection de branche et SAST est en bien meilleure forme qu’un dépôt noté 8 qui obtient simplement de bons résultats sur des vérifications cosmétiques.

Nous ne recommandons pas de brancher une condition « score Scorecard < X » sur une règle bloquant la fusion. Le bon endroit pour ce type de contrôle est :

• Branch-Protection en échec → corrigez-le sur /<org>/_admin/security/policies/repository-rules#org-baseline (déjà un signal distinct).
• SAST en échec → consultez /<org>/_admin/code-security (déjà un signal distinct).

Utilisez Scorecard pour observer l’écart entre des dépôts similaires : si acme/api obtient 8,5 et acme/web 6,5, d’où vient l’écart, et est-il voulu ?

Où s’exécute l’analyse : note sur la résidence des données

Le binaire scorecard lui-même est open source (Apache-2.0). L’analyse s’exécute sur une infrastructure de plateforme fremforge isolée et cloisonnée au niveau réseau (T Cloud Public, eu-de), et non dans vos runners de CI. Elle est pilotée par un bot en lecture seule, propre à chaque tenant, qui peut lire vos dépôts mais pas y écrire.

Ce que cela signifie pour vos données :

• Le clone est temporaire. L’analyse clone superficiellement chaque dépôt modifié dans un répertoire de travail temporaire, exécute scorecard --local sur cette copie locale, et supprime le répertoire de travail à la fin de l’exécution. Le code source n’est jamais conservé sur un stockage durable et ne quitte jamais la plateforme vers l’internet public : le bot récupère les données depuis le Forgejo de votre propre tenant via le réseau interne, et le binaire scorecard s’exécute en --local (aucun appel sortant vers des API de type GitHub pour les vérifications que nous exécutons).
• Seul le JSON des résultats de vérification est conservé. Ce que nous stockons par (tenant, repo), ce sont les scores par vérification et la référence HEAD analysée : aucun code source, aucun contenu de fichier, aucun extrait de commit.
• Tout reste dans eu-de. Le clone comme l’analyse s’exécutent au sein de la plateforme hébergée dans l’UE, conformément à la position de fremforge : aucun sous-traitant américain.

C’est un changement par rapport au modèle précédent, où scorecard s’exécutait comme workflow dans vos propres runners de CI. L’analyse s’exécute désormais sur l’infrastructure de fremforge ; les propriétés de résidence et de bot en lecture seule décrites ci-dessus sont la façon dont nous maintenons cette frontière étanche.

Voir aussi

• Protection de branche : détermine le score Branch-Protection.
• SBOM : détermine les scores Dependencies et Vulnerabilities.