Renforcer la chaîne d’approvisionnement logicielle : protéger dépendances, secrets et pipelines

Une dépendance compromise, un secret exposé ou un workflow CI/CD trop permissif peut transformer un dépôt de code en point d’entrée vers les artefacts et les environnements de production. Renforcer la sécurité de la chaîne d’approvisionnement logicielle demande donc de traiter ensemble les dépendances, les secrets et les pipelines, plutôt que de compter sur un scanner unique ou sur la seule conformité.

Pour une équipe produit ou une entreprise, l’objectif n’est pas de supprimer tout risque, les dépendances et les outils évoluent en permanence, mais de réduire la confiance implicite, de limiter les accès et de rendre chaque étape vérifiable. Voici une méthode concrète pour inventorier les composants, protéger les identifiants, durcir les builds et organiser une réaction efficace aux alertes.

Sécurité de la chaîne d’approvisionnement logicielle : la réponse courte

Pour renforcer la chaîne d’approvisionnement logicielle, inventoriez les composants et leurs versions, contrôlez les sources et les mises à jour, protégez les secrets avec des identifiants à durée et portée limitées, puis rendez les pipelines déclaratifs, isolés et vérifiables. Ajoutez une surveillance continue et un processus de révocation afin de pouvoir agir quand une dépendance, un secret ou un outil de build devient suspect.

Cette approche répond à trois risques liés, mais distincts. Une dépendance peut introduire du code vulnérable ou malveillant. Un secret peut donner à un attaquant les droits nécessaires pour publier ou modifier du code. Enfin, un pipeline compromis peut altérer le logiciel produit, même si le code source examiné paraît légitime.

Les recommandations de CISA et les observations rapportées par GitHub, OpenSSF, Sonatype et Snyk convergent vers ce triptyque : comprendre ce qui entre dans le logiciel, empêcher l’exposition des identifiants et réduire les pouvoirs accordés aux processus de build. Il n’existe pas de contrôle unique qui couvre ces trois plans.

Cartographier les dépendances directes, transitives et nouvelles

La première étape consiste à savoir quels composants entrent réellement dans une application, pas seulement ceux que l’équipe a ajoutés explicitement. OpenSSF rappelle qu’une application peut incorporer des centaines ou des milliers de dépendances directes et transitives, sans qu’elles aient toutes fait l’objet d’une revue individuelle complète. Une dépendance transitive peut donc devenir un risque opérationnel sans avoir été choisie directement par un développeur.

Établissez un inventaire exploitable par application et par version. Un SBOM, ou nomenclature logicielle, formalise cette visibilité. CISA présente les SBOM comme un moyen de comprendre les dépendances et d’évaluer les risques de la chaîne d’approvisionnement. Il ne s’agit pas d’un certificat de sécurité : il décrit les composants, mais ne prouve pas à lui seul qu’ils sont sûrs, maintenus ou exempts de vulnérabilités.

Rendre l’inventaire utile à la décision

Pour chaque composant, cherchez à relier son nom et sa version au service qui l’utilise, à la personne ou à l’équipe responsable, à son origine et au contexte d’exécution. Cette association permet de distinguer une bibliothèque présente dans un outil interne d’un composant inclus dans un service exposé, tout en identifiant le propriétaire qui pourra évaluer une alerte.

  • Générez ou actualisez le SBOM lors des builds, et conservez-le avec l’artefact ou les métadonnées de livraison concernées.
  • Enregistrez les versions exactes et les sources de résolution, notamment pour les dépendances transitives.
  • Reliez les alertes de vulnérabilité aux dépôts, produits et équipes responsables, plutôt que de les laisser dans une console isolée.
  • Prévoyez une procédure pour les composants abandonnés, difficiles à remplacer ou dont l’origine ne peut pas être vérifiée.

L’inventaire doit alimenter une décision, pas devenir un document produit une fois puis oublié. Sonatype souligne qu’une dépendance considérée comme acceptable peut recevoir une nouvelle divulgation de vulnérabilité le lendemain. Il faut donc prévoir une veille continue et réévaluer les composants lorsque de nouvelles informations apparaissent, au lieu de considérer une validation initiale comme permanente.

Arbitrer les mises à jour sans banaliser le risque

