Sécurisez votre chaîne d'approvisionnement logicielle, du build au déploiement

Évitez que des images de conteneur non analysées, non signées ou vulnérables n’arrivent en production. Ce guide vous expliquera comment les contrôles de registres privés, l'analyse des vulnérabilités, la signature d'artefacts et les politiques d'admission Kubernetes permettent de créer un workflow pouvant être appliqué dans l’ensemble de la chaîne d'approvisionnement logicielle. 
DémarrerManaged Private Registry
Noms de domaine illustration

Vérifiez chaque composant de votre pipeline

La sécurité de la chaîne d'approvisionnement logicielle implique de vérifier en permanence chaque dépendance, paquet et artefact dans une chaîne CI/CD. La confiance doit couvrir la source, les paquets publics, la technologie externe, les composants tiers, les éléments du build, les registres et la version finale. Une menace peut faire son entrée via des dépendances altérées ou des processus compromis. Commencez par identifier chaque composant orienté vers les clients par rapport à un référentiel reconnu, tel que les directives du NIST (National Institute of Standards and Technology) ou les principes de sécurité de la chaîne d’approvisionnement logicielle. Cela permettra ensuite aux équipes de savoir s’il manque des preuves dans certains domaines, d’appliquer des pratiques de codage sécurisées et de signer les sorties avec Cosign. Cette approche axée sur un référentiel vous permet de mettre en place des garanties tout au long de la chaîne plutôt que de compter sur un seul point de contrôle. Chaque partie peut retracer les composants intégrés au build, leur traitement et les preuves soutenant le déploiement.
[object Object]

Une assurance de publication s’appuyant sur des contrôles vérifiables

Projets Harbor privés, politiques Trivy, signatures Cosign et compétence européenne
Community@2x.png
Restreindre l'accès aux registres
Cyber Security@2x.png
Bloquer les vulnérabilités connues
Magnifying Glass Check@2x.png
Vérifier l'origine et la résilience

Protéger chaque étape susceptible d’être ciblée par des attaques

Qu'est-ce que la sécurité de la chaîne d'approvisionnement dans un environnement de conteneurs moderne ?

Qu'est-ce que la sécurité de la chaîne d'approvisionnement dans un environnement de conteneurs moderne ? Elle permet de protéger le parcours depuis le code source et les dépendances tierces jusqu'aux systèmes de build, au stockage d'images et aux terminaux de déploiement. La sécurité de la chaîne d'approvisionnement logicielle considère ces processus comme étant connectés, car une attaque à une extrémité de la chaîne peut affaiblir tous les contrôles ultérieurs.

Protection du référentiel source

Un référentiel source est une cible évidente. Un hacker peut voler des identifiants, modifier le code, désactiver une règle de contrôle ou introduire une dépendance qui semble légitime. Des sources de téléchargement contrôlées, un contrôle obligatoire par les pairs et des branches protégées constituent la première ligne de défense. Les équipes doivent également verrouiller les versions des dépendances et vérifier les sommes de contrôle, les licences et les origines plutôt que d'accepter des entrées changeantes pour chaque build. De tels contrôles réduisent le risque d'importer des logiciels malveillants ou non autorisés provenant d'autres parties.

Chemins d'attaque de l'infrastructure de build

L'infrastructure de build présente différents chemins d'attaque. Des exécuteurs compromis, des secrets exposés ou des images de base mutables peuvent modifier un artefact après l’approbation de sa source par les développeurs. Isolez les processus de build, utilisez des identifiants à courte durée de vie et enregistrez des entrées exactes. Cette approche contribue à la sécurité des images de conteneurs en facilitant le traçage des modifications de code imprévues.

Contrôles du registre au cluster

Le parcours du registre au cluster nécessite des contrôles indépendants. Un hacker pourrait remplacer une image approuvée, réutiliser une ancienne balise ou exploiter des autorisations de déploiement excessives. Le principe du droit d’accès minimal limite ce qui peut être publié ou récupéré par chaque identité. Des références immuables connectent les manifestes à des images précises, tandis que Kyverno est capable de rejeter les versions qui manquent de preuves fiables ou ne respectent pas les exigences de sécurité.

