Introduction : quand la confiance devient l’arme

En décembre 2020, le monde de la cybersécurité découvrait que SolarWinds, éditeur d’un logiciel de monitoring réseau utilisé par des milliers d’entreprises et d’agences gouvernementales américaines, avait été compromis à la source. Les attaquants — identifiés plus tard comme l’APT29 russe — avaient injecté une backdoor directement dans le processus de build. Les clients téléchargeaient une mise à jour signée numériquement, officielle en apparence, qui ouvrait une porte dérobée dans leurs systèmes. Ce n’était pas une faille dans le code de SolarWinds au sens classique : c’était une attaque contre le processus de fabrication du logiciel lui-même.

Quelques mois plus tard, en décembre 2021, la vulnérabilité Log4Shell (CVE-2021-44228) frappait avec une violence inédite. Log4j, une bibliothèque Java de journalisation omniprésente, se révélait exploitable à distance avec une simplicité désarmante. Le vrai problème n’était pas la faille en elle-même — c’était que des millions d’équipes ignoraient totalement utiliser Log4j dans leurs applications. Elle était enfouie à trois ou quatre niveaux de dépendances transitives, invisible, non inventoriée. Des entreprises ont mis des semaines à recenser tous leurs systèmes exposés, précisément parce qu’elles n’avaient aucune liste structurée de leurs composants logiciels.

Puis vint mars 2024 et l’affaire xz-utils (CVE-2024-3094). Un acteur malveillant, agissant sous une fausse identité construite sur plusieurs années, avait progressivement gagné la confiance des mainteneurs d’un utilitaire de compression Linux fondamental, pour finalement introduire une backdoor sophistiquée ciblant sshd sur les systèmes systemd. Seul un ingénieur chez Microsoft, intrigué par une légère anomalie de performance, l’a détectée par hasard, à quelques jours d’une distribution massive sur les systèmes Debian et Fedora. L’attaque était prête. Elle a failli passer.

Ces trois événements dessinent une tendance lourde qui structure le paysage de la sécurité en 2026 : les attaquants ne s’attaquent plus frontalement aux systèmes cibles. Ils remontent la chaîne d’approvisionnement logiciel — le code open source que vous intégrez, les images Docker que vous déployez, les pipelines CI/CD qui construisent vos artefacts — pour atteindre des milliers de victimes en une seule opération. C’est ce qu’on appelle une attaque supply chain, et elle est aujourd’hui considérée comme le vecteur de risque systémique numéro un par le NIST, l’ENISA et les principaux organismes de sécurité mondiaux.

Ce pilier vous donne la vue d’ensemble complète : pourquoi ce risque concerne aussi les PME d’Abidjan, de Dakar ou de Bamako, quels sont les quatre piliers d’une défense efficace, quels outils déployer concrètement dans votre pipeline, et comment adapter tout cela à la réalité opérationnelle de l’Afrique de l’Ouest. Chaque section renvoie vers un tutoriel satellite pour la mise en œuvre pas à pas.

Pourquoi se soucier de la supply-chain logiciel en PME

Une objection revient souvent dans les conversations avec des développeurs et responsables techniques en Afrique de l’Ouest : « Ces attaques visent les grandes entreprises américaines, pas nous. » Cette conviction est compréhensible, mais elle est fausse à plusieurs titres, et l’ignorer expose à des risques réels et croissants.

Premièrement, la chaîne d’approvisionnement logiciel est globale et partagée. Lorsqu’une faille est introduite dans une bibliothèque npm, Maven ou PyPI, elle affecte tous ceux qui en dépendent, quelle que soit leur géographie. Une startup fintech à Dakar utilisant une image Docker Node.js non mise à jour est exposée à exactement les mêmes CVE qu’une banque à New York. Le fait d’être « petit » ne confère aucune invisibilité — les scanners automatisés des attaquants ne font pas de discrimination géographique.

Deuxièmement, les PME africaines sont de plus en plus intégrées dans des écosystèmes qui exigent des garanties de sécurité. Les marchés publics sénégalais et ivoiriens intègrent progressivement des clauses de sécurité informatique dans les appels d’offres. L’ARTCI en Côte d’Ivoire et l’ADIE au Sénégal publient des référentiels de cybersécurité. Les partenaires internationaux — bailleurs, opérateurs télécoms, institutions financières — commencent à poser des questions sur les pratiques DevSecOps avant de signer des contrats. Avoir un SBOM (Software Bill of Materials) à jour n’est plus un luxe d’entreprise du CAC 40 : c’est une case à cocher dans les due diligences de partenariat.