Mettre à jour systématiquement chaque composant à la dernière version n’est pas toujours le choix le plus sûr : une mise à jour peut introduire une régression ou demander une validation fonctionnelle. À l’inverse, différer sans échéance les mises à jour laisse des versions vulnérables en circulation. Définissez une politique qui tient compte de la gravité de l’alerte, de l’exposition du composant, de sa présence dans un artefact livré et de la disponibilité d’une correction.

Les outils d’analyse de composition logicielle, ou SCA, peuvent aider à repérer les dépendances et les avis associés, mais ils ne remplacent pas l’analyse du contexte. Une alerte doit être traduite en action : confirmer si la version est réellement utilisée, évaluer son rôle, choisir entre mise à jour, remplacement, atténuation ou acceptation temporaire, puis attribuer un responsable et une échéance.

Le volume rend cette discipline plus importante. Sonatype rapporte dans son rapport 2026 une hausse de 75 % du malware open source et décrit une analyse portant sur plus de 1,233 million de paquets malveillants. Le rapport mentionne également 1,7 mille enregistrements de vulnérabilités et 37 mille recommandations de mise à niveau assistées par IA. Ces éléments soulignent la pression exercée sur les équipes, mais ne justifient pas une mise à jour aveugle : le triage doit rester relié à l’application et à ses usages.

Contrôler l’origine des paquets et réduire la confiance implicite

La présence d’un nom de paquet connu ne suffit pas à établir qu’un composant est digne de confiance. Les attaques de chaîne d’approvisionnement peuvent viser les dépôts de paquets et les systèmes CI/CD pour distribuer des malwares ou voler des identifiants. Dans un écosystème où les dépendances transitives se multiplient, une erreur de résolution ou une publication compromise peut affecter des projets qui n’ont pas examiné le composant en détail.

Adoptez des règles de résolution explicites. Verrouillez les versions lorsque cela convient à votre gestion de dépendances, contrôlez les sources autorisées et évitez les changements automatiques de registre ou de nommage sans revue. Les fichiers de verrouillage réduisent les variations inattendues entre installations, mais doivent être révisés et mis à jour selon un processus connu : les figer indéfiniment ne corrige pas les vulnérabilités.

Définir une politique de consommation

La politique doit préciser ce qui est autorisé, ce qui déclenche une revue et ce qui bloque une livraison. Elle peut tenir compte de la provenance, de l’existence d’une version publiée, de la maintenance apparente, des avis de sécurité disponibles et de la présence d’un remplaçant acceptable. Les critères sont à adapter au produit : une bibliothèque incluse dans un logiciel distribué et un outil temporaire de test ne présentent pas nécessairement le même contexte d’exposition.

  1. Définissez les registres et sources de paquets approuvés pour chaque langage et environnement.
  2. Exigez une revue pour les changements de source, les nouveaux composants critiques et les mises à jour majeures.
  3. Consignez les exceptions avec leur justification, leur propriétaire et une date de réévaluation.
  4. Testez les versions mises à jour avant livraison, sans laisser les tests remplacer l’examen de sécurité.

Le risque évolue aussi avec les pratiques de développement. Sonatype observe que l’IA accélère le développement et peut augmenter le nombre de dépendances et de mises à jour, au point de dépasser des programmes de gestion des vulnérabilités conçus pour un rythme plus lent. Si les assistants proposent ou ajoutent des composants, appliquez les mêmes exigences de provenance et de revue que pour les choix humains. La vitesse de génération ne doit pas devenir une permission implicite d’introduire de nouveaux paquets.

Enfin, traitez les outils de développement agentique comme une extension de cette surface. Snyk décrit une chaîne d’approvisionnement émergente composée de serveurs MCP, de skills et d’intégrations, souvent installés hors des contrôles de sécurité existants. Avant d’autoriser une intégration, identifiez ses permissions, ses données accessibles, sa source et son responsable. Un outil connecté au contexte de développement mérite un inventaire et des règles de mise à jour, au même titre qu’une dépendance logicielle classique.

Protéger les secrets dans le code et les pipelines CI/CD

Un secret exposé peut relier une erreur de développement à une compromission de publication ou d’infrastructure. CISA recommande de protéger les secrets du pipeline de build, d’éviter leur présence en clair dans le code et les logs, de modifier les identifiants par défaut et de faire tourner régulièrement les secrets. Ces mesures sont complémentaires : le stockage sécurisé ne suffit pas si les permissions sont trop larges ou si un jeton demeure actif après une exposition.

