Alors que les produits numériques sont de plus en plus intégrés dans les infrastructures critiques et la vie quotidienne, la maturité des pratiques de développement sécurisé fait l’objet d’un examen de plus en plus minutieux. La loi de l’Union européenne sur la cyber-résilience (CRA) et les réglementations connexes telles que NIS2 accélèrent la nécessité pour les organisations d’adopter des principes de sécurité dès la conception. Pourtant, malgré une prise de conscience croissante, la maturité des pratiques de développement sécurisé reste inégale d’un secteur à l’autre. Ce document explore l’état actuel de la maturité du développement sécurisé en utilisant les données de référence SAMM de l’OWASP. Il examine également l’influence de la taille de l’organisation et du secteur sur l’état de préparation. Enfin, il explique comment des programmes structurés de sécurité des applications peuvent combler l’écart entre les pratiques actuelles et les attentes réglementaires.
Comprendre le paysage actuel du développement sécurisé
Le modèle de maturité de l’assurance logicielle de l’OWASP (SAMM) est devenu un cadre largement adopté pour l’évaluation et l’amélioration des pratiques de sécurité logicielle. Il évalue la maturité dans cinq domaines : la gouvernance, la conception, la mise en œuvre, la vérification et les opérations. Selon les dernières données de référence, le score moyen de maturité des organisations est de 1,44 sur 3,0. Cela suggère que si de nombreuses entreprises ont mis en place des pratiques de développement sécurisées, peu d’entre elles les ont institutionnalisées d’une manière reproductible et mesurable.
Un examen plus approfondi des données révèle que les niveaux de maturité varient considérablement en fonction de la taille et du secteur de l’organisation. Les grandes entreprises, en particulier celles des secteurs réglementés tels que la finance et la santé, ont tendance à avoir des structures de gouvernance plus formelles et des équipes dédiées à la sécurité des applications. Cependant, elles ont souvent du mal à mettre en place des pratiques sécurisées dans des environnements de développement complexes et distribués.
En revanche, les PME sont généralement plus agiles et ouvertes à l’adoption d’outils DevSecOps modernes, mais elles manquent souvent de feuilles de route structurées, de rôles dédiés à la sécurité et de ressources pour répondre aux exigences de conformité.
Les organisations du secteur public et les opérateurs d’infrastructures critiques font souvent preuve d’une plus grande maturité en matière de documentation et d’auditabilité, sous l’impulsion de mandats réglementaires. Cependant, ils sont également limités par des systèmes hérités et des cycles d’approvisionnement qui peuvent ralentir l’adoption de pratiques de sécurité modernes.
Pression réglementaire : CRA et NIS2
La loi sur la cyberrésilience introduit un ensemble complet d’exigences en matière de cybersécurité pour les produits et services numériques dans l’UE. Elle s’applique aux fabricants, aux importateurs et aux distributeurs. Il s’agit notamment de l’obligation de mettre en œuvre la sécurité dès la conception et la gestion des risques, d’assurer un traitement continu des vulnérabilités et de garantir la traçabilité des mesures de sécurité tout au long du cycle de vie du produit, y compris une documentation et une communication adéquates aux utilisateurs finaux.
La directive NIS2 étend ces attentes aux entités essentielles et importantes dans tous les secteurs (tels que l’énergie, les transports, la santé, l’infrastructure numérique), en mettant l’accent sur la gestion des risques, le signalement des incidents et la sécurité de la chaîne d’approvisionnement.
Ces réglementations ne sont pas de simples listes de contrôle : elles exigent des preuves tangibles de pratiques de développement sécurisées. Les organisations doivent être en mesure de démontrer que la sécurité est intégrée dès les premières étapes de la conception jusqu’au déploiement et à la maintenance, sous peine de se voir infliger de lourdes amendes. Ce passage d’une sécurité réactive à une sécurité proactive exige une transformation culturelle autant que technique, ce qui signifie une gouvernance structurée et des processus reproductibles tout au long du cycle de vie du logiciel.
Au-delà de la conformité réglementaire, la sécurité est de plus en plus reconnue comme une pierre angulaire de la qualité et un facteur essentiel de différenciation sur le marché. Les clients et les partenaires privilégient les produits et les services sécurisés, car ils comprennent les risques associés aux vulnérabilités. Des études soulignent encore les enjeux. Plus de la moitié des petites entreprises victimes de cyberattaques sont contraintes de fermer leurs portes dans les six mois, ce qui souligne l’importance vitale de mesures de sécurité proactives.
Lacunes dans l’état de préparation
Malgré l’urgence et la prise de conscience croissante, de nombreuses organisations ne sont pas encore prêtes à répondre aux exigences de ces réglementations. L’un des problèmes les plus courants est l’absence d’une évaluation structurée des pratiques actuelles. Sans une compréhension claire de leur situation, les organisations ont du mal à identifier des améliorations ou à allouer des ressources de manière efficace.
La première étape consiste à effectuer une évaluation de base à l’aide de modèles de maturité tels que OWASP SAMM ou BSIMM. Cela permet d’obtenir une image claire des forces et des faiblesses de l’organisation et d’identifier les lacunes par rapport aux exigences réglementaires. Les experts du secteur discutent actuellement de la manière d’utiliser le SAMM pour déterminer la conformité à l’ARC, et les premières estimations montrent que, sur la base des données de référence, la plupart des entreprises ne sont pas encore prêtes. C’est encore plus vrai pour les PME, qui sont également soumises à la réglementation.
Astuce : des outils comme SAMMY peuvent vous aider à suivre votre évaluation et à définir des objectifs. Ils intègrent également les exigences attendues de l’ARC, ce qui vous permet de fixer des objectifs pour atteindre la conformité..,
Figure 1– Évaluation de SAMM et objectifs de l’ARC dans SAMMY
L’absence d’une hiérarchisation cohérente des risques constitue un autre défi. Les efforts en matière de sécurité sont souvent réactifs, motivés par des incidents ou des audits, plutôt qu’alignés sur les risques et les objectifs stratégiques de l’entreprise. Il en résulte des initiatives fragmentées qui ne parviennent pas à apporter des améliorations durables.
L’habilitation des développeurs constitue également une lacune importante. Les pratiques de codage sécurisé ne sont pas systématiquement intégrées dans les flux de travail quotidiens, et la formation se limite souvent à des sessions ponctuelles plutôt qu’à un apprentissage continu. En outre, les outils de sécurité sont souvent ajoutés au processus de développement plutôt qu’intégrés à la chaîne d’outils, ce qui entraîne des frictions et une faible adoption.
La nécessité d’un programme clair de sécurité des applications
Pour relever les défis de la maturité en matière de développement sécurisé, les organisations ont besoin d’un programme structuré de sécurité des applications, adapté à leur contexte et à leur niveau de maturité.
Sur la base de cette évaluation, une feuille de route adaptée devrait être élaborée. Cette feuille de route devrait comprendre des actions à court terme pour combler les lacunes critiques, des initiatives à moyen terme pour renforcer les capacités fondamentales et des objectifs à long terme pour institutionnaliser les pratiques de développement sécurisé. La feuille de route doit être basée sur les risques et alignée sur les priorités commerciales et réglementaires afin de garantir le soutien de la direction et un investissement durable.
L’intégration de la chaîne d’outils est importante et les contrôles de sécurité devraient être intégrés dans les pipelines CI/CD. Cela permettra une vérification et une traçabilité continues, avec des outils tels que SAST, DAST, SCA. Cependant, comme un outil n’est bon que dans la mesure où son utilisateur l’est aussi, l’habilitation des développeurs devrait être un pilier central du programme. Il s’agit notamment de fournir une formation adaptée aux différents rôles, d’intégrer des directives de codage sécurisé dans les flux de développement et d’offrir un apprentissage pratique.
Enfin, des structures de gouvernance doivent être mises en place pour garantir la responsabilité et la surveillance. Il s’agit notamment de définir les rôles et les responsabilités, de fixer des indicateurs clés de performance mesurables et de mettre en place des tableaux de bord pour suivre les progrès accomplis. Des révisions et des mises à jour régulières du programme sont essentielles pour s’adapter à l’évolution des menaces et des attentes réglementaires.
Orientations pour faire de la sécurité une capacité stratégique
Parallèlement, il est important de reconnaître que toutes les organisations n’ont pas l’expertise interne ou la capacité de mettre en place et de maintenir un programme de développement sécurisé mature par elles-mêmes. C’est particulièrement vrai pour les petites entreprises ou celles qui travaillent dans des secteurs où la cybersécurité n’est pas traditionnellement au cœur des préoccupations. Dans ces cas, le partenariat avec des experts externes peut être une stratégie pragmatique et efficace.
Les organisations externes, qu’il s’agisse de cabinets de conseil spécialisés, de fournisseurs de sécurité ou d’alliances sectorielles, peuvent apporter un soutien essentiel sous la forme d’évaluations, de développement de feuilles de route, de formations, de normes, d’intégration de chaînes d’outils, voire d’un leadership intérimaire en matière d’AppSec. Ces partenariats peuvent accélérer la maturité, réduire la charge des équipes internes et garantir l’alignement sur les attentes réglementaires en constante évolution. Il est important de noter qu’ils offrent également une perspective extérieure qui permet de remettre en question les hypothèses et de découvrir les angles morts que les équipes internes peuvent négliger.
En combinant l’engagement interne et les conseils externes, les organisations peuvent mettre en place une capacité de développement sécurisée qui est à la fois résiliente et évolutive, quel que soit leur point de départ.
Conclusion
La convergence de la pression réglementaire et des cybermenaces croissantes fait de la maturité du développement sécurisé un impératif stratégique. En fin de compte, atteindre la maturité en matière de développement sécurisé n’est pas une destination, mais un voyage permanent. Les organisations doivent rester agiles et adapter leurs programmes en encourageant une culture de la sécurité, en investissant dans la formation et en tirant parti des capacités internes ainsi que de l’expertise et des outils externes. Elles peuvent transformer la sécurité des applications d’une obligation de conformité en un avantage stratégique. Cette approche proactive permettra non seulement de protéger leurs opérations, mais aussi d’inspirer confiance aux parties prenantes, en démontrant leur engagement en faveur de l’innovation et de la résilience face à l’évolution des défis.
Vous avez besoin d’aide ? Jetez un coup d’œil à nos solutions de développement sécurisé.