Troisièmement, les coûts d’une compromission sont disproportionnés pour une PME. Quand SolarWinds a été touchée, l’entreprise avait les ressources pour mobiliser des dizaines d’experts en réponse à incident. Une PME de dix développeurs à Abidjan qui se retrouve avec une backdoor dans son application de paiement mobile n’a pas ces ressources. La prévention par des outils comme Trivy ou Falco coûte quelques heures de configuration ; la remédiation d’un incident majeur coûte des semaines, parfois la réputation de l’entreprise tout entière.

Quatrièmement, la pression réglementaire monte. Le règlement européen CRA (Cyber Resilience Act), entré en application progressive en 2026, impose des exigences de traçabilité des composants logiciels (SBOM) pour tout produit mis sur le marché européen. Les éditeurs africains qui exportent des solutions vers l’Europe ou travaillent avec des entreprises européennes devront s’y conformer. Ce n’est pas une hypothèse future : c’est une réalité contractuelle qui touche déjà les équipes les plus exposées à l’international.

Enfin, les outils de sécurité supply chain sont devenus accessibles. Trivy, CycloneDX, Cosign, Falco — ce sont tous des projets open source, gratuits, bien documentés, qui tournent sur un VPS Hetzner à 4 € par mois. Il n’y a plus d’excuse budgétaire à ne pas les déployer. Le seul investissement réel est du temps et de la connaissance — précisément ce que ce pilier et ses satellites vous apportent.

Les 4 piliers : SBOM, Signature, Scanning, Runtime

La défense de la supply chain s’articule autour de quatre briques complémentaires. Elles ne sont pas optionnelles : chacune adresse un vecteur d’attaque différent, et l’absence de l’une crée un angle mort que les trois autres ne compensent pas.

Pilier 1 — SBOM : savoir ce que vous embarquez

Le SBOM (Software Bill of Materials) est un inventaire structuré et exhaustif de tous les composants logiciels d’une application : bibliothèques directes, dépendances transitives, versions exactes, licences, hachages cryptographiques, origines. C’est l’équivalent de la liste d’ingrédients sur un produit alimentaire. Sans SBOM, vous ne pouvez pas savoir si vous utilisez Log4j 2.14.1, la version vulnérable. Avec un SBOM à jour, produit automatiquement à chaque build, vous pouvez en quelques secondes vérifier si votre application est exposée à n’importe quelle CVE nouvellement publiée.

Un SBOM peut être généré à différents niveaux : au niveau du code source (analyse des manifests npm/Maven/pip), au niveau de l’image container (analyse des couches Docker), ou au niveau du binaire déployé. Les formats standardisés sont CycloneDX (JSON/XML, maintenu par l’OWASP) et SPDX (maintenu par la Linux Foundation). Le standard CycloneDX est aujourd’hui le plus adopté dans les pipelines DevSecOps modernes grâce à son support outillage riche et son intégration native avec Dependency-Track.

Pilier 2 — Signature : vérifier l’authenticité des artefacts

Générer un SBOM ne suffit pas si n’importe qui peut le falsifier ou si vos images Docker peuvent être substituées en transit. La signature cryptographique des artefacts logiciels — images containers, binaires, SBOM eux-mêmes — garantit l’intégrité et l’authenticité de ce que vous déployez. Un artefact signé par un identifiant vérifié (une adresse email OIDC, un compte GitHub Actions) ne peut pas avoir été modifié après sa signature sans que la vérification échoue.

Sigstore est aujourd’hui l’infrastructure de référence pour cette problématique. Son composant Cosign gère la signature et la vérification d’images OCI, et son journal de transparence Rekor (l’équivalent de Certificate Transparency pour les artefacts logiciels) permet à n’importe qui de vérifier qu’une signature a bien été émise à un instant donné par une identité donnée. Aucune clé privée à gérer manuellement : Sigstore exploite les OIDC tokens d’identité déjà présents dans GitHub Actions, GitLab CI ou Google Cloud Build.

Pilier 3 — Scanning : détecter les vulnérabilités connues