Commencez par recenser les identifiants nécessaires à chaque workflow : jetons de registre, clés de déploiement, accès cloud, certificats et identifiants de services. Pour chacun, documentez son propriétaire, son usage, les ressources auxquelles il donne accès et la procédure de révocation. Lorsqu’un identifiant n’a pas de propriétaire clair, il est difficile de savoir qui peut le retirer ou de déterminer l’impact d’une rotation.

Appliquer le moindre privilège aux identifiants

Un secret de build ne devrait pas donner automatiquement accès à la publication, et un identifiant de publication ne devrait pas disposer de droits sans rapport avec son objectif. Séparez les credentials utilisés par les étapes de test, de construction et de publication. GitHub a expliqué que dissocier les identifiants de pipeline de ceux qui publient vers les registres permet de couper une chaîne d’attaque dans laquelle un workflow compromis chercherait à réutiliser ses accès pour publier un paquet.

  • Utilisez des secrets limités à un dépôt, un environnement ou une tâche lorsque la plateforme le permet.
  • Privilégiez des identifiants temporaires ou renouvelables plutôt que des clés permanentes quand votre infrastructure le permet.
  • Réduisez les permissions par défaut et n’accordez l’accès aux secrets qu’aux étapes qui en ont besoin.
  • Masquez les valeurs sensibles dans les sorties, et examinez les scripts susceptibles de les copier dans les logs ou les artefacts.
  • Faites tourner les secrets selon une procédure planifiée et après toute suspicion d’exposition.

Une rotation n’est efficace que si l’ancien identifiant est désactivé et si les dépendances qui l’utilisaient ont été mises à jour. Préparez un chemin de révocation qui ne repose pas uniquement sur la disponibilité de la personne ayant créé le secret. Pour les identifiants de production, testez la procédure de remplacement afin que l’urgence ne conduise pas à laisser simultanément actifs des accès obsolètes.

Combiner prévention et détection

Le secret scanning aide à détecter des identifiants exposés dans les dépôts, mais sa couverture et son contexte comptent. GitHub indique couvrir plus de 150 partenaires techniques pour détecter et signaler des secrets rendus publics. La surveillance publique concerne les secrets déjà exposés dans des dépôts publics ; elle ne scanne pas les dépôts privés. Elle peut donc contribuer à une révocation rapide après une exposition publique, mais ne remplace ni les contrôles internes ni la prévention avant le push.

Les protections avant publication, les alertes post-push et les revues de sécurité ont des rôles différents. Une protection à l’envoi peut bloquer certaines expositions avant qu’elles n’entrent dans l’historique partagé. Une alerte post-push aide à repérer un problème déjà publié. Une revue peut examiner du code ou un contexte qui ne correspond pas aux formats classiques d’un jeton. GitHub a décrit une évolution vers une détection tenant compte du contexte du code et vers son intégration à l’alerting, à la push protection et aux revues de sécurité Copilot.

Une alerte de secret doit déclencher une action sur l’identifiant lui-même : retirer le secret du code ne révoque pas un jeton déjà divulgué.

Cette règle évite une réponse incomplète. Supprimer une ligne dans un commit ultérieur ne rend pas nécessairement l’identifiant inutilisable, notamment si la valeur demeure dans l’historique ou a déjà été copiée. Évaluez l’étendue des permissions, révoquez ou faites tourner le secret, recherchez les usages pertinents, puis corrigez la source de l’exposition. La détection automatisée accélère ce travail ; elle ne détermine pas seule l’impact opérationnel.

Durcir les workflows : permissions, déclencheurs et séparation des rôles

Un workflow CI/CD est du code qui s’exécute avec des permissions. Il faut donc examiner ses déclencheurs, les données qu’il traite, les secrets auxquels il accède et les actions qu’il peut effectuer. Un pipeline qui teste une contribution non fiable avec les droits du dépôt peut devenir un pont entre du code contrôlé par un attaquant et les ressources de l’organisation.

Un cas rapporté par OpenSSF en juin 2026 illustre ce risque : le déclencheur pull_request_target a permis à du code contrôlé par un attaquant de s’exécuter dans le contexte de sécurité du dépôt de base. Le problème ne tient pas seulement au nom d’un événement, mais au contexte de confiance dans lequel le code s’exécute. Passez en revue les workflows utilisant des contributions externes et vérifiez précisément quel code est exécuté, avec quelles permissions et à quel moment.