Une gestion efficace de la chaîne d'approvisionnement logicielle commence par un inventaire. Enregistrez les bibliothèques propriétaires et tierces, les images de base, les licences et les outils de build utilisés par chaque application. Connectez chaque nomenclature logicielle (SBOM) au projet, à la validation et à l'exécution de pipeline qui a produit l’artefact correspondant. Cette relation aide les équipes de cybersécurité à identifier les services affectés lorsqu'un composant sensible est compromis. Choisissez un outil qui exporte des preuves lisibles par machine et compare les versions grâce à l'automatisation. L'inventaire doit se développer parallèlement au logiciel, plutôt que de dépendre d'un travail manuel périodique. Désignez une personne à contacter pour les questions liées aux dépendances, aux exceptions et aux mesures correctives afin que les responsabilités restent claires.
Exécutez les tests de sécurité suffisamment tôt pour fournir aux développeurs des résultats exploitables. L'automatisation du pipeline permet d’examiner les dépendances de sources, les couches de conteneurs et la configuration avant la promotion. Définissez des seuils d'analyse des CVE (vulnérabilités et expositions courantes) en fonction de l'exposition du workflow et de l'impact sur l'activité, puis acheminez les résultats ayant échoué vers l'équipe responsable. L’échec d’un contrôle doit arrêter la progression au lieu de générer une alerte non lue. Enregistrez le problème, le paquet affecté, la gravité et la réponse approuvée. Cette preuve contribue à protéger la qualité des versions tout en assurant la cohérence des décisions concernant la sécurité de la chaîne d'approvisionnement logicielle pour toutes les applications.
La signature des images atteste du processus contrôlé d’approbation d’un artefact. Une fois que les tests requis sont réussis, signez chaque image avec une empreinte immuable, puis conservez la provenance qui identifie la révision source, l’auteur du build et le workflow. Évitez de signer des balises mutables seules, car une balise peut ensuite renvoyer à un contenu différent. Séparez les autorisations de signature de l'accès général concernant les développeurs et les pipelines. La vérification doit s’appuyer sur des identités de confiance ou des clés publiques définies par votre entreprise. Un processus de build compromis ne peut alors générer de preuves acceptables que si la politique de signature est également respectée.
Un contrôleur d'admission Kubernetes constitue le point de décision final avant que les charges de travail n'entrent dans un cluster. Configurez-le de manière à rejeter les images non signées, les registres non approuvés, les critères de vulnérabilité non satisfaits ou les provenances manquantes. Kyverno et OPA Gatekeeper peuvent exprimer ces conditions sous forme de politiques contrôlées par version. Testez chaque règle par rapport aux charges de travail correspondantes avant toute mise en production. Commencez en mode audit pour identifier les exceptions légitimes, puis passez les contrôles matures en mode blocage. Conservez un chemin d'exception autorisée avec un(e) responsable, un motif et une date d'expiration. Le cluster peut alors évaluer les preuves de version de manière cohérente, même si un contrôle antérieur est contourné ou mal configuré.
Une gestion efficace de la chaîne d'approvisionnement logicielle commence par un inventaire. Enregistrez les bibliothèques propriétaires et tierces, les images de base, les licences et les outils de build utilisés par chaque application. Connectez chaque nomenclature logicielle (SBOM) au projet, à la validation et à l'exécution de pipeline qui a produit l’artefact correspondant. Cette relation aide les équipes de cybersécurité à identifier les services affectés lorsqu'un composant sensible est compromis. Choisissez un outil qui exporte des preuves lisibles par machine et compare les versions grâce à l'automatisation. L'inventaire doit se développer parallèlement au logiciel, plutôt que de dépendre d'un travail manuel périodique. Désignez une personne à contacter pour les questions liées aux dépendances, aux exceptions et aux mesures correctives afin que les responsabilités restent claires.

Attribuez les responsabilités pour les quatre priorités de gouvernance

Code de confiance et gouvernance des fournisseurs

La personne désignée comme responsable doit définir les critères concernant les sources et fournisseurs de confiance, avec le soutien des services des achats, d'ingénierie et de sécurité. Utilisez le cadre de sécurité SLSA comme guide pour renforcer l’intégrité du build et la provenance sans présumer qu’un niveau donné sera atteint. Adaptez les revues à la taille de l'entreprise et aux risques de la chaîne d'approvisionnement logicielle.

Application des politiques et conformité de l’infrastructure

Les responsables de la sécurité et des plateformes doivent traduire les obligations de conformité en mesures quantifiables d’application des politiques pour le code, le cloud et l'infrastructure. Définissez qui peut approuver les exceptions, quelles preuves ces personnes doivent fournir et comment les contrôles répondent aux exigences internes.

Documentation, audits et preuves

Désignez une ressource chargée de conserver la documentation relative aux décisions, dépendances et changements de contrôle. Des audits réguliers doivent tester si les documents conservés correspondent à la pratique opérationnelle. Les réviseurs doivent bénéficier d’un soutien suffisant pour pouvoir retracer un problème jusqu'au/à la responsable concerné(e), à la version affectée et à sa résolution.