Le scanning consiste à comparer le contenu de vos artefacts (images Docker, dépendances applicatives, fichiers de configuration) contre les bases de données de vulnérabilités connues : NVD (National Vulnerability Database), CVE Mitre, GitHub Advisory Database, mais aussi des sources spécialisées comme les advisories Red Hat, Debian ou Alpine. Un scanner CVE moderne ne se contente pas de lister les vulnérabilités ; il les priorise par criticité, indique si un correctif existe, et peut s’intégrer dans un pipeline CI pour bloquer un déploiement si une CVE critique est détectée.

Trivy, développé par Aqua Security et disponible en open source, est devenu le standard de facto du scanning supply chain. Il analyse en une seule commande les images Docker (toutes les couches), les systèmes de fichiers, les dépôts Git, les fichiers Terraform, les manifests Kubernetes, et produit des SBOM au format CycloneDX ou SPDX. Sa légèreté et sa vitesse en font l’outil idéal pour l’intégration CI/CD.

Pilier 4 — Runtime : détecter ce qui passe au travers

Même avec un SBOM, des signatures et un scanning rigoureux, il reste un angle mort : les attaques zero-day (vulnérabilités inconnues au moment du build), les comportements anormaux post-déploiement, et les techniques de compromission qui n’impliquent pas de CVE connue. C’est le domaine de la détection runtime. Plutôt que d’analyser les artefacts statiquement, on observe le comportement réel des processus en production : appels système inattendus, connexions réseau non déclarées, modifications de fichiers système, élévations de privilèges.

Falco, projet CNCF incubé par Sysdig, est le moteur de détection runtime open source de référence pour les workloads conteneurisés. Il se branche au niveau du noyau Linux (via eBPF ou le module noyau) et applique des règles déclaratives pour détecter les comportements suspects en temps réel. Une règle Falco peut par exemple alerter si un container exécute un shell interactif, télécharge un binaire depuis internet, ou lit un fichier /etc/shadow — autant de signaux d’une compromission en cours.

Outils du cluster

CycloneDX — génération de SBOM standardisés

CycloneDX est une spécification SBOM développée et maintenue par l’OWASP (Open Web Application Security Project), disponible à l’adresse cyclonedx.org. La spécification définit un schéma JSON et XML complet pour représenter un composant logiciel : identifiant PURL (Package URL), version, hachage SHA, licence SPDX, fournisseur, dépendances, vulnérabilités associées, et métadonnées de provenance (quel outil a généré le SBOM, à quelle date, depuis quel commit).

L’écosystème CycloneDX propose des générateurs pour pratiquement tous les langages et gestionnaires de paquets : cyclonedx-npm pour Node.js, cyclonedx-python pour pip/poetry, cyclonedx-maven-plugin pour Java, cyclonedx-gomod pour Go, et bien d’autres. Trivy peut également générer directement des SBOM CycloneDX lors de l’analyse d’une image Docker, ce qui permet de centraliser la génération SBOM dans le scanner CVE déjà présent dans votre pipeline.

Le format CycloneDX version 1.6 (en vigueur en 2026) introduit notamment le support des attestations — des déclarations vérifiables sur les pratiques de sécurité du processus de build — et des formulas, qui permettent de décrire précisément les étapes de compilation d’un artefact pour une reproductibilité complète. Ce sont ces fonctionnalités avancées qui permettent de répondre aux exigences du CRA européen et des appels d’offres gouvernementaux qui demandent une traçabilité totale de la chaîne de fabrication logicielle.

Sigstore + Cosign — signature transparente sans gestion de clés

Sigstore est une infrastructure open source fondée par Google, Red Hat et Purdue University, opérée par l’OpenSSF (Open Source Security Foundation), dont le service central est disponible à sigstore.dev. Sa proposition de valeur principale est de rendre la signature cryptographique des artefacts logiciels aussi simple que possible, sans les problèmes classiques de gestion de clés (rotation, révocation, stockage sécurisé, distribution).

Le composant Cosign est l’outil en ligne de commande de Sigstore pour signer et vérifier des images OCI, des fichiers, des SBOM et des attestations. Il supporte deux modes de signature : le mode « keyless » (sans clé), qui utilise les tokens OIDC émis par GitHub Actions, GitLab CI, Google Cloud ou Azure pour créer une signature éphémère rattachée à l’identité CI sans jamais stocker de clé privée ; et le mode avec clé explicite pour les environnements qui l’exigent. En mode keyless, chaque signature est automatiquement enregistrée dans Rekor, le journal de transparence immuable de Sigstore, ce qui permet à n’importe qui de prouver a posteriori qu’une image a été construite par tel pipeline à tel commit.