Réduire les privilèges à chaque étape

Ne donnez pas à l’ensemble d’un workflow les permissions nécessaires à sa dernière étape. Séparez les tâches de validation, d’empaquetage et de publication, puis accordez à chacune le minimum utile. Une étape qui compile du code fourni par un contributeur n’a généralement pas besoin des mêmes droits qu’une étape de publication déclenchée après approbation.

  • Déclarez explicitement les permissions accordées au workflow et aux tâches qui le composent.
  • Évitez d’exposer des secrets aux workflows déclenchés par du code non fiable.
  • Exigez une approbation ou une condition contrôlée avant les opérations de publication et de déploiement.
  • Examinez les actions tierces utilisées, leur version et les droits qu’elles reçoivent.
  • Traitez les changements de workflow comme des changements de sécurité, avec revue et historique.

La séparation des rôles limite la portée d’une compromission, mais elle apporte aussi un coût : davantage de règles, de transitions et de cas d’exception à maintenir. Documentez les frontières entre les tâches et automatisez autant que possible les vérifications. Une politique trop complexe, mal comprise ou régulièrement contournée finit par perdre son efficacité.

La gouvernance des secrets doit suivre la même logique. La roadmap 2026 de GitHub Actions met l’accent sur les secrets scopés et une meilleure gouvernance de bout en bout. L’idée opérationnelle est de rattacher un secret à un usage et à un périmètre définis, plutôt que de le rendre accessible à tous les workflows d’un dépôt ou d’une organisation. Vérifiez régulièrement que ces périmètres correspondent encore aux responsabilités réelles des équipes.

Rendre les builds hermétiques, déclaratifs et vérifiables

La sécurité ne s’arrête pas à la revue du dépôt. Un adversaire qui accède aux outils ou aux processus de build peut chercher à injecter du code malveillant dans les artefacts. Le guide de CISA destiné aux fournisseurs recommande une chaîne d’outils de confiance, configurée dans un état de base sûr et inventorié. Cela impose de connaître les outils de compilation, les extensions, les images et les environnements qui contribuent à produire le logiciel.

CISA recommande aussi de déclarer à l’avance les étapes, les sources et les dépendances transitives, et de privilégier des builds hermétiques avec des contrôles d’intégrité du transport et de signature du code. Un build hermétique limite les entrées implicites : il réduit la possibilité qu’une étape récupère silencieusement un composant ou un outil différent de celui attendu. La déclaration des entrées rend les builds plus inspectables et facilite la comparaison entre un résultat attendu et un résultat produit.

Passer d’un build implicite à un build reproductible

Dans un pipeline peu maîtrisé, l’environnement peut dépendre d’un téléchargement non versionné, d’une image modifiée ou d’un outil installé manuellement. L’objectif est de remplacer ces hypothèses par des entrées explicites et contrôlées. Cela ne signifie pas qu’il faut imposer immédiatement une architecture complexe à chaque projet : commencez par les applications les plus sensibles ou les étapes qui ont accès à des secrets de publication.

  1. Inventoriez les images, outils, actions, scripts et services employés pour construire chaque artefact.
  2. Déclarez les versions et les sources des composants nécessaires, y compris les dépendances transitives.
  3. Limitez les téléchargements non prévus pendant le build et contrôlez l’intégrité des entrées.
  4. Conservez les résultats et les métadonnées de construction permettant de relier l’artefact au code et aux outils utilisés.
  5. Protégez les clés de signature et restreignez leur accès à l’étape de publication autorisée.

La provenance répond à une question distincte de la vulnérabilité : comment cet artefact a-t-il été produit, et par quel processus ? Une signature peut aider à vérifier l’intégrité ou l’origine selon le dispositif mis en place, mais une signature apposée par un pipeline compromis ne rend pas le logiciel sain. Il faut donc protéger simultanément les outils de build, les permissions de signature et les informations décrivant la construction.

Le niveau de reproductibilité atteignable dépend des technologies et des contraintes du projet. Certains outils ou services rendent difficile une herméticité totale, et des builds fortement isolés peuvent demander des adaptations. Documentez les dépendances externes impossibles à éliminer, les contrôles compensatoires et les risques résiduels. La transparence sur ces limites est plus utile qu’une affirmation générale selon laquelle un build serait entièrement sécurisé.

