Supply-chain applicative (typosquatting, dependency

Cet article constitue une ressource technique complete sur Supply-chain applicative (typosquatting, dependency, couvrant les fondamentaux theoriques, les aspects pratiques d'implementation et les considerations avancees pour les environnements de production. Les professionnels y trouveront des guides etape par etape, des exemples concrets et des recommandations issues de retours d'experience terrain. L'analyse integre les dernieres evolutions du domaine et propose des perspectives sur les tendances a suivre pour les mois a venir. Les bonnes pratiques presentees sont directement applicables et ont ete validees dans des contextes operationnels reels. Les implications de cette evolution pour le secteur sont multiples, touchant aussi bien les aspects techniques que les dimensions strategiques, reglementaires et organisationnelles des entreprises concernees. L'analyse des experts du domaine souligne l'importance d'une veille continue et d'une adaptation rapide des pratiques pour tirer parti des opportunites tout en maitrisant les risques associes a ces changements.

Cette analyse technique de Supply-chain applicative (typosquatting, dependency s'appuie sur les retours d'experience d'equipes confrontees quotidiennement aux defis operationnels du domaine. Les methodologies presentees couvrent l'ensemble du cycle de vie, de la conception initiale au deploiement en production, en passant par les phases de test et de validation. Les recommandations sont directement applicables dans les environnements professionnels.

Résumé exécutif

Les attaques de supply-chain applicative ciblent la chaîne de développement en exploitant les dépendances logicielles : packages open source, modules internes, registres privés. Des campagnes de typosquatting, dependency confusion et de compromission de registres ont démontré la vulnérabilité des pipelines CI/CD et des applications en production. Cet article dissèque ces menaces, propose des stratégies pour bâtir une Software Bill of Materials (SBOM), verrouiller les registres et intégrer des analyses SCA (Software Composition Analysis) dans les pipelines. L'objectif est de fournir une approche opérationnelle et outillée afin de détecter, prévenir et répondre aux risques supply-chain tout au long du cycle de vie du logiciel. Cet article fournit une analyse technique approfondie et des recommandations pratiques pour les professionnels de la cybersecurite. Les concepts presentes sont issus de retours d'experience terrain et des meilleures pratiques du secteur. Les equipes techniques y trouveront des methodologies eprouvees, des outils recommandes et des strategies de mise en oeuvre adaptees aux environnements de production modernes. La maitrise de ces sujets est devenue incontournable dans le contexte actuel de menaces en constante evolution.

Panorama des menaces supply-chain

1. Typosquatting : publication de packages aux noms similaires (requests vs requestss) sur des registres publics (npm, PyPI, RubyGems). 2. Dependency confusion (ou namespace confusion) : exploitation des résolutions de dépendances (packages internes vs externes) via publication de versions plus élevées sur des registres publics. 3. Compromission de packages : injection de backdoors dans des packages maintenus (ex : event-stream, ua-parser-js). 4. Malicious maintainer takeover : prise de contrôle d’un package par un mainteneur (ou compte compromis). 5. Registres compromis : accès non autorisé à un registry interne (Docker, Artifactory) pour remplacer des artefacts.

Avez-vous automatisé les tâches de sécurité répétitives qui consomment le temps de vos équipes ?

Typosquatting : anatomie

Les attaquants publient un package avec un nom proche d’un package populaire. Ils incluent du code malveillant (exfiltration secrets, trojan). Lorsqu’un développeur installera le package par erreur (typo, autocompletion), le code s’exécute. Les environnements CI/CD automatisent les npm install, pip install, augmentant l’impact. Les attaques :

• ctx (npm) -> vol de variables d’environnement.
• colourama (PyPI) -> télécharge un payload.
• phpass (Packagist) -> backdoor.

Détection : scanning des dépendances, surveillance TI, alertes registry.

Dependency confusion

Le concept : les systèmes de build résolvent les dépendances en interrogeant d’abord les registres publics. Si un package interne (@company/lib) n’existe pas public, publier une version publique (major version) trompe la résolution. Le package malveillant s’installe, accède aux secrets du build. Alex Birsan a popularisé la technique. Les environnements vulnérables : npm, PyPI, NuGet, RubyGems. Conditions : configuration du registry, scoped packages, absence de restrictions (always-auth).

Mitigation :

• Configurer le registry (npmrc) pour pointer vers un registre privé avec registry=https://npm.company.com.
• Ajouter @company:registry=https://npm.company.com.
• Bloquer les installations de packages non approuvés (npm npmconfigscope).
• Utiliser pip --index-url et --extra-index-url en contrôlant la priorité.

Compromission de packages légitimes

Les mainteneurs peuvent être compromis (phishing, takeover) ou agir malicieusement :

• ua-parser-js (npm) : compromission via compte mainteneur -> cryptominer.
• event-stream : mainteneur a cédé le package, backdoor injectée.
• npm colors : sabotage par mainteneur.

Mitigation : instrumentation TI, pinned versions, scanning comportemental. Les mainteneurs majoritaires doivent avoir MFA (npm, PyPI). Les organisations doivent surveiller les versions, les scripts postinstall.

Votre architecture de sécurité repose-t-elle sur une seule couche de défense ?

Registres compromis et artefacts

Les registries (Docker, Artifactory) contiennent les images, packages internes :

• Credentials volés -> push malveillant.
• ACL laxistes -> modification.
• Manque d’audit -> infiltration invisible.

Les attaques supply chain se traduisent par des images modifiées (cryptominer, backdoor). Les défenses :

• Authentification forte (MFA, SSO).
• RBAC strict, principle of least privilege.
• Audit trail (push/pull).
• Signature (Cosign, Notary) des images.

SBOM : fondations

La SBOM (Software Bill of Materials) est un inventaire des composants (packages, versions, licences) d’une application. Normes :

• SPDX (Software Package Data Exchange).
• CycloneDX.

Générer une SBOM :

• Outils SCA (Snyk, Anchore, Trivy, Syft) pendant le build.
• Intégrer dans pipeline (GitHub Actions, GitLab CI).
• Stocker SBOM (artifacts, registry).

La SBOM permet :

• Visibilité (quelles dépendances, versions).
• Réponse rapide (vulnérabilité critique -> identification des applis impactées).
• Conformité (Executive Order US, directives UE NIS2).

Verrouillage des registres (registry hardening)

• Registry firewall : limiter les sources IP, imposer TLS mutualisé.
• Policies : immutable tags, interdiction de latest non signés.
• Scanning : vulnérabilité, malwares (Harbor, ECR scan).
• Auditing : logs push, pull, delete.
• Backup : snapshots regular (éviter pollution).

Les registries on-prem (Artifactory) : appliquer des patchs, habilitations, segmentation réseau. Les architectures zero trust isolent le registry dans un segment restreint.

SCA (Software Composition Analysis) en pipeline

Les outils SCA identifient les vulnérabilités, licences, packages malveillants :

• Snyk, Sonatype Nexus IQ, GitHub Dependabot, GitLab Dependency Scanning, OWASP Dependency-Check.

Intégration :

• Jobs CI exécutant SCA sur chaque commit.
• Faille critique -> échec pipeline.
• Rapports (JSON, SARIF) pour tri.

Les SCA identifient les versions malicieuses (CVE). Les organisations ajoutent des règles (policy) : fail si CVSS > 7.0. Les dashboards (Snyk) priorisent.

Gestion des packages internes

• Private registries (npm Enterprise, GitLab Package, Azure Artifacts).
• Namespace (scopes @company).
• npm access restricted.

Automatisation : pipeline publie packages signés, versions semver. Documentation d’utilisation. On interdit l’installation de packages internes depuis public (policy). Les build configs (npmrc, pip.conf) sont gérés via configuration management (Ansible).

Détection typosquatting et TI

• Outils (GuardDog, Datadog Wolfi, Sonatype) détectent packages suspects.
• TI (GitHub Advisory Database, Sonatype OSS Index) alerte sur packages malveillants.

Les organisations surveillent les publications : subscribe aux RSS registry. Scripts comparent les noms (distance Levenshtein) avec packages internes -> alerte.

Pipeline de sécurité supply chain

1. Pull : developer souhaite une dépendance. 2. Review : check security (TI, signature, mainteneur). 3. Approval : security champion valide. 4. Catalog : package ajouté à la liste approuvée. 5. Monitoring : SCA continue.

Les workflows (ServiceNow) assurent traçabilité. Les packages non approuvés -> pipeline fail.

Signatures, attestations et provenance

• Cosign signe les artefacts et SBOMs.
• in-toto et SLSA attestation (prouve pipeline).

Les pipelines génèrent attestation (cosign attest --predicate sbom.json). Les déploiements vérifient (policy OPA). Sans signature valide -> blocage. Les clés stockées dans KMS, rotation.

Observabilité et alerting

Les logs :

• npm/pip : use --loglevel http.
• Artifactory/Azure Artifacts : audit logs (REST API).

SIEM :

RegistryLogs
| where Action == "push" and User !in (allowed)

Alertes sur delete inattendus, force push. Surveiller les pip install vers un index externe.

Cas d'incidents

Dependency confusion Microsoft (2021)

Des packages internes @azure synchronisés ; Birsan publie versions externes -> installation lors de build, exfil vraies. Microsoft a corrigé en configurant Scoped registries, Artifact registries.

SolarWinds Orion

Backdoor insérée dans build pipeline, signée, distribuée. Importance : isolation du build, code review, monitoring. Utilisation de build signing et check.

PyTorch-nightly (2022)

Package nightly PyPI compromis, exfiltration de creds. Mitigation : isoler environnements (nightly vs stable), scanning.

Gestion des licences et conformité

Les SBOM incluent les licences. Les outils SCA identifient (GPL, MIT). Les policies (legal) interdisent certain licences. Les pipelines échouent si violation. Les rapports alimentent compliance (SOX).

Monitoring runtime

Même avec SCA, un package peut contenir du code malveillant. On surveille en runtime :

• EDR/Runtime (Falco, Sysdig) -> identify network connections (ex : npm install contact C2).
• RASP pour instrumentation.

Les logs (app) repèrent des comportements (ex : arborescence d'accès). Pour approfondir, consultez Top 10 Solutions EDR/XDR.

Policy as code : OPA, Sentinel

Les politiques contrôlent :

• Pas de npm install sans package-lock.
• pip install uniquement depuis allowlist.

OPA Gatekeeper (Kubernetes) -> Interdire déploiements sans attestation. Terraform Sentinel -> infrastructure. Les pipelines pre-commit appliquent (Conftest).

Inventory et asset management

• Cataloguer dépendances dans CMDB (ServiceNow).
• Liens applicatifs -> packages -> versions.

Les incidents (Log4Shell) : la CMDB identifie les apps. Les champs (owner, criticité). On automatise via SBOM import.

Response to incidents

1. Identifier packages malveillants (TI, SCA). 2. Search (repos, registries). 3. Remédiation (supprimer, patch). 4. Rebuild, redeploy. 5. Communiquer (clients, regulators).

Le playbook inclut git grep pour references, alertes Slack. Les pipelines CG (Canary) test.

Roadmap de maturité

1. Phase 1 : SCA basique, SBOM générée, policies registry. 2. Phase 2 : Signatures, attestation, TI intégrée, allowlist packages. 3. Phase 3 : SLSA L3, OPA policies, runtime monitoring. 4. Phase 4 : ML detection, full pipeline isolate, zero trust supply chain.

Chaque phase : jalons (ex : 100% SBOM).

Tableaux de bord

Dashboards (Grafana, Power BI) :

• Nombre packages par repo.
• Vulnérabilités critiques ouvertes.
• % dependencies approuvées.
• Temps de remédiation (MTTR).

Collaboration DevSecOps

• Security champions dans chaque squad.
• Revues architecture supply chain, Threat modeling.
• Formations sur dependency management.

Les ateliers (brown bag) sur typosquatting. Les guides (wiki) listent process.

Intégration avec Dev Portal

Les devs utilisent un portail (Backstage) listant packages approuvés, SBOM, instructions. Les API fournissent l’état (SLO).

TI automatisée

• Intégration MISP, Sonatype.
• Alertes Slack quand un package est flagged.

Les pipelines cross-check TI avant merge. Les updates (Dependabot) sont accompagnées d’un score risk.

Gestion des artefacts tiers (binary provenance)

• Les binaires (ex : libs C++) -> signature, hash.
• Stocker dans repo secure.
• Scanner (ClamAV).

Les pipelines comparent hash (Chain of Custody).

Questions frequemment posees

Conclusion

La protection de la supply-chain applicative exige une combinaison de visibilité (SBOM), de contrôle (registry locking), d'analyse (SCA) et de gouvernance (policies). Les attaques par typosquatting et dependency confusion exploitent la confiance dans les écosystèmes open source ; seule une défense en profondeur, intégrée aux pipelines CI/CD, permet de maintenir la sécurité tout au long du cycle de développement logiciel.

Écosystèmes et particularités

npm (JavaScript)

• Fichiers package.json, package-lock.json (ou yarn.lock).
• Scripts preinstall, postinstall, prepare pouvant exécuter du code.
• npm install résout en fonction du registry et des scopes.

Bonnes pratiques :

• Fixer engine-strict et package-lock commit.
• Désactiver les scripts automatiques (npm install --ignore-scripts lors de l’analyse).
• Utiliser npm audit et npm audit signatures.
• Configurer npm config set always-auth=true pour authentification.

PyPI (Python)

• Fichiers requirements.txt, Pipfile.lock, setup.py.
• Scripts setup.py peuvent exécuter du code lors du build.

Bonnes pratiques :

• Utiliser pip install --require-hashes pour vérifier les hash.
• pip-audit, pipenv check.
• Configurer pip.conf avec index interne et trusted-host.

Maven (Java)

• Dépendances dans pom.xml, résolution via settings.xml.
• Risque de repository mirrorOf= redirigeant vers un site malveillant.

Bonnes pratiques :

• Utiliser un repository manager (Nexus, Artifactory).
• Signatures PGP (Maven Central).
• mvn verify avec enforce plugin pour versions.

NuGet (.NET)

• Fichiers .csproj, packages.config.
• Typosquatting dans nuget.org.

Bonnes pratiques :

• nuget.config pointant vers feed interne.
• dotnet restore --source spécifique.
• Idenfifier packages signés.

OCI (conteneurs)

• Images Docker, chart Helm.
• Attaques : images typosquattées (Docker Hub), chart malveillant.

Bonnes pratiques :

• FROM images de base officielles, pin digest (sha256).
• Scanning (Trivy, Grype).
• Signatures (Cosign), Policy (Kyverno) interdisant images non signées.

Gestion des environnements de build

• Séparer environnements (dev, test, prod) avec registries distincts.
• Build en environnement hermétique (pas d'accès Internet direct) : utiliser un proxy cache ou interne.
• Pipeline two-step: résolve, approuve -> build.
• Cache de dépendances (Artifactory) pour éviter downloads directs.

L’hermétisation réduit le risque d’installer un package malveillant en temps réel. Les builds offline utilisent des archives approuvées.

Contrôles de signature

• GPG/PGP sur packages (Maven, Python).
• sigstore pour npm (sign-in via OIDC) -> signature.
• Verifier signatures (npm audit signatures, gpg --verify).

Les organisations doivent stocker les clés (HSM). La rotation régulière. Les pipelines automatisent la vérification (fail si signature invalide).

Gestion des alertes de vulnérabilités

Les SCA remontent des vulnérabilités :

• Tri (CVSS, exploitabilité, criticité).
• Assignation (Jira) à l’équipe owning.
• SLAs (ex : CVE critique -> 7 jours).

Les dashboards suivent la dette. Les exceptions sont enregistrées (waiver). L’utilisation de virtual patching (WAF) en attendant patch.

TI et communauté

Les organisations participent aux communautés (OpenSSF, CNCF). Elles reçoivent des alertes early. Ex : OpenSSF Securing OSS propose des guides. Participation à Bug bounty OSS. Les contributions à OSS (funding) améliorent la sécurité.

Détection de code malveillant dans packages

• Analyse statique (Semgrep) pour repérer exec, os.system, eval non attendus.
• Sandboxing : exécuter le package dans un environnement contrôlé (gVisor) et observer (network calls, file writes).
• YARA sur archives .tgz, .whl.

Les rapports incluent l’évaluation. Les packages suspect sont mis en quarantaine (registry).

Audit des registres

Les registres doivent enregistrer :

• push, pull, delete.
• Utilisateur, IP, date, digest.

Les logs sont envoyés au SIEM. Les alertes : delete hors processus, push par compte non usual. Les organisations activent quarantine (Harbor) pour images non scannées.

Cas d’usage : gestion Log4Shell

Log4Shell (CVE-2021-44228) a démontré l’importance SBOM et SCA. Étapes :

1. Génération SBOM -> rechercher log4j-core. 2. Inventaire : liste des applications affectées. 3. Plan patch -> mise à niveau 2.17. 4. Compensations (WAF, config). 5. Communication (clients, régulateurs).

Les organisations sans SBOM ont eu du retard. Les pipelines ont intégré log4j-detector. Pour approfondir, consultez Incident Response : Playbook Ransomware 2026.

Programmes de bug bounty supply-chain

Certaines entreprises financent des audits (sec) de packages OSS critiques. On sponsorise OSS-Fuzz, OpenSSF Alpha-Omega. Les budgets améliorent la sécurité des dépendances. Des programmes bug bounty internes se focalisent sur pipeline.

Industrialisation SCA

• Intégrer SCA dans pre-commit (rapide) + pipeline (complet).
• Alerting centralisé (Snyk Slack).
• Automatise PR (Dependabot) avec fix -> review.

Process : detection -> PR auto -> tests -> merge. Exceptions confirmées par security.

Gestion des packages transients

Les transients sont indirects (dépendances de dépendances). Les SBOM listent. Les SCA priorisent. Les packages transients malveillants (ex : flatmap-stream). Mitigation :

• Pin versions (lockfiles).
• Override via resolution (npm resolutions).
• Mirror repo (vendoring).

Politique de registre offline

• Forcer downloads via registry interne.
• Bloquer internet direct (firewall).
• Maintenir un pipeline sync (mirror) des packages nets (whitelist).

Les updates sont contrôlés (pull -> scan -> push). La latence est ajoutée mais la sécurité augmente.

Tests de infiltration (Purple Team)

Exercices :

• Publier un package typosquatté test (lab) -> voir pipeline.
• Simuler dependency confusion (internal).
• Compromettre un registry lab -> voir detection.

Les lessons alimentent les playbooks. Les red teams utilisent npm malware toolkits.

Monitoring de hash et diff

• Maintenir un repo de hash (SHA) des packages approuvés.
• À chaque build, comparer hash.
• Si divergence -> alerte.

Les outils (Sigstore, Rekor) stockent digests. L’historique aide à détecter modifications (even same version).

Sécurité des conteneurs base

Les images base (alpine, ubuntu) doivent être scannées. Les organisations maintiennent des images golden. Les pipelines basent sur ces images (private registry). On suit CVE sur base (Snyk, Clair).

Observabilité en runtime

• Intégrer eBPF (Cilium Tetragon) pour surveiller les process qui s’exécutent (ex : curl dans container).
• Indicateurs : process anormaux, network vers exfil.

Les attaques supply chain se manifestent par communications (C2). Les logs app (AppInsights) identifient anomalies.

Certifications et conformités

• NIST SSDF, NIST 800-218.
• ISO 27034 (Application Security).
• Executive Order 14028 (fédéral US) -> SBOM exigée.

Les programmes alignent leurs process. Les rapports (audit) démontrent la conformité.

Collaboration inter-équipes

• SecOps, DevOps, Legal, Compliance.
• Process d’exception pour packages non approuvés (par ex : frameworks R&D).

Les comités mensuels review packages, dettes. Les N-1 partagent la roadmap.

Threat Hunting supply-chain

Scenarios :

• Recherche d’installations de packages depuis IP externes non prévues.
• Identification de curl/wget dans pipeline.
• Diff sur registries (sha mismatch).
• Revue des packages nouvellement publiés sur registries internes.

Scripts (Python) interrogent API registry. Les hunts planifiés (mensuel).

Sensibilisation développeurs

• Formations (module e-learning) sur typosquatting.
• Cheat sheets (OWASP ASVS).
• Afficher avertissements (npm ci vs npm install).

Les développeurs apprennent à vérifier package (mainteneurs, downloads).

Outils open source utiles

• Syft : génère SBOM.
• Grype : scan vulnérabilités.
• GuardDog : detect malicious npm.
• Bandit (Python) + Pip-audit.
• Sigstore Cosign.

Les équipes les intègrent dans pipeline (GitHub Actions).

Vue Data et analytics

Les data scientists appliquent analytics :

• Score risk package (downloads, maintainer).
• Graphs de dépendances (NetworkX) -> centralité.
• Détection anomalies (nouveau mainteneur).

Les graphes identifient packages critiques (bus factor). On priorise l’audit.

Gestion du bus factor

Les packages critiques maintenus par peu de personnes (OSS) -> risque. Les organisations peuvent :

• Contribuer (code, funding).
• Rechercher alternatives.
• Appliquer monitoring renforcé (TI).

Registres Helm et Terraform

• Charts Helm : signer (helm package --sign), vérifier (helm verify).
• Modules Terraform : checksums.

Les pipelines contrôlent. Les registries (Artifact Hub) -> TI.

Récapitulatif détection vs prévention

• Prévention : registries privés, allowlists, signature, sandbox.
• Détection : SCA, logs, TI, runtime.
• Réponse : rotation, rebuild, communication.

Gouvernance et politiques

• Politique supply chain (document) : exigences, process.
• Rôles (Product Security, Dev, Ops).
• Reporting (CISO).

Les KPIs (temps detection, remediation). Les audits tierces (pen-tests).

Roadmap détaillée

0-3 mois

• Cartographier dépendances via SCA.
• Configurer registries privés, lockfiles obligatoires.
• Mettre en place scanning pipeline (Snyk, Trivy).

3-6 mois

• Générer SBOM, stocker centralement.
• Implémenter signatures artefacts.
• Déployer policies OPA (no unapproved).

6-12 mois

• Intégrer attestation SLSA.
• Automatiser TI, hunts.
• Déployer runtime detection (Falco).

>12 mois

• Zero trust supply chain : builds hermétiques, exécution enclaves.
• R&D IA pour detection.
• Collaboration OSS renforcée.

Chaque étape associe budget, sponsor, indicateurs.

Tableau de bord exécutif

• # vulnérabilités critiques ouvertes.
• Temps moyen de remédiation.
• Couverture SBOM (%).
• Packages approuvés vs non approuvés.
• Incidents supply-chain.

FAQ

Checklist finale étendue

1. Catalogue : SBOM, lockfiles, inventaire packages internes/externes. 2. Registries : privés, accès restreint, logs, scanning, signatures. 3. SCA/Pipeline : analyses sur chaque build, fail sur vulnérabilités critiques, rapport. 4. Policies : allowlists, OPA, no scripts non signés, pin versions. 5. Secrets : isolation builds, offline, sans Internet direct. 6. TI/Hunting : monitoring typosquatting, dependency confusion, hunts réguliers. 7. Réponse : playbooks, rotation, rebuild, communication. 8. Gouvernance : documentation, training, KPIs, audits. 9. SLSA/Provenance : signatures, attestations, runtime monitoring. 10. Amélioration continue : roadmap, bug bounty, participation OSS.

En combinant ces actions, les entreprises réduisent drastiquement l’impact potentiel des attaques supply-chain applicatives, renforcent la confiance dans leurs logiciels et se préparent aux exigences réglementaires croissantes.

Déploiement des contrôles dans les environnements multi-cloud

Les organisations modernes exploitent plusieurs clouds (AWS, Azure, GCP) et SaaS (GitHub, GitLab). Les contrôles supply-chain doivent être cohérents :

• AWS : CodeArtifact pour registries, IAM with least privilege, CloudTrail pour audits, GuardDuty pour détection. Intégration S3 pour SBOM.
• Azure : Azure Artifacts, Azure Defender for DevOps, Azure Policy pour contrôler images ACR signées.
• GCP : Artifact Registry, Binary Authorization (enforce signatures), Cloud Build (supply chain security).

Une gouvernance centralisée définit les standards (SBOM format, SCA tools) et assure leur adoption sur chaque plateforme. Les logs sont centralisés (SIEM multi-cloud).

Intégration des SBOM dans le cycle de vie

La SBOM n’est pas statique :

• Génération à chaque build.
• Stockage versionné (Git, Artefact).
• Distribution aux clients (pour conformité).
• Utilisation dans réponse incident (recherche rapide).

On crée un service interne SBOM API permettant d’interroger (ex : GET /sbom?component=log4j). Les équipes compliance utilisent l’API. Les SBOM sont signées (intégrité).

Surveillance des mainteneurs OSS

Les packages critiques sont surveillés :

• Surveillance des commits (baisse d’activité, nouveaux maintainers).
• Vérification MFA sur comptes (npm propose npm owner ls).
• Watch des issues (annonce takeover).

Des scripts (GitHub GraphQL) collectent les metadata (last commit). On établit un scoring. Les packages high risk -> plan mitigation (fork interne, contributions).

Governance des contributions externes

Les contributions aux projets open source peuvent introduire des risques. Process : Pour approfondir, consultez WebCache Deception & cache.

• Revue par security champion.
• Analyse (static analysis).
• Communication avec mainteneurs.

Les entreprises maintiennent un Open source program office (OSPO) pour superviser contributions, licences, sécurité.

Observabilité supply chain dans le SIEM

Sources intégrées :

• Logs registry (Artifactory, ECR).
• Scans SCA (Snyk events).
• Git events (workflow modifications).
• Cloud Audit (AssumeRole, Access).

Les dashboards SIEM affichent les menaces. Des règles corrèlent (ex : nouveau package + pipeline failure + network anomaly).

Réduction du bruit et priorisation

Les outils SCA peuvent générer beaucoup d’alertes. Stratégies :

• Prioriser par criticité (CVSS, exploit).
• Exploit prediction scoring (EPSS).
• Filtrer packages non utilisés (dead code).

Les rapports hebdomadaires se concentrent sur high/critical. Les exceptions justifiées (documented).

Méthodes d’analyses avancées

• Fuzzy hashing (ssdeep) pour comparer packages.
• Control Flow Graph pour détecter code inj.
• Machine learning pour comportement install scripts (feature : network call, entropy).

Les data scientists collaborent. Le modèle apprend à partir d’échantillons malveillants. Les scores élevés déclenchent revue manuelle.

Cas de dependency confusion géré

Une entreprise a détecté un package internal-common-utils publié sur npm public. Dès l’install, l’outil SCA a alerté (package non approuvé). Le pipeline a échoué. Les investigations ont montré un test interne. La leçon : config de npm .npmrc (registry private). Policy mise à jour.

Gestion des tokens d’accès registry

Les tokens (npm auth token, Docker registry) doivent être gérés :

• Stockage dans vault.
• Durée de vie limitée.
• Scope minimal (read-only pour CI).

Les logs surveillent l’utilisation. Les tokens read-write uniquement sur pipelines de publication, isolés. Rotation régulière (30-60 jours).

Rôle des Security Champions

Chaque équipe produit a un champion :

• Gère la liste des dépendances.
• Coordonne avec SecOps pour packages nouveaux.
• Assure la conformité (SCA).

Des réunions mensuelles partagent retours (incident, nouveaux outils). Les champions participent aux hunts.

Processus d’acceptation des packages

1. Developer propose -> issue security. 2. Analyse security (TI, SCA). 3. Legal vérifie licence. 4. Entry dans registre (approuvé).

Un catalogue interne (Portal) liste packages approuvés, versions, justification. Les pipelines vérifient (pre-commit script).

Alignement sur frameworks

• OWASP SAMM : SAMM-BM3 (Security Requirements), S-Supply1 (Inventory & Control).
• BSIMM : Domain SSDL Touchpoints -> Package management.

Les maturités sont évaluées annuellement. Les actions alignées sur scoring.

Mesurer l’efficacité des contrôles

KPIs :

• % builds avec SBOM générée.
• Temps entre release vulnérable et patch.
• Nombre de packages non approuvés détectés par SCA.
• # hunts supply chain réalisés.

Les dashboards suivent l’évolution (progression).

Simulation (Table-top)

Scénario : package strcpy compromis. Table-top :

• Identification (TI).
• Impact (SBOM).
• Communication (clients).
• Lessons (update process).

Les participants : SecOps, Dev, Legal, PR.

Intégration d’OPA/Kyverno

Pour Kubernetes :

• Kyverno policy : require attestations (Cosign).
• Gatekeeper : deny images sans digest.

Exemple Kyverno :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image
spec:
  rules:
  - name: check-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - image: "registry.company.com/"
      key: "cosign.pub"

Les déploiements non conformes échouent. Les logs Kyverno sont suivis.

Documentation et runbooks

Les runbooks détaillent :

• Comment générer SBOM.
• Process pour approuver package.
• Réponse incident supply chain (contacts).

Les runbooks sont versionnés (Git). L’accès facile via wiki.

Prod vs R&D

Les environnements R&D peuvent tolérer plus de flexibilité. Cependant :

• Label packages experimental.
• Interdiction de déployer en prod sans validation.

Les R&D pipeline isolés. Les packages test sont blocklist pour prod.

Sécurité des templates pipeline

Les templates (.gitlab-ci.yml partagés) doivent être sécurisés. Includes pointent vers commit hash. Les modifications sont revues. Les pipelines utilisent policy-as-code (Sentinel).

Collaboration avec les fournisseurs

Les logiciels tiers (SaaS) doivent fournir SBOM. Les contrats incluent supply chain security. On évalue leur pipeline (questionnaires SIG Lite). Les fournisseurs critiques undergo audits.

Architecture Zero Trust supply chain

• Build isolé.
• Authentification forte pour accès registry.
• Verification signatures à chaque étape.
• Monitoring continu.

Les pipelines ne font confiance à aucun package non attesté. Les jobs sans credentials par défaut (JIT).

Innovations et tendances

• Reproducible builds (determinisme) -> compare outputs.
• Secure enclaves (Confidential CI).
• AI pour detection packages malveillants (analysis pattern).
• OSS Scorecard automatisé dans pipeline.

Les équipes explorent ces innovations lors de PoC.

Cas d’étude : organisation financière

Une banque a instauré : Pour approfondir, consultez Attaques Wireless Avancées : Wi-Fi 7, BLE 5.4 et Zigbee.

• Registry interne (Artifactory) isolé.
• SCA (Snyk) sur pipelines Jenkins.
• SBOM central via Syft/Anchore.
• Policy OPA (images signées).
• TI monitoring (Sonatype).

Lors de la vuln Log4Shell, l’identification a pris 2 heures, patch 48h. Le KPI a montré amélioration vs incidents précédents.

Cas d’étude : entreprise SaaS

• GitHub Actions + OIDC -> AWS.
• SLSA L3, attestation.
• Release gating : require attestation, tests security.
• SBOM communiqué aux clients.

Un typosquatting lodashs a été détecté via SCA. Les pipelines ont échoué, évitant propagation.

Stratégie d’open source management

• OSPO gère contributions, licences, backlog security.
• Dependency update days.

L’OSPO collabore avec SecOps pour prioriser patchs. Les devs reçoivent du temps (20%) pour maintenance.

Assurance et responsabilité

Les assureurs cyber évaluent supply chain security. Les questions : SBOM, SCA, policies. Les entreprises dotées de contrôles robustes obtiennent de meilleures primes.

Rapports vers le conseil d'administration

Trimestriels :

• Synthèse incidents supply chain.
• Progression roadmap.
• Risques résiduels.

Les slides mettent en avant actions (SBOM, SLSA).

Conclusion étendue

La sécurité supply-chain applicative est un chantier continu, impliquant une collaboration étroite entre développeurs, sécurité, opérations et dirigeants. Les menaces (typosquatting, dependency confusion) profitent de la complexité et de la confiance implicite dans les écosystèmes open source. En déployant des contrôles techniques (SCA, SBOM, signatures), des politiques (allowlists, OPA), une gouvernance rigoureuse et une surveillance proactive, les organisations bâtissent une chaîne logicielle résiliente, capable de détecter et d’absorber les attaques émergentes.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

Copyright Ayi NEDJIMI Consultants