L’intégration de Cosign dans un pipeline GitHub Actions se résume à deux étapes : une action sigstore/cosign-installer pour installer l’outil, puis une commande cosign sign --yes après le push vers le registre. Du côté de Kubernetes, l’admission controller Policy Controller (également du projet Sigstore) peut bloquer tout déploiement d’une image non signée par une identité autorisée.

Trivy — scanner CVE universel

Trivy est développé par Aqua Security en open source et disponible à aquasec.com/products/trivy ainsi que sur GitHub. C’est aujourd’hui le scanner de vulnérabilités le plus utilisé dans les pipelines DevSecOps, grâce à sa polyvalence exceptionnelle : en une seule commande trivy image nginx:1.25, il analyse toutes les couches de l’image, les paquets OS (Alpine, Debian, Ubuntu, RHEL), les dépendances applicatives (npm, pip, Maven, Cargo, Composer), les fichiers de configuration (Kubernetes, Terraform, Dockerfile), et les secrets potentiellement exposés.

Trivy maintient sa propre base de données de vulnérabilités (trivy-db), mise à jour automatiquement depuis les sources NVD, GitHub Advisory Database, Red Hat Security Data, Debian Security Tracker et d’autres. En mode hors ligne (pertinent pour les environnements avec bande passante limitée), il est possible de télécharger la base de données une fois et de la mettre à cache localement. Trivy produit ses résultats en JSON, table terminal, SARIF (pour GitHub Code Scanning), ou directement au format SBOM CycloneDX/SPDX, ce qui en fait un couteau suisse complet.

Dans un pipeline CI/CD, on utilise typiquement la directive --exit-code 1 associée à --severity CRITICAL,HIGH pour faire échouer automatiquement le build si une vulnérabilité critique est détectée. Le flag --ignore-unfixed permet de ne bloquer que sur les CVE pour lesquelles un correctif existe, évitant les faux positifs qui paralysent les équipes.

Falco — détection runtime comportementale

Falco est un projet CNCF (Cloud Native Computing Foundation) en phase d’incubation avancée, disponible à falco.org, initialement développé par Sysdig. Il fonctionne en observant les appels système (syscalls) des processus sur un nœud Linux, soit via un module noyau, soit via une sonde eBPF (plus moderne et moins intrusif). Pour chaque syscall, il évalue un ensemble de règles déclaratives écrites en YAML/DSL Falco et génère une alerte si une règle est déclenchée.

Les règles Falco couvrent les patterns d’attaque les plus courants dans les environnements conteneurisés : exécution d’un shell dans un container (Terminal shell in container), écriture dans des chemins système sensibles (Write below etc), connexion réseau non attendue depuis un container (Unexpected outbound connection), utilisation de nsenter ou ptrace pour l’évasion de container, modification de fichiers binaires système en runtime. Ces règles par défaut couvrent les techniques MITRE ATT&CK les plus fréquentes et servent de base à une personnalisation selon votre environnement.

Les alertes Falco peuvent être routées vers un webhook, un topic Kafka, un endpoint Fluentd, ou directement vers un SIEM. En 2026, l’intégration Falco + OpenTelemetry permet d’enrichir les traces de sécurité avec le contexte runtime, offrant une corrélation puissante entre les alertes Falco et les logs applicatifs. Pour un déploiement Kubernetes, le chart Helm officiel de Falco est la méthode recommandée.

Renovate — mise à jour automatique des dépendances

Renovate est un outil open source de mise à jour automatique des dépendances, développé par Mend (ex-WhiteSource) et disponible sur GitHub. Là où un scanner CVE détecte les vulnérabilités dans vos dépendances actuelles, Renovate les prévient en maintenant ces dépendances à jour en continu. Il ouvre automatiquement des Pull Requests pour chaque mise à jour disponible — patch, minor ou major — avec un changelog intégré, des badges de compatibilité (basés sur les tests d’autres utilisateurs), et une configuration fine pour regrouper les mises à jour, planifier leur application, ou les soumettre à validation manuelle pour les changements majeurs.

