Développement de logiciels sécurisés

Le développement logiciel sécurisé intègre la sécurité à chaque phase de la création d'un logiciel — de la modélisation des menaces et de la conception sécurisée aux normes de codage, aux tests et à la révision — afin que les vulnérabilités soient prévenues plutôt que corrigées après la publication.

Definition

Le développement logiciel sécurisé est la discipline qui consiste à intégrer des activités et des contrôles de sécurité tout au long du cycle de vie du développement logiciel afin de réduire le nombre et la gravité des vulnérabilités dans les logiciels livrés.

Scope

Ce sujet couvre les pratiques et processus qui produisent des logiciels sécurisés : la modélisation des menaces, les principes de conception sécurisée, les normes de codage sécurisé, l'analyse statique et dynamique, le fuzzing, les tests de sécurité, la revue de code, ainsi que le cycle de vie du développement sécurisé et le DevSecOps. Il aborde la sécurité de la chaîne d'approvisionnement et des dépendances. Il exclut l'étude offensive de l'exploitation et l'analyse post-publication des logiciels malveillants, qui sont traitées dans des sujets connexes.

Core questions

• Comment la sécurité est-elle conçue dans le logiciel dès le départ plutôt que d'être ajoutée après coup ?
• Qu'est-ce que la modélisation des menaces et comment guide-t-elle la conception sécurisée ?
• Comment l'analyse statique, l'analyse dynamique et le fuzzing détectent-ils les vulnérabilités avant la publication ?
• Comment les activités de développement sécurisé sont-elles intégrées dans les pipelines CI/CD modernes (DevSecOps) ?
• Comment les risques liés aux dépendances tierces et à la chaîne d'approvisionnement logicielle sont-ils gérés ?

Key concepts

• modélisation des menaces
• principes de conception sécurisée
• normes de codage sécurisé
• tests de sécurité statiques des applications (SAST)
• analyse dynamique (DAST)
• fuzzing
• revue de code
• cycle de vie du développement sécurisé
• sécurité de la chaîne d'approvisionnement

Key theories

Cycle de vie du développement de la sécurité

Un processus structuré intègre des points de contrôle de sécurité à chaque phase de développement — exigences, conception (modélisation des menaces), implémentation (codage sécurisé, analyse), vérification (tests, fuzzing) et publication — réduisant de manière mesurable les vulnérabilités des logiciels livrés.

Décalage à gauche et assurance automatisée

Détecter et corriger les défauts tôt ('décalage à gauche') est bien moins coûteux qu'après le déploiement ; l'analyse statique/dynamique automatisée et le fuzzing intégrés dans l'intégration continue offrent une assurance évolutive et reproductible.

Mechanisms

Le développement sécurisé commence par la modélisation des menaces (par exemple, STRIDE) pour identifier les problèmes potentiels, éclairant une conception qui applique le principe du moindre privilège et la défense en profondeur. Pendant l'implémentation, les normes de codage sécurisé et l'analyse statique signalent les schémas risqués, tandis que l'analyse dynamique et le fuzzing soumettent le programme en cours d'exécution à des entrées malformées pour révéler les plantages et les erreurs de mémoire. La revue de code et les tests de sécurité précèdent la publication, et dans le cadre du DevSecOps, ces vérifications s'exécutent automatiquement dans le pipeline de construction, avec l'analyse des dépendances et les builds signés protégeant la chaîne d'approvisionnement.

Clinical relevance

Le développement sécurisé détermine la sécurité de base de presque tous les logiciels utilisés par les individus. L'adoption du SDL par Microsoft après 2002 a considérablement réduit les vulnérabilités de ses produits, le fuzzing continu (OSS-Fuzz de Google) détecte des milliers de bogues dans des codes open source largement utilisés, et les pratiques de la chaîne d'approvisionnement sont devenues urgentes après des attaques comme SolarWinds et Log4Shell. Ces pratiques façonnent les attentes réglementaires et les exigences d'approvisionnement.

Evidence & guidelines

Les cadres de référence incluent le SDL de Microsoft, OWASP SAMM et ASVS, BSIMM (une mesure de programmes réels), et le Secure Software Development Framework (SSDF, SP 800-218) du NIST. Les directives exécutives américaines exigent désormais une attestation SSDF pour les fournisseurs de logiciels gouvernementaux, et les normes SBOM (software bill of materials) soutiennent la transparence de la chaîne d'approvisionnement.

History

Le développement sécurisé est né de la reconnaissance, à la fin des années 1990 et au début des années 2000, que la correction des logiciels livrés n'était pas une solution évolutive. L'initiative Trustworthy Computing de Microsoft en 2002 a produit le Security Development Lifecycle, et l'ouvrage 'Software Security' (2006) de McGraw a codifié le principe de 'building security in' (intégrer la sécurité dès la conception). Les années 2010 ont intégré ces pratiques dans les flux de travail agiles et DevOps (DevSecOps) et, après des incidents majeurs de la chaîne d'approvisionnement, les ont étendues aux dépendances et à l'intégrité des builds.

Key figures

• Gary McGraw
• Michael Howard
• Steve Lipner
• Ross Anderson

Seminal works

• howard2006
• mcgraw2006
• anderson2020

Frequently asked questions

Qu'est-ce que la modélisation des menaces ?

La modélisation des menaces est une analyse structurée, réalisée pendant la phase de conception, de ce qu'un attaquant pourrait cibler et de la manière. Les équipes schématisent le système, énumèrent les menaces (souvent à l'aide d'une liste de contrôle comme STRIDE) et décident des mesures d'atténuation avant l'écriture du code, de sorte que la sécurité soit intégrée à l'architecture.

Pourquoi l'exécution d'un scanner de sécurité n'est-elle pas suffisante ?

Les scanners automatisés détectent de nombreux schémas connus mais manquent les défauts de conception, les erreurs de logique métier et les problèmes inédits, et ils produisent des faux positifs. Les programmes efficaces combinent l'analyse automatisée avec la modélisation des menaces, la revue manuelle et les tests tout au long du cycle de vie.