Organiser la détection, la réponse aux incidents et les outils

Les contrôles préventifs réduisent la probabilité ou la portée d’un incident, mais ils ne garantissent pas qu’aucune dépendance ne sera compromise ni qu’aucun secret ne sera exposé. Une stratégie complète précise donc comment détecter, qualifier, contenir et corriger un problème. Les équipes doivent pouvoir répondre à des questions concrètes : quels produits utilisent ce paquet, quels workflows ont eu accès à ce jeton et quels artefacts ont été produits par ce pipeline ?

Préparez des procédures spécifiques selon le type d’événement. Pour une dépendance suspecte, identifiez les versions et les builds concernés, vérifiez les mises à jour disponibles et décidez si l’artefact doit être retiré ou remplacé. Pour un secret exposé, révoquez-le ou faites-le tourner, puis recherchez son usage. Pour un workflow compromis, suspendez les opérations sensibles, examinez les changements et les artefacts publiés, et rétablissez un état de confiance avant de relancer les déploiements.

Attribuer les alertes et mesurer le traitement

Une alerte sans responsable devient facilement un élément de backlog permanent. Définissez des propriétaires pour les applications, les dépendances critiques, les secrets et les pipelines. Pour chaque catégorie, établissez un chemin d’escalade et des critères de priorité adaptés au contexte métier. Une vulnérabilité dans un composant non exposé et une clé de publication publiquement divulguée ne demandent pas nécessairement la même réponse, même si les deux méritent une analyse.

  • Suivez le délai entre détection, qualification et correction, sans confondre vitesse et qualité de la réponse.
  • Consignez les exceptions acceptées, leur justification, les mesures de réduction du risque et leur date de réexamen.
  • Effectuez des exercices de révocation et de restauration pour vérifier que les procédures sont utilisables en situation réelle.
  • Après un incident, corrigez le contrôle manquant : permissions, source de dépendance, journalisation ou processus de revue.

Le choix des outils doit soutenir ce processus au lieu de le fragmenter. KuppingerCole et OpenSSF observent en 2026 une convergence de la SCA, de l’analyse statique du code (SAST), du secret scanning et de la gestion de posture vers des plateformes ASPM. Une plateforme intégrée peut faciliter la mise en relation des résultats et leur attribution, mais elle ne garantit pas que les alertes soient exactes ni traitées. Évaluez la qualité des intégrations, la couverture des dépôts et pipelines, les possibilités d’export et la capacité à gérer les exceptions.

Les scanners spécialisés restent pertinents lorsque vous avez besoin d’une capacité ciblée, d’une intégration particulière ou d’un contrôle indépendant. En contrepartie, plusieurs outils peuvent produire des doublons, des priorités incohérentes et une charge de triage élevée. Comparez les outils sur le parcours complet : découverte, contextualisation, affectation, correction et vérification. Le bon choix est celui qui permet aux équipes d’agir sur un risque compris, et non celui qui affiche le plus grand nombre de résultats.

La détection évolue avec les usages. GitHub a rapporté une moyenne de 26 correspondances d’identifiants par seconde dans le scanning public au T2 2026, en précisant que ces observations incluent des répétitions et que des partenaires révoquent rapidement plusieurs tokens. Ce chiffre illustre l’échelle des expositions observées publiquement, mais ne mesure pas directement le nombre de secrets uniques ni le risque d’une entreprise particulière. Il invite surtout à automatiser la détection et la révocation, tout en gardant une analyse contextuelle des alertes.

Étendre les contrôles aux outils de développement et à l’IA

Les environnements de développement ne se limitent plus aux dépôts et aux dépendances compilées. Les connexions à des serveurs MCP, les skills et les intégrations peuvent accéder à du code, à des fichiers de configuration ou à des services externes. Snyk décrit ces composants comme une nouvelle chaîne d’approvisionnement de développement, souvent installée hors des contrôles de sécurité établis. Les intégrer sans inventaire peut créer des accès qui échappent aux politiques appliquées au pipeline classique.

Un rapport de Snyk en 2026 indique que 50,8 % des développeurs scannés ont déjà des connexions MCP actives, et qu’un développeur sur douze présente un finding High ou Critical dans sa configuration. Ces résultats concernent les environnements analysés par Snyk ; ils ne constituent pas une mesure universelle de toutes les organisations. Ils montrent néanmoins pourquoi l’évaluation des outils connectés doit rejoindre les pratiques de sécurité du poste de développement et du code.

