La sécurité ne s'improvise pas et ne s'achète pas en boîte noire. Elle se construit méthodiquement : on part des menaces réelles, on en déduit des exigences hiérarchisées, on les met en œuvre avec les bons outils, puis on les prouve. Cette section applique ce fil rouge, du système d'exploitation jusqu'à l'artefact déployé, en suivant la démarche que je formalise dans SOCLE.
Le fil rouge : de la menace à la preuve
Section intitulée « Le fil rouge : de la menace à la preuve »Trop souvent, la sécurité se résume à empiler des outils sans cohérence : un scanner par-ci, un pare-feu par-là, sans savoir ce qu'on cherche vraiment à garantir. J'inverse cette logique avec une démarche en quatre temps, valable quel que soit le domaine :
- Comprendre la menace : contre quoi se défend-on ? Quel attaquant, quelle cible, quel vecteur ?
- Définir l'exigence : ce qui DOIT être vrai, formulé de façon opposable et ancrée dans un référentiel reconnu (ANSSI, CIS, SLSA, SSDF), pas de mémoire.
- Mettre en œuvre : choisir l'outil open source qui satisfait l'exigence, jamais l'inverse.
- Prouver : produire la preuve d'audit attendue (configuration, attestation, rapport de scan), parce qu'une sécurité non vérifiable n'est qu'une intention.
Cette démarche est le cœur de SOCLE (Sécurité de la Chaîne Logicielle), la norme ouverte que je construis. SOCLE formalisera d'abord la chaîne logicielle ; mais sa méthode (exigence ancrée, preuve, hiérarchie de niveaux) sert ici de grille de lecture à toute la section.
Trois niveaux de robustesse (R1 → R2 → R3)
Section intitulée « Trois niveaux de robustesse (R1 → R2 → R3) »Toutes les organisations n'ont pas les mêmes besoins. Plutôt qu'un objectif unique et décourageant, la démarche propose trois niveaux croissants. On commence par R1, atteignable partout, et on monte selon la criticité.
| Niveau | Esprit | Exemples transverses |
|---|---|---|
| R1 Fondamental | L'hygiène atteignable par toute équipe | MFA, moindre privilège, mises à jour, secrets hors de Git, scan de base |
| R2 Renforcé | Les exigences d'un service en production | Durcissement CIS/ANSSI, détection d'intrusion, SBOM, signature et vérification, coffre à secrets |
| R3 Souverain | Les contextes sensibles ou réglementés | Isolation forte, provenance non falsifiable, air-gap, forensics, alignement ANSSI/SecNumCloud |
L'intérêt de ces niveaux est de prioriser : inutile de viser le souverain sur un outil interne, mais une application de paiement visera R2 voire R3. Chaque guide de cette section précise, quand c'est pertinent, à quel niveau se situe la pratique décrite.
Appliquer la démarche, domaine par domaine
Section intitulée « Appliquer la démarche, domaine par domaine »Les domaines ci-dessous sont les terrains où l'on déroule le même cycle menace → exigence → outil → preuve. Ils sont autonomes : commencez par celui qui répond à votre besoin immédiat.
Fondations : principes et menaces
Section intitulée « Fondations : principes et menaces »Avant tout outil, deux fondations. D'abord les principes qui guident chaque décision : le moindre privilège n'accorde que les droits nécessaires, la minimisation réduit la surface d'attaque, et le Zero Trust ne fait confiance à personne par défaut (voir l'ensemble des principes fondamentaux). Ensuite, connaître l'ennemi : le profil des attaquants, les phases d'une attaque (la kill chain) et les GTFObins qui détournent des binaires légitimes. C'est l'étape « comprendre la menace » appliquée à tout le reste (voir toutes les menaces).
Durcir le système d'exploitation
Section intitulée « Durcir le système d'exploitation »Le durcissement système est le socle. L'exigence s'ancre dans des référentiels reconnus : ANSSI-BP-028 côté français, CIS Benchmarks côté international. Concrètement, on sécurise SSH et PAM, on prouve la posture en auditant avec Lynis et OpenSCAP, et on confine les processus avec SELinux ou AppArmor. À l'extrême R3, l'immuabilité avec NixOS rend la configuration déclarative, reproductible et auditable.
Protéger le réseau
Section intitulée « Protéger le réseau »La protection réseau se déroule en couches. Les pare-feux filtrent le trafic avec UFW ou Firewalld. La détection d'intrusion (CrowdSec, Snort, AIDE) produit la preuve qu'un comportement suspect est repéré. Et pour investiguer, les outils d'analyse (Nmap, TCPDump, Netcat) vérifient concrètement vos règles.
Analyser le code et les vulnérabilités
Section intitulée « Analyser le code et les vulnérabilités »L'analyse de sécurité couvre l'exigence « pas de secret exposé, pas de faille connue ». La détection de secrets avec Gitleaks et TruffleHog évite les fuites de credentials. Le scan avec Nuclei et Dependency-Track identifie les failles ; l'analyse d'images avec Trivy, Grype et Dockle sécurise les builds ; Checkov vérifie l'Infrastructure as Code. Le système CVE/CVSS/EPSS priorise les correctifs selon le risque réel.
Maîtriser la chaîne logicielle
Section intitulée « Maîtriser la chaîne logicielle »C'est ici que SOCLE est le plus directement à l'œuvre : prouver l'intégrité du code jusqu'à l'artefact. Le framework SLSA définit les niveaux de provenance des builds, l'OWASP Top 10 CI/CD recense les risques des pipelines, et Cosign signe cryptographiquement les images. Côté conteneurs, Kubescape vérifie la conformité Kubernetes (NSA, MITRE) et NeuVector assure la protection runtime. La démarche SOCLE relie ces briques en exigences opposables.
Gérer les secrets
Section intitulée « Gérer les secrets »Les secrets (mots de passe, clés API, certificats) sont une cible prioritaire. L'exigence R1 est simple : jamais en clair dans Git. HashiCorp Vault centralise et fait tourner les credentials, SOPS chiffre les secrets versionnés, Infisical propose une alternative moderne. Pour les équipes, Bitwarden et Passbolt gèrent les mots de passe partagés.
Assurer la résilience
Section intitulée « Assurer la résilience »La résilience fait partie de la sécurité : un service indisponible est un service vulnérable. Corosync et Pacemaker orchestrent le clustering haute disponibilité et DRBD réplique les disques en temps réel entre serveurs.
Comment progresser, étape par étape
Section intitulée « Comment progresser, étape par étape »Chaque guide est autonome, mais pour une montée en compétences cohérente, appliquez la démarche dans cet ordre :
-
Identifiez la menace prioritaire : serveurs non durcis, secrets dans le code, conteneurs non scannés ? Partez du risque réel, pas de l'outil à la mode.
-
Posez les principes : sans cette base, vous empilez des outils sans cohérence. Commencez par les fondamentaux.
-
Fixez votre niveau cible : R1 partout d'abord, R2 sur la production, R3 sur le sensible. C'est votre exigence.
-
Mettez en œuvre un domaine à la fois : durcissement, puis réseau, puis analyse de code, puis secrets. Terminez chaque domaine avant le suivant.
-
Automatisez : un scan manuel oublié ne sert à rien. Intégrez les contrôles dans vos pipelines CI/CD.
-
Produisez la preuve : rapport Lynis/OpenSCAP, SBOM, provenance signée, règles de pare-feu testées. La preuve est l'exigence rendue vérifiable.
-
Restez en veille : suivez les CVE critiques, les nouvelles techniques et les mises à jour d'outils. Les menaces évoluent, vos exigences aussi.
Valider ses compétences en sécurité
Section intitulée « Valider ses compétences en sécurité »La sécurité se prouve par la pratique. Voici comment mesurer votre progression :
| Domaine | Validation | Certification associée |
|---|---|---|
| Durcissement Linux | Labs + Examens Linux | RHCSA |
| Sécurité Kubernetes | Labs + Examens K8s | CKS |
| Supply chain | Labs Cosign, Kyverno | CKS |
| Sécurité réseau | Labs OPNsense + Homelab | Aucune |
Prochaines étapes
Section intitulée « Prochaines étapes »La sécurité n'est pas une destination, c'est un processus continu. Avancez étape par étape : chaque exigence prouvée est une amélioration qui compte.