Renovate supporte plus de 90 gestionnaires de paquets et formats de configuration, des package.json npm aux Dockerfiles en passant par les requirements.txt Python, les go.mod, les charts Helm, les Terraform providers, et même les GitHub Actions. Dans un pipeline sécurisé, Renovate joue le rôle de première ligne de défense : il garantit que vous ne restez jamais longtemps sur une version connue comme vulnérable, réduisant drastiquement la fenêtre d’exposition entre la publication d’une CVE et son correction dans votre code.

Dependency-Track — tracking centralisé des SBOM

Dependency-Track est une plateforme open source de gestion des risques liés aux composants logiciels, développée par l’OWASP et disponible sur GitHub. Elle ingère des SBOM au format CycloneDX ou SPDX, les indexe dans une base de données interne, et les corrèle en temps réel avec les bases de données de vulnérabilités (NVD, GitHub Advisories, OSS Index, Sonatype OSS). Son interface web offre un tableau de bord complet : nombre de composants, score de risque par projet, CVE détectées classées par criticité, licences problématiques (GPL dans un projet propriétaire, licences dépréciées), et politiques de sécurité configurables.

Dans une architecture multi-projets typique d’une PME ou d’une ESN africaine (plusieurs applications clients déployées en parallèle), Dependency-Track est indispensable pour avoir une vue centralisée du risque. Quand une nouvelle CVE est publiée dans la NVD, Dependency-Track re-corrèle automatiquement tous les SBOM ingérés et envoie des alertes pour tous les projets affectés — sans qu’il faille relancer un scan manuellement. C’est la différence entre une posture réactive (scanner quand on y pense) et une posture proactive (être alerté dès qu’un composant déjà déployé devient vulnérable).

Architecture d’une chaîne CI/CD sécurisée

Une pipeline CI/CD sécurisée supply chain ne se construit pas en ajoutant des outils au hasard : elle suit une logique séquentielle où chaque étape s’appuie sur les garanties de la précédente. Voici l’architecture recommandée, applicable aussi bien sur GitHub Actions que sur GitLab CI ou une installation Forgejo auto-hébergée.

La première étape est le scan de dépendances au commit. Dès qu’un développeur pousse du code, le pipeline exécute Trivy en mode système de fichiers (trivy fs .) sur le code source, analysant les manifests de dépendances (package.json, requirements.txt, go.mod, pom.xml) pour détecter les vulnérabilités dans les dépendances directes et transitives déclarées. Cette étape doit être rapide (moins de 2 minutes) et doit échouer immédiatement si une CVE critique avec correctif disponible est détectée. Renovate, configuré en parallèle sur le dépôt, ouvre automatiquement les PR de mise à jour.

La deuxième étape est la construction et génération SBOM. Une fois les tests passés, le Dockerfile est construit avec BuildKit. Immédiatement après, Trivy génère un SBOM CycloneDX de l’image produite (trivy image --format cyclonedx --output sbom.json ). Ce SBOM est l’inventaire définitif de ce qui sera déployé. Il est archivé comme artefact du pipeline avec un hachage SHA-256 attestant son intégrité.

La troisième étape est le scan CVE de l’image construite. Trivy analyse maintenant l’image Docker complète (trivy image --exit-code 1 --severity CRITICAL ), incluant toutes les couches OS et les dépendances applicatives. C’est ici que les failles dans l’image de base (par exemple une Ubuntu 22.04 avec des paquets système non mis à jour) seront détectées, que le scan de dépendances source n’aurait pas couvertes.

La quatrième étape est la signature de l’image et du SBOM. Cosign signe l’image avec l’identité OIDC du pipeline CI (cosign sign --yes ). Le SBOM lui-même est ensuite attaché à l’image sous forme d’attestation signée (cosign attest --predicate sbom.json --type cyclonedx ). À partir de ce moment, toute personne déployant cette image peut vérifier cryptographiquement qu’elle a bien été construite par ce pipeline, à ce commit, et que le SBOM attaché correspond bien à son contenu.

La cinquième étape est l’ingestion dans Dependency-Track. Le SBOM est envoyé via l’API REST de Dependency-Track, qui l’indexe et corrèle immédiatement avec les CVE connues. Si une nouvelle faille est publiée la semaine suivante dans un composant de ce SBOM, l’équipe sera alertée automatiquement sans avoir à relancer un scan.