Établir une gouvernance proportionnée

Avant d’autoriser un nouvel agent ou une intégration, déterminez quelles données il peut lire, quels outils il peut appeler, quels identifiants il peut utiliser et quels contenus il peut envoyer à un service externe. Évaluez aussi la manière dont l’intégration est installée et mise à jour. Le même principe de moindre privilège s’applique ici : une extension destinée à assister une tâche précise ne doit pas recevoir un accès général aux dépôts, aux secrets et aux environnements de production.

Attribuez un propriétaire à chaque intégration, consignez les permissions et prévoyez la désactivation d’un accès lorsqu’il n’est plus nécessaire. Définissez les usages permis des données et les modalités de revue des changements apportés par un agent. Si un outil génère des modifications de code ou de configuration, soumettez-les aux mécanismes de validation habituels ; l’origine assistée par IA ne dispense ni des tests ni de la revue de sécurité.

L’IA accélère aussi la création et la mise à jour de dépendances. Sonatype met en garde contre un rythme de développement à machine speed susceptible de dépasser les programmes traditionnels de gestion des vulnérabilités. La réponse n’est pas de bannir automatiquement ces outils, mais de renforcer les points de contrôle où une suggestion devient une dépendance, un secret, une modification de workflow ou un artefact livrable. Automatisez les vérifications répétitives, puis réservez l’examen humain aux décisions qui exigent du contexte.

Déployer une feuille de route réaliste pour l’équipe

Une transformation efficace commence par les chemins qui pourraient causer le plus d’impact, et non par une tentative de refondre simultanément tous les dépôts. Faites un état des lieux des applications, des registres, des workflows disposant de secrets, des environnements de publication et des outils connectés. Utilisez cet inventaire pour ordonner les chantiers et identifier les dépendances entre eux.

  1. Établir une base visible : recensez les dépôts, les services, les dépendances, les secrets et les processus de build. Générez les SBOM nécessaires et nommez des responsables.
  2. Traiter les accès critiques : recherchez les secrets en clair, révoquez les identifiants exposés, remplacez les accès par défaut et séparez les secrets de build de ceux de publication.
  3. Réduire les permissions des workflows : examinez les déclencheurs, les contributions non fiables, les actions tierces et les droits par étape.
  4. Améliorer la maîtrise des dépendances : fixez des sources autorisées, rendez les mises à jour visibles et définissez un processus de triage des vulnérabilités et paquets suspects.
  5. Renforcer les builds : inventoriez les outils, déclarez les entrées, ajoutez des contrôles d’intégrité et protégez les opérations de signature et de publication.
  6. Tester la réponse : exercez-vous à révoquer un jeton, remplacer une dépendance et suspendre une publication afin de vérifier que les procédures sont réalisables.

Pour chaque étape, définissez un indicateur qui aide à décider. Par exemple, suivez la part des dépôts dont les propriétaires sont connus, la couverture des workflows par des permissions explicites ou la proportion d’alertes critiques avec un responsable. Évitez les indicateurs de volume seuls : multiplier les scans ou les alertes ne signifie pas automatiquement que le risque baisse.

Adaptez enfin l’effort au modèle de livraison. Une startup disposant de peu de services peut commencer par séparer les credentials de publication et protéger ses workflows les plus sensibles. Une organisation avec de nombreux produits devra probablement investir davantage dans l’automatisation de l’inventaire, le routage des alertes et la gouvernance commune. Dans les deux cas, la priorité reste de rendre les contrôles simples à appliquer et difficiles à contourner par inadvertance.

La chaîne d’approvisionnement logicielle se défend en limitant les permissions à chaque maillon : dépendances identifiables, secrets protégés et pipeline maîtrisé. Les SBOM rendent les composants visibles, les règles de moindre privilège réduisent l’impact d’un accès compromis et les builds déclaratifs aident à vérifier comment un artefact a été produit.

Commencez par un périmètre concret, une application, un workflow de publication ou un registre, puis mesurez les lacunes et corrigez-les avant d’étendre les contrôles. Pour une organisation qui prépare une modernisation de ses pratiques DevSecOps ou de ses outils de publication, Hurter & Co peut aider à concevoir des applications et des chaînes de livraison adaptées à ces exigences, de l’architecture au déploiement.