Vous avez un pipeline GitHub Actions, des dépendances npm et des images conteneurs, et pas d'équipe sécurité dédiée. Cette page donne le chemin court : les premiers contrôles SOCLE de niveau R1 (les fondamentaux) à mettre en place, dans l'ordre de la chaîne, du poste du développeur au déploiement. Pour chacun : l'exigence, l'action concrète, la preuve à conserver et un outil open source. Cochez les contrôles au fur et à mesure : votre progression est suivie et conservée sur cet appareil.
R1-R3 et M0-M4 : deux échelles à ne pas confondre
Section intitulée « R1-R3 et M0-M4 : deux échelles à ne pas confondre »SOCLE manipule deux gradations qu'on mélange souvent. L'une qualifie l'exigence, l'autre qualifie votre organisation.
- R1 / R2 / R3 : le niveau de l'exigence, c'est-à-dire la hauteur de la barre. R1 est fondamental (à faire d'abord), R2 renforcé, R3 souverain. C'est une propriété fixe de chaque exigence. Ce parcours ne couvre que les R1.
- M0 à M4 : votre maturité, c'est-à-dire où vous en êtes dans la transformation. De M0 (rien de formalisé) à M4 (mesuré et amélioré en continu). C'est une propriété de votre organisation, qui progresse dans le temps.
Autrement dit : R indique quoi viser, M indique où vous en êtes. On vise d'abord le niveau R1 ; la maturité monte à mesure que ces exigences sont réellement satisfaites, prouvées et tenues dans la durée, pas seulement cochées une fois.
On ne sécurise bien que ce qu'on a nommé. Avant tout outil, deux décisions de gouvernance posent le cadre : inventorier ses produits et chaînes de build, avec un tiering par criticité (tout ne mérite pas le même effort), et désigner qui est responsable de la sécurité dans chaque équipe. Sans ce cadrage, les contrôles techniques s'empilent sans priorité, et personne ne les tient dans la durée.
Ces décisions ne demandent aucun outil, seulement des documents vivants : un inventaire daté, une politique courte, une matrice de rôles. C'est ce qui transforme une checklist en démarche pilotée.
La chaîne commence sur le poste du développeur et sur ses comptes. Un identifiant GitHub ou npm détourné, un token volé sur une machine non durcie, et l'attaquant publie du code légitime aux yeux du système : il a contourné tous les garde-fous d'aval. Les compromissions de mainteneurs par vol de compte npm suivent exactement ce schéma.
Deux réflexes couvrent l'essentiel : une identité forte (MFA partout, fin des droits admin permanents) et une hygiène locale qui empêche un secret de fuiter dans un commit et garantit que les commits sont bien signés.
Une application npm tire des centaines de dépendances transitives : c'est la porte d'entrée numéro un des attaques supply chain (typosquatting, paquet piégé, mainteneur compromis comme event-stream). On ne se protège pas en lisant le code de chaque paquet, mais en figeant et en analysant.
Figer avec un lockfile versionné et npm ci garantit que le même commit produit le même arbre de dépendances. Analyser (SCA) à chaque build, avec un seuil bloquant sur les vulnérabilités critiques exploitables, empêche une faille connue de filer en production.
npm ci (reproductible). Des dépendances saines ne sauvent pas d'un défaut dans votre propre code : une injection, un contrôle d'accès défaillant, un secret en dur. Ces classes de failles restent les plus exploitées en production.
Le SAST intégré au pipeline les attrape au plus tôt, à chaque build, là où la correction coûte le moins cher. L'enjeu n'est pas d'avoir un rapport de plus, mais de bloquer sur les criticités hautes et de conserver la preuve.
Sécuriser GitHub Actions ne se limite pas au fichier YAML. La plateforme CI/CD exécute du code avec des secrets et des droits : c'est une cible de choix. L'incident tj-actions de 2025 a montré qu'une seule action tierce non maîtrisée peut compromettre des milliers de pipelines.
Trois leviers : durcir la plateforme et revoir les accès (CIS), réduire les permissions au minimum en empêchant tout contournement des contrôles, et épingler images et outils CI par digest (jamais latest) pour qu'un tag réécrit ne livre pas du code malveillant.
latest). À la sortie du build, l'artefact part vers la production : il faut savoir ce qu'il contient et vérifier qu'il est sain avant de le publier. Sans inventaire, une vulnérabilité de dépendance reste invisible jusqu'à l'incident (l'effet Log4Shell).
Le SBOM (CycloneDX ou SPDX) généré par artefact donne cet inventaire ; le scan avant publication couvre les CVE mais aussi les secrets et le malware, pas seulement les vulnérabilités connues, et bloque ce qui ne doit pas sortir.
Un artefact non signé est interchangeable : rien ne prouve qu'il vient bien de votre source et de votre build. La signature et la provenance ferment cette faille en liant l'artefact à son origine vérifiable.
Signer avec cosign, générer une provenance in-toto, puis vérifier l'intégrité avant toute promotion : c'est la base de SLSA. Attention, la provenance prouve l'origine, pas l'innocuité ; elle se combine aux étapes précédentes.
Dernière barrière avant la production : ne laisser entrer que ce qui est signé et conforme. C'est le contrôle d'admission qui refuse une image non signée ou non scannée, même si tout le reste a été contourné en amont.
On sépare aussi les privilèges de déploiement : le CI ne doit pas disposer d'un accès direct et non contrôlé à la production. Hors Kubernetes, le principe reste le même : une porte d'entrée unique, vérifiée et tracée.
À retenir
Section intitulée « À retenir »- Ce parcours couvre 19 contrôles R1 essentiels, du cadrage (gouvernance : inventaire, politique, ownership) au déploiement, dans l'ordre de la chaîne.
- La priorité absolue : dépendances (lockfile, SCA bloquant) et GitHub Actions (durcissement, images par digest). Meilleur rapport effort/risque.
- Chaque contrôle produit une preuve : c'est elle qui rend la posture auditable, pas l'outil.
- Une fois ces R1 en place, montez en R2/R3 domaine par domaine via le référentiel.