Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Cloud Supply Chain Security

cloud

Définition

La Cloud Supply Chain Security est la protection de l'ensemble des composants logiciels, des dépendances, et des pipelines CI/CD utilisés pour construire et déployer des applications dans le cloud contre les compromissions intentionnelles ou accidentelles. Les attaques supply chain cloud (SolarWinds, Kaseya, log4shell) ciblent les maillons faibles de la chaîne de production logicielle pour compromettre massivement les environnements cloud via des composants de confiance. Les vecteurs d'attaque supply chain cloud incluent : la compromission de registres de packages (npm, PyPI, Maven) avec des packages malveillants imitant des packages légitimes (typosquatting, dependency confusion), la compromission des pipelines CI/CD (injection de code malveillant dans GitHub Actions, Jenkins, GitLab CI), la compromission des images de conteneurs (image poisoning dans Docker Hub ou des registres tiers), et la compromission des dépendances tierces dans les applications (bibliothèques open source avec des backdoors). Les SBOM (Software Bill of Materials) sont au cœur de la supply chain security cloud : un SBOM est un inventaire complet de tous les composants logiciels d'une application (packages OS, bibliothèques, frameworks) avec leurs versions et leurs licences. Les formats standardisés SPDX (Software Package Data Exchange) et CycloneDX permettent l'interopérabilité entre outils. Les SBOMs permettent d'analyser instantanément l'impact d'une nouvelle CVE (ex: log4shell) sur l'ensemble du parc applicatif sans re-scanner chaque application. La sécurisation des pipelines CI/CD cloud passe par : la signature des artefacts (Sigstore/Cosign pour les images conteneurs, SLSA framework pour les artefacts de build), le scanning des dépendances (Dependabot, Renovate pour les mises à jour automatiques, Snyk, Trivy, Grype pour les CVEs), l'isolation des environnements de build (builds hermétiques sans accès Internet, runners éphémères), et l'authentification forte des pipelines vers les registres cloud (OIDC federation évitant les long-lived credentials).

Signature d'images avec Cosign et Sigstore

Signez vos images conteneurs avec Cosign (Sigstore) pour garantir leur intégrité : cosign sign --key cosign.key ghcr.io/myorg/myapp:v1.0.0. Vérifiez la signature dans votre pipeline de déploiement : cosign verify --key cosign.pub ghcr.io/myorg/myapp:v1.0.0. Utilisez Gatekeeper ou Kyverno dans Kubernetes pour refuser les images non signées : la policy ClusterPolicy vérifie la signature Cosign avant d'autoriser le scheduling d'un pod. Avec Sigstore Keyless Signing (Fulcio + Rekor), la signature est liée à l'identité OIDC du pipeline CI/CD (sans clé à gérer).

SLSA Framework pour les artefacts de build

Implémentez le framework SLSA (Supply Chain Levels for Software Artifacts) pour sécuriser vos pipelines de build : SLSA Level 1 - les builds sont scriptés (pas de builds manuels). SLSA Level 2 - les builds s'exécutent sur un système de build géré avec un service de provenance signé (GitHub Actions avec SLSA Generator). SLSA Level 3 - les builds sont hermétiques (isolation réseau pendant le build), éphémères (runner détruit après le build), et sourcés uniquement depuis des sources contrôlées. Le SLSA Provenance (attestation signée de l'origine d'un artefact) permet de vérifier qu'un binaire a été construit à partir d'un commit Git spécifique par un workflow CI/CD spécifique.

OIDC Federation pour les pipelines CI/CD

Remplacez les long-lived AWS credentials dans vos pipelines CI/CD par l'OIDC Federation : GitHub Actions peut assumer des rôles IAM AWS directement via OIDC (sans access keys stockés dans GitHub Secrets). Configurez un Identity Provider OIDC dans IAM Trust Policy du rôle : condition StringLike token.actions.githubusercontent.com:sub repo:myorg/myrepo:*. Dans le workflow GitHub Actions, utilisez aws-actions/configure-aws-credentials avec role-to-assume et web-identity-token-file. Ces credentials temporaires (STS tokens, durée 1h) éliminent le risque de vol de long-lived credentials depuis les pipelines.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis