Pour la sécurité des applications : SCA, SAST, DAST et MAST. Et ensuite ?

J’ai regardé suffisamment de tableaux de bord de scanner pour reconnaître le modèle. SAST signale les failles théoriques qui ne s’exécutent jamais. DAST hausse les épaules car la route vers la fonction vulnérable est bloquée. SCA inonde la zone de CVE qui ne touchent jamais un chemin chaud. MAST gronde mon application mobile pour les secrets que j’ai retirés le trimestre dernier. Ces outils restent essentiels, mais ils constituent désormais une référence plutôt qu’une destination. Le prochain chapitre n’est pas une autre « solution miracle » ; c’est un changement vers la posture, la provenance et la preuve.

Au cours de l’année écoulée, la communauté a admis une évidence : le champ de bataille est la chaîne d’approvisionnement des logiciels et le système en cours d’exécution, et pas seulement les analyses préliminaires. La mise à jour 2025 de l’OWASP a élevé les défaillances de la chaîne d’approvisionnement logicielle au niveau A03, recadrant les composants vulnérables et obsolètes comme un risque systémique pour l’écosystème qui s’étend des dépendances, des systèmes de construction et de l’infrastructure de distribution (aperçu d’Endor Labs ici). En parallèle, la CISA a fait avancer les lignes directrices du SBOM avec un projet de 2025 qui exige des métadonnées plus riches et lisibles par machine et met l’accent sur l’automatisation à grande échelle.

Posture, provenance et preuve : La nouvelle trinité

La gestion de la posture de sécurité des applications (ASPM) est le plan de contrôle qui rend l’ancien quatuor à nouveau utile. Le rapport 2025 Innovation Insight de Gartner décrit comment ASPM connecte les signaux dispersés à travers le SDLC, applique les politiques et établit les priorités en fonction du contexte, comme l’accessibilité et l’exposition dans la pratique, ce qui signifie rassembler les résultats SAST, DAST, SCA, IaC et d’exécution dans une seule vue, puis filtrer le petit sous-ensemble qui compte vraiment.

Je préfère encadrer l’ASPM à travers un code plutôt qu’une lentille cloud, car cela reflète le fonctionnement réel de nos systèmes. Le guide de la Wiz Academy présente les principales fonctionnalités d’ASPM, la visibilité unifiée, la priorisation des risques, l’application des politiques et met l’accent sur la découverte continue tout au long du développement, de la construction et du déploiement. L’objectif est de réduire la fatigue des alertes tout en reliant les problèmes de code à l’impact sur l’exécution de l’ASPM. Cela correspond au principe de Gartner mais ajoute des détails pratiques sur la corrélation des signaux du référentiel, des politiques de pipeline et de la réalité du cloud.

La posture est le « quoi ». La provenance est le « comment ». Le cadre SLSA nous offre un vocabulaire partagé et des contrôles vérifiables pour prouver que les artefacts ont été construits par des pipelines renforcés et inviolables avec des attestations signées auxquelles les consommateurs en aval peuvent faire confiance (aperçu d’OpenSSF ici). Lorsque j’insiste sur le niveau SLSA 2 pour la plupart des services et sur le niveau 3 pour les chemins critiques, je ne poursuis pas le théâtre de la conformité ; J’achète une intégrité qui survit aux audits et aux incidents.

La preuve est que les SBOM grandissent enfin. Lier la génération SBOM à la version qui émet les bits déployables, les signer et les valider au moment du déploiement déplace les SBOM des « listes d’ingrédients » vers des contrôles exécutoires. Le document CNCF TAG‑Security best practices v2 contient ma carte pratique, mes personnages, VEX pour l’exploitabilité, ma vérification cryptographique pour garantir que les tests ont bien été exécutés et mes conseils prescriptifs pour les usines cloud natives.

Avis : si votre SBOM décrit l’intention du développeur plutôt que ce qui s’exécute, vous manquerez le prochain rappel. Générez des SBOM à partir de la version qui a produit le binaire, signez-les, ingérez les déploiements VEX et gate après vérification.

Des tableaux de bord aux décisions : l’ASPM en pratique

Un programme de posture est un ensemble d’habitudes, pas seulement une plateforme. Je commence par unifier les résultats des scanners dans un seul registre des risques, mais je refuse de trier en vase clos. Les résultats doivent contenir des preuves d’accessibilité, des balises de sensibilité des données et le contexte d’exposition. C’est là que l’ASPM gagne sa place. Le matériel de la Wiz Academy souligne ce code pour la connexion au cloud et montre comment réduire le bruit afin que les développeurs voient les quelques problèmes qui bloquent l’activité plutôt qu’un mur de risques théoriques. Le cadre de Gartner plaide en faveur de l’adoption dans les environnements réglementés où les signaux fragmentés nuisent à la vitesse de remédiation.

Deux notes d’implémentation de mes propres programmes. Tout d’abord, connectez ASPM aux propriétaires. Chaque découverte nécessite un résolveur et un SLA, ou il s’agit simplement d’un rapport. Deuxièmement, bloquez les constructions risquées. L’application des politiques n’est pas un tableau de bord ; c’est une décision. Si un artefact n’a pas de provenance ou si un VEX montre une exploitabilité dans un chemin accessible, il n’est pas expédié.

Avis : Conservez une seule source de vérité politique. Si la politique de sécurité réside dans trois outils, les développeurs les ignoreront tous les trois.

Rigueur de la supply chain sans théâtre

Le travail lié à la chaîne d’approvisionnement peut se transformer en paperasse si nous oublions ce qui compte. L’intégrité est le point important. Je garde SLSA simple. Niveau 2 rapidement, Niveau 3 pour les chemins critiques. Cela signifie un service de build renforcé, des builds isolés, une provenance signée et une chaîne vérifiée de la source à l’artefact. Les SBOM deviennent opérationnels une fois qu’ils sont lisibles par machine, signés et validés lors du déploiement. Le projet 2025 de CISA a resserré les attentes en matière de champs, de formats et d’automatisation, ce que je salue car il rend les achats et la réponse aux incidents plus rapides et plus propres.

Le document du CNCF comble les lacunes. Il explique comment coupler les SBOM avec VEX, ajouter des contrôles cryptographiques pour les étapes du pipeline et traiter l’infrastructure des développeurs comme faisant partie de la chaîne d’approvisionnement. Ce dernier point est important car les attaquants ciblent de plus en plus les référentiels, les paramètres CI et les registres d’artefacts, et pas seulement les dépendances du code. Les orientations du secteur public de la CNCF font écho aux mêmes priorités pour les charges de travail du gouvernement, avec des leçons concrètes de SolarWinds, Log4Shell et xz.

Avis : n’acceptez jamais un vendeur SBOM sans signature et attestation de provenance. S’ils ne peuvent pas prouver comment le logiciel a été créé, votre calcul des risques n’est qu’une conjecture.

Réalité d’exécution : des instruments, pas des illusions

Les tests préliminaires sont nécessaires mais pas suffisants. L’instrumentation IAST me donne la vérité d’exécution pendant le contrôle qualité, en observant les chemins d’exécution réels pour réduire les faux positifs et préserver le contexte du développeur. En production, le modèle mental passe à RASP, qui bloque l’exploitation au sein de l’application au moment précis où des opérations risquées se produisent : construction SQL, exécution du système d’exploitation, sérialisation, là où les WAF ne peuvent pas voir. Il ne s’agit pas d’une atteinte aux WAF ; c’est une reconnaissance du fait que l’inspection de la couche réseau et l’introspection de la couche application résolvent des problèmes différents.

Si vous pensez que les contrôles périmétriques sont suffisants, deux semaines en novembre 2025 devraient dissiper ce sentiment. La CISA a publié des directives d’urgence pour les vulnérabilités Cisco ASA et FTD (CVE‑2025‑20333, CVE‑2025‑20362) parce que les agences ont signalé des appareils comme « corrigés » qui se trouvaient toujours dans les trains vulnérables. La directive prescrivait des versions minimales, des contrôles médico-légaux et des délais, et rappelait à tous que tous les appareils doivent être mis à jour, pas seulement ceux connectés à Internet (communiqué de presse de la CISA).

La leçon est portable : traitez « patché » comme un état avec des preuves. Validez les trains à libération minimale, vérifiez l’ensemble de la flotte et mettez hors service les équipements de fin de support. Associez les contrôles de périmètre aux capteurs de la couche d’application et à la protection de l’exécution des conteneurs, car vos charges de travail résident de plus en plus dans Kubernetes et sur des plateformes gérées. Les analyses de marché confirment l’évolution vers des domaines cloud natifs orchestrés où une politique d’exécution cohérente est possible (article de tendance CNCF ici).

Conseil : connectez la télémétrie d’exécution à votre cabinet TDIR. Lorsque RASP bloque une injection en production, cet événement devrait générer des correctifs de code, pas seulement une alerte fermée.

Sécuriser l’IA et les écosystèmes de la chaîne d’approvisionnement

Parmi les suivantes, l’IA est la plus mercurielle. Les directives finales du NIST pour 2025 sur le ML contradictoire divisent les menaces entre PredAI et GenAI et désignent l’injection rapide sous forme directe et indirecte comme l’exploit dominant dans les systèmes agentiques où des instructions fiables se mélangent à des données non fiables (Meritak Overview ; IBM explicatif). L’AI Safety Institute des États-Unis a publié des travaux sur les évaluations du détournement d’agents, que je considère comme une lecture obligatoire de l’équipe rouge pour quiconque délègue des actions à des outils (blog NIST AISI).

Pour les constructeurs, le profil communautaire NIST SP 800‑218A de juillet 2024 étend SSDF aux modèles de fondations génératives et à double usage. Il couvre les invites de modélisation des menaces, la sécurisation des pipelines de données de formation, l’isolation des opérations de modèle et la liaison de la documentation du modèle pour sécuriser les pratiques de développement.

Au niveau linguistique, une recommandation démodée est devenue courante. En juin 2025, la NSA et la CISA ont préconisé l’adoption de langages sécurisés en mémoire avec des conseils de migration pragmatiques pour les domaines existants : commencer là où cela compte le plus, intégrer progressivement et protéger les anciens modules derrière des FFI renforcés (NSA/CISA CSI).

Choix de langage qui effacent des classes de bogues entières

Si vous souhaitez supprimer des classes de vulnérabilité, arrêtez de les écrire. En juin 2025, la NSA et la CISA ont publié un CSI conjoint appelant à l’adoption de langages sécurisés en mémoire avec des conseils de migration pragmatiques pour les domaines existants. Commencez là où cela compte, intégrez progressivement et protégez les anciens modules derrière un FFI renforcé. Ce n’est pas une posture académique. Les débordements de tampon, l’utilisation après la gratuité et les courses aux données érodent la résilience et coûtent de l’argent réel. Les langages sécurisés en mémoire réduisent ces risques dès leur conception.

Conseil : imposez des langages sécurisés en mémoire pour les nouveaux développements nets, planifiez les migrations pour les modules à haut risque et publiez une piste avec des dates et des métriques. Expliquez le pourquoi en utilisant les conseils de la NSA et de la CISA, puis mesurez les résultats.

Où s’intègrent désormais SCA, SAST, DAST et MAST

Ils restent fondamentaux lorsqu’ils sont intégrés à un programme centré sur la posture.

• SAST détecte toujours les défauts de conception et de mise en œuvre, mais j’insiste sur l’analyse de l’accessibilité et la correction prioritaire par le développeur au sein de l’IDE ; introduisez SAST dans ASPM pour le contexte afin que les problèmes théoriques ne submergent pas les problèmes réels.
• DAST est indispensable pour l’exposition avant la sortie, mais je l’associe à IAST pour observer les chemins de code en direct et réduire les faux positifs.
• SCA va au-delà des listes CVE lorsque la génération SBOM se lie aux builds et que VEX réduit le bruit ; Les meilleures pratiques du CNCF et le projet SBOM 2025 de la CISA décrivent comment bien procéder.
• MAST maintient le renforcement mobile honnête, mais j’intègre les contrôles secrets d’hygiène et de stockage sécurisé dans les mêmes contrôles de cycle de vie que ceux utilisés pour les applications serveur.

Conseil en leadership : ce que je mets en œuvre ensuite

C’est le modèle opérationnel que j’ai mis en œuvre dans des environnements réglementés qui ne peuvent pas se permettre de se tromper.

1. ASPM comme plan de contrôle. Unifiez les signaux, dupliquez et classez par exploitabilité : accessibilité, exposition, sensibilité des données. Acheminez automatiquement la propriété et utilisez des barrières de politique sur les builds à risque.
2. Rigueur de la supply chain. Adoptez les niveaux SLSA, exigez des SBOM et des attestations signés, et validez lors du déploiement. Pas d’artefact sans provenance, pas de déploiement sans vérification.
3. Protection d’exécution. Intégrez RASP dans les piles d’applications, appliquez des contrôles d’exécution des conteneurs et gardez WAF à la pointe. Câblez les événements à votre pipeline TDIR afin que le blocage en production déclenche des correctifs dans le code.
4. Cycle de vie des secrets et identités des machines. Sauvegarde centralisée, rotation automatisée, moindre privilège partout, TLS mutuel pour l’authentification de service à service.
5. Programme de sécurité IA. Adoptez le NIST SP 800‑218A, les agents de l’équipe rouge pour le piratage, appliquez la séparation des privilèges et surveillez les sorties.
6. Politique linguistique. Mandatez des langages sécurisés en mémoire pour le nouveau développement Internet, planifiez les migrations pour les modules à haut risque et utilisez les conseils de la NSA/CISA pour éduquer les parties prenantes.

Conclusion

SCA, SAST, DAST et MAST restent la base, mais ils sont plus efficaces lorsqu’ils sont orchestrés par ASPM, éprouvés par SLSA et SBOM et défendus par des contrôles d’exécution. Ajoutez des protections spécifiques à l’IA et des langages sécurisés pour la mémoire, et vous passerez de la recherche de résultats à la prise de décisions en toute confiance. C’est mon « et ensuite ».

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?