Préparation aux incidents et responsabilité quant aux mesures correctives

Une personne responsable de la sécurité doit coordonner les fonctions de réponse avant que des hackers ne les testent. Élaborez un plan permettant de traiter les problèmes potentiels, couvrant le triage, le confinement, la communication avec les parties prenantes et la reprise. Chaque action nécessite une personne responsable, des ressources de soutien et des délais adaptés à l'exposition au risque de l'entreprise.

Exploitez Harbor au regard de quatre axes de sécurité

Contrôlez les accès avec précision

Harbor prend en charge le contrôle d'accès fondé sur les rôles (RBAC) au niveau des projets et des équipes pour différencier les charges de travail et les responsabilités de l'entreprise. Émettez des comptes robots définis pour les tâches de push/pull de la chaîne CI/CD au lieu de partager des identifiants humains généraux. Faites correspondre chaque identité à un seul objectif, renouvelez son secret et supprimez les accès inutilisés. Cette pratique limite l'impact de l'exposition des identifiants, tout en sécurisant la publication quotidienne.

Détectez les composants non sécurisés en permanence

Associez des vérifications Trivy continues à l'analyse de la composition logicielle (SCA) et à la gestion des dépendances. Ces outils détectent les vulnérabilités connues, les paquets obsolètes et les indicateurs de code malveillant au sein de chaque composant. Produisez un rapport clair pour chaque version, incluant la gravité, l'emplacement et le statut des mesures correctives. Les équipes peuvent alors distinguer les résultats bloquants des exceptions acceptées et savoir si de nouvelles informations affectent les artefacts stockés.

Connectez les workflows de développement

Intégrez la plateforme à GitLab CI, Tekton et d'autres workflows de développement approuvés. Veillez à ce que les décisions de politique restent proches du pipeline, afin que l’échec d’un contrôle renvoie un retour utile avant la promotion. Les références de gestion du code source (SCM) doivent lier chaque artefact à sa validation, à son exécution de build et à la personne qui en est responsable. Les équipes DevSecOps disposent alors d'archives cohérentes plutôt que de preuves diverses dispersées à travers les systèmes.

Préparez la réponse opérationnelle

Mettez en place un plan d’intervention en cas d’incident pour les identifiants compromis, les images non sécurisées et les contrôles ayant échoué. Définissez les personnes compétentes pour suspendre la distribution, supprimer une version affectée, enquêter sur les accès et approuver la reprise. Une personne responsable et une procédure de réponse attendue sont nécessaires pour les alertes ; une simple génération d’alerte ne réduit pas le risque. Menez des exercices pour confirmer que les équipes de sécurité et des plateformes peuvent trouver le rapport pertinent, isoler le contenu et communiquer les décisions. Ce pilier opérationnel transforme la détection en mesures opportunes pour toute la plateforme de distribution.

Préservez des preuves fiables pour chaque version

La visibilité des versions dépend de preuves montrant qui a produit l’artefact, d'où il provient et comment il a été testé. Générez et conservez les résultats de Trivy, les données de nomenclature logicielle et les signatures pour chaque image et chaque ensemble de Helm charts. Cela permet à l'entreprise d'identifier chaque type de contenu et d'enquêter sur des problèmes de sécurité potentiels. Intégrez des contrôles avec GitLab CI afin d’automatiser les retours pour les développeurs avant que le logiciel n'entre dans l'environnement contrôlé. Des tests cohérents favorisent également la sensibilisation à la sécurité en montrant pourquoi une version a échoué. Protégez les clés de signature Cosign via Key Management Service d’OVHcloud, en utilisant un stockage fondé sur des HSM certifiés FIPS 140-2. La gestion centralisée des clés permet de garantir que chaque signature générée est liée à un matériel de clé contrôlé, plutôt qu'à un secret de pipeline exposé.
[object Object]
Veillez au respect de votre politique de publication de conteneurs avec OVHcloud
Mettez en place un chemin contrôlé entre la sortie de la chaîne CI/CD et le déploiement Kubernetes avec Managed Private Registry et Managed Kubernetes Service. Évaluez comment la validation de registre, les preuves de publication et la mise en œuvre de clusters peuvent bloquer les images non analysées, non signées ou vulnérables avant la production. Découvrez Managed Private Registry, puis évaluez l'intégration Kubernetes pour vos charges de travail, votre modèle de politique et vos responsabilités opérationnelles.
Explorer le chemin de registre