La sixième étape est le déploiement avec vérification de signature. Dans l’environnement Kubernetes de production, le Policy Controller de Sigstore (ou Kyverno avec une politique de vérification Cosign) vérifie la signature de l’image avant tout déploiement. Un pod dont l’image ne porte pas de signature valide émise par l’identité CI autorisée est rejeté par l’admission controller. Cette étape garantit que rien ne peut être déployé en production sans être passé par la chaîne de fabrication sécurisée.

La septième étape, continue et perpétuelle, est la surveillance runtime avec Falco. Une fois en production, Falco observe en temps réel les comportements des containers. Les alertes critiques (shell dans un container, écriture dans /usr, appel à ptrace) sont routées vers le canal de sécurité Slack ou le SIEM de l’équipe. Les alertes de niveau warning alimentent un tableau de bord pour analyse périodique.

Cette architecture complète peut sembler ambitieuse, mais elle est parfaitement réalisable pour une équipe de 3-5 développeurs en quelques sprints. Les tutoriels du cluster vous guident étape par étape pour chaque composant.

Tutoriels du cluster (6 satellites)

Ce pilier est le hub du cluster secu-supplychain. Les six tutoriels pratiques ci-dessous couvrent chacun un composant de l’architecture décrite ci-dessus. Chaque satellite est un guide pas-à-pas de 2000+ mots avec les commandes testées, les configurations complètes et les erreurs fréquentes.

• Trivy : scanner vos images Docker pour les CVE en 15 minutes — Installation, intégration GitHub Actions, configuration des seuils d’alerte, export SARIF pour GitHub Security. Le point d’entrée recommandé pour débuter.
• Générer un SBOM CycloneDX dans votre pipeline CI — Génération par langage (npm, pip, Maven, Go), génération depuis une image Docker avec Trivy, archivage des SBOM comme artefacts CI, comparaison entre deux SBOM.
• Signer vos images Docker avec Cosign et Sigstore — Mode keyless avec GitHub Actions OIDC, vérification de signature avant déploiement, attachement du SBOM comme attestation signée, vérification avec Cosign verify-attestation.
• Dependency-Track : tableau de bord SBOM self-hosted — Installation Docker Compose, import SBOM via API, configuration des notifications CVE, intégration avec la pipeline CI pour ingestion automatique.
• Falco : détection d’intrusion runtime sur Kubernetes — Installation via Helm, comprendre les règles par défaut, écrire des règles personnalisées, router les alertes vers Slack/webhook, tester avec des attaques simulées.
• Renovate : automatiser les mises à jour de dépendances — Configuration de base sur GitHub, groupage des mises à jour, planification hebdomadaire, automerge pour les patchs, intégration avec les checks de sécurité Trivy.

Adaptation au contexte ouest-africain

La sécurité supply chain n’est pas un concept abstrait réservé aux équipes SRE des géants de la Silicon Valley. Elle touche concrètement les équipes techniques d’Abidjan, de Dakar, de Lomé ou de Cotonou qui déploient des applications sur des VPS Hetzner, OVH Roubaix, ou des infrastructures cloud émergentes comme Africa Data Centres. Voici comment l’adapter à la réalité opérationnelle et réglementaire de la sous-région.

SBOM dans les appels d’offres publics au Sénégal et en Côte d’Ivoire

Les marchés publics IT en Afrique de l’Ouest évoluent rapidement. Au Sénégal, la Direction de l’Informatique de l’État (DIE) et l’Agence de l’Informatique de l’État (ADIE) ont publié un référentiel de sécurité des systèmes d’information qui intègre progressivement les bonnes pratiques DevSecOps. En Côte d’Ivoire, l’ARTCI (Autorité de Régulation des Télécommunications et du Numérique) impose aux opérateurs de services numériques critiques des audits de sécurité périodiques qui incluent désormais la traçabilité des composants logiciels déployés.

Concrètement, si vous répondez à un appel d’offres pour un système d’information gouvernemental sénégalais ou ivoirien en 2026, avoir un SBOM à jour pour votre application est un avantage compétitif réel. Certains cahiers des charges commencent à demander explicitement une « liste des composants logiciels tiers utilisés avec leurs versions et licences ». Un SBOM CycloneDX répond exactement à cette demande de manière formelle et vérifiable. Les équipes qui peuvent produire ce document en quelques secondes à partir de leur pipeline CI se distinguent de celles qui passent des jours à construire manuellement une liste Excel approximative.

La conformité au cadre CSF (Cybersecurity Framework) du NIST, que certaines institutions financières et telcos africains adoptent comme référence, inclut la fonction « Identify » qui couvre explicitement la gestion de l’inventaire des actifs logiciels. Un SBOM outillé avec Dependency-Track constitue une réponse directe et auditables à cette exigence.

Scanning de containers déployés sur Hetzner et OVH

La majorité des startups et PME tech d’Afrique de l’Ouest hébergent leurs workloads sur des VPS Hetzner (Falkenstein, Nuremberg, Helsinki) ou OVH (Roubaix, Gravelines). C’est un choix rationnel : prix imbattables, qualité réseau excellente, facturation en euros compatible avec les contraintes de transfer de devises. Dans ce contexte, le déploiement de Trivy ne nécessite aucune infrastructure spéciale — c’est un binaire statique de moins de 100 Mo qui s’installe en une ligne et s’exécute localement sur le VPS.

Pour les équipes avec une bande passante limitée ou des coûts de transfert élevés, deux optimisations sont importantes : premièrement, utiliser le cache local de la base de données Trivy (trivy image --cache-dir /opt/trivy-cache) pour ne télécharger la base de vulnérabilités qu’une fois par semaine plutôt qu’à chaque scan. Deuxièmement, dans les pipelines CI hébergés sur des runners auto-hébergés au Sénégal ou en Côte d’Ivoire, configurer un miroir local de la trivy-db réduit les dépendances réseau vers l’Europe ou l’Amérique du Nord, améliorant la fiabilité des builds dans les environnements où la connexion internet peut être intermittente.

Pour Falco sur un VPS Hetzner ou OVH sous Ubuntu 22.04, l’installation via les packages officiels Falco est recommandée. Le driver eBPF est préféré au module noyau car il ne nécessite pas de recompilation si le noyau est mis à jour par les outils de sécurité automatiques d’Ubuntu. Sur un VPS Hetzner à 4 CPUs, Falco en mode eBPF consomme typiquement moins de 3 % de CPU et 150 Mo de RAM — parfaitement raisonnable pour un serveur de production.

Opérer en mode dégradé pendant les coupures

Une contrainte spécifique au contexte africain est la fiabilité électrique et réseau. Les pipelines CI/CD doivent être conçus pour tolérer une coupure internet temporaire. Trivy en mode cache local, Dependency-Track déployé on-premise, et un registre Docker privé (Harbor ou Gitea sur le VPS) permettent de continuer à construire et déployer des images même sans connexion vers les registres publics Docker Hub ou GitHub Container Registry. Cette résilience est un bénéfice secondaire de l’approche supply chain sécurisée self-hosted.

Erreurs fréquentes à éviter

FAQ

Pour aller plus loin

Ce pilier vous a donné la vue d’ensemble architecturale. Pour passer à la mise en œuvre concrète, les six tutoriels satellites du cluster vous attendent avec les configurations complètes et les commandes testées :

• Point d’entrée recommandé : Trivy : scanner vos images Docker pour les CVE en 15 minutes — commencez ici pour un gain immédiat.
• Deuxième étape : Renovate : automatiser les mises à jour de dépendances — la prévention continue des CVE connues.
• Pour aller plus loin côté traçabilité : Générer un SBOM CycloneDX dans votre pipeline CI et Dependency-Track self-hosted.
• Sécurisation avancée : Signer vos images Docker avec Cosign et Falco : détection runtime.

Références et sources primaires

• cyclonedx.org — Spécification CycloneDX, schémas JSON/XML, outils de génération par langage
• sigstore.dev — Documentation Cosign, Rekor, Fulcio, guides d’intégration CI/CD
• aquasec.com/products/trivy — Documentation Trivy, référence des flags, guides d’intégration
• falco.org — Documentation Falco, bibliothèque de règles, guides d’installation Helm
• OWASP Dependency-Track — Documentation officielle, API REST, guides de déploiement
• docs.renovatebot.com — Documentation Renovate, référence de configuration
• NVD NIST — Base de données nationale des vulnérabilités, source primaire CVE
• slsa.dev — Framework SLSA (Supply chain Levels for Software Artifacts) de Google

Formation ITSkillsCenter

ITSkillsCenter propose des formations DevSecOps adaptées aux équipes d’Afrique de l’Ouest : déploiement de pipelines sécurisés, configuration de Trivy/Falco en production, audit de SBOM. Découvrir la formation DevSecOps.