Un cadre pour l'intégration de la sécurité applicative dans le génie logiciel (FIASSE) utilisant le modèle d'ingénierie logicielle sécurisable (SSEM)
# Un cadre pour intégrer la sécurité applicative dans l'ingénierie logicielle (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **Remarque :** Ce dépôt est un travail en cours. Les contributions sont les bienvenues ! ## Aperçu TL;DR : veuillez lire la [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). Explorez le [site web FIASSE](https://fiasse.org). Visitez les [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) pour contribuer. Ce dépôt contient des ressources et des documents pour le cadre OWASP pour l'intégration de la sécurité applicative dans l'ingénierie logicielle (FIASSE). FIASSE (prononcé /feiz/ comme « phase ») est un cadre indépendant des fournisseurs qui promeut une **approche fondée sur des principes et centrée sur les développeurs** pour construire des logiciels **sécurisables**. Il reconnaît que la sécurité est un processus dynamique et continu, comme le développement. Il introduit le Modèle d'ingénierie logicielle sécurisable (SSEM) comme **langage de conception commun** qui utilise des termes d'ingénierie logicielle établis pour intégrer la sécurité dans l'architecture, la conception et l'ingénierie logicielles en ancrant la sécurité dans les principes qui façonnent le code lui-même. Le cadre permet aux équipes de développement d'ajouter de la valeur informatique de manière résiliente tout en réduisant la probabilité d'un impact matériel dû à des événements cyber au cours de la durée de vie du code. FIASSE est un cadre de création. Il traite de la manière dont la sécurité est mise en œuvre dans les logiciels, en reliant directement les décisions d'ingénierie à des résultats sécurisables. Ce n'est pas un cadre d'assurance, un modèle de maturité, ni un remplacement pour les catalogues de contrôles ou les métriques de vulnérabilités. Il complète ces approches et allège la pression en aval sur l'assurance et la conformité. ## Objectif Fournir des lignes directrices pratiques qui **autonomisent les développeurs** pour créer des logiciels sécurisables sans nécessiter une expertise approfondie en sécurité, et guider les professionnels de la sécurité dans l'intégration efficace de leur expérience en sécurité dans l'ingénierie logicielle. FIASSE y parvient à travers un **prisme d'ingénierie logicielle**, réduisant la charge cognitive et favorisant la collaboration entre les équipes de développement et de sécurité. ## En quoi est-ce différent ? Alors que les projets axés sur l'assurance comme l'OWASP Top 10 mettent en évidence ce qu'il faut éviter (une liste de blocage), OWASP FIASSE fournit un ensemble d'attributs et de pratiques positifs à suivre (une liste d'autorisation). Cette approche s'appuie sur les compétences existantes en ingénierie logicielle pour construire des logiciels sécurisables, plutôt que d'exiger des développeurs qu'ils apprennent des techniques d'exploitation ou adoptent un état d'esprit axé sur les vulnérabilités. L'accent est mis sur la possibilité d'un codage sécurisé et pratique grâce à des principes d'ingénierie familiers. En définissant clairement le rôle pratique de la sécurité dans le processus de développement, ce cadre garantit que la valeur métier est capturée efficacement. Fixer des attentes de sécurité explicites avant l'écriture du code réduit la probabilité que des failles de sécurité soient découvertes et nécessitent une remédiation ultérieure. Une adoption efficace devrait améliorer les métriques d'assurance existantes, réduire le va-et-vient des constats, produire des correctifs plus durables et raccourcir le temps de remédiation. ## Valeurs fondamentales FIASSE est orienté par quatre valeurs fondamentales. Chacune exprime une préférence relative : les deux côtés ont de la valeur, mais lorsqu'il faut faire des choix, FIASSE privilégie celui de gauche. - **Les attributs sécurisables plutôt que les contrôles de sécurité** : privilégier les qualités d'ingénierie qui permettent de construire et de maintenir un système défendable plutôt que les contrôles de sécurité ajoutés après coup pour compenser des faiblesses. - **La participation plutôt que l'évaluation** : privilégier un engagement structuré entre la sécurité et le développement tout au long du cycle de vie plutôt qu'une évaluation réalisée une fois le travail terminé. - **Les principes premiers de l'ingénierie plutôt que le jargon de sécurité** : privilégier l'ancrage dans les principes premiers établis de l'ingénierie logicielle plutôt que le jargon spécifique à la sécurité ou les heuristiques adverses. - **La valeur métier plutôt que l'activité de sécurité** : privilégier une sécurité qui soutient la création de valeur de l'organisation plutôt qu'une sécurité poursuivie comme une fin en soi. ## Principes clés - **Le paradigme sécurisable** : Il n'existe pas d'état statique de « sécurisé ». Un système déclaré sécurisé aujourd'hui peut être vulnérable demain. FIASSE réoriente l'objectif d'ingénierie de « est-il sécurisé ? » vers « est-il construit de manière à ce que la sécurité puisse être maintenue ? » grâce à la résilience adaptative, à la sécurité évolutive et à l'amélioration continue. - **Ajouter de la valeur informatique de manière résiliente** : La directive première de l'ingénierie logicielle dans un contexte business. Le logiciel doit répondre aux exigences fonctionnelles tout en préservant les qualités sécurisables qui lui permettent de résister au changement, à la contrainte et aux attaques qui suivent chaque changement. - **Mission de sécurité : réduire l'impact matériel** : La mission de la sécurité est de réduire la probabilité d'un impact matériel d'un cyber-événement. L'élimination complète des violations n'est pas un objectif business réaliste, les stratégies de sécurité doivent donc s'aligner sur les objectifs business et l'appétence au risque. - **La relation qualité-sécurité** : La sécurité ne peut pas dépasser la qualité du logiciel. Les qualités qui rendent un logiciel facile à comprendre, à modifier, à tester et à observer sont les mêmes qualités qui rendent sa sécurisation possible. L'investissement dans la qualité d'ingénierie est un investissement de sécurité. - **Sécurité centrée sur le développeur** : Donner aux ingénieurs logiciels les moyens de construire des systèmes sécurisables en utilisant des principes d'ingénierie logicielle familiers, plutôt que de leur imposer d'adopter l'état d'esprit d'un testeur d'intrusion. - **SSEM comme langage de conception commun** : Utiliser des termes d'ingénierie logicielle établis (par exemple, Analysabilité, Modifiabilité, Testabilité) pour définir et discuter les attributs de sécurité. Cela rend la sécurité accessible aux développeurs et donne aux professionnels de la sécurité une base partagée pour l'évaluation. - **Aligner la sécurité sur les objectifs de développement et business** : La sécurité et le développement sont complémentaires, non adversariaux. L'AppSec participe tôt au SDLC, en particulier lors de la collecte des exigences et de la planification des fonctionnalités, afin que les attentes soient explicites avant l'écriture du code. - **Le principe de transparence** : Les systèmes sont conçus de manière à ce que les parties autorisées puissent comprendre l'état interne et le comportement. La journalisation structurée, l'instrumentation et les pistes d'audit sont intégrées dans le code plutôt que fournies uniquement par des outils externes. - **Le principe du moindre étonnement** : Les systèmes se comportent de manière intuitive et prévisible pour les utilisateurs, les développeurs et les administrateurs. La prévisibilité facilite l'analyse, réduit la charge cognitive et rend les frontières de confiance claires. - **Les exigences comme citoyen de première classe en AppSec** : Les fonctionnalités de sécurité, les scénarios de menace et les critères d'acceptation de sécurité sont livrés via le processus d'exigences. Les vulnérabilités découlent souvent d'une attente qui n'a jamais été spécifiée, cet écart relève donc du processus d'exigences. ## Principes d'ingénierie La section 4 du framework donne aux développeurs des principes qui s'appliquent directement au niveau du code : - **Le principe de contrôle des frontières** : La flexibilité à l'intérieur d'un système est un atout d'ingénierie à préserver. Le contrôle à chaque frontière de confiance est une exigence de sécurité à appliquer. - **Traitement canonique des entrées** : Canonicaliser, valider et assainir les entrées au point d'entrée. Le **principe d'analyse canonique** analyse les entrées externes en un type interne canonique à la frontière et échoue de manière sûre lorsque l'analyse n'aboutit pas. - **Le principe d'intégrité isolée** : Les valeurs critiques pour l'intégrité telles que les prix, les rôles et l'état des objets sont dérivées de sources autoritaires côté serveur. Elles ne sont jamais acceptées directement depuis un client. - **Codage résilient** : Les pratiques de codage défensif garantissent une exécution prévisible. Elles incluent le typage fort, la validation des entrées aux frontières de confiance, l'encodage des sorties, une gestion complète des erreurs, une gestion sûre des ressources, une défaillance gracieuse et sécurisée, et le moindre privilège au niveau du code. - **Gestion des dépendances** : Appliquer les attributs SSEM lors de la sélection, de l'intégration, de la surveillance et de la maintenance des dépendances pendant toute la durée de la relation. ## Le modèle d'ingénierie logicielle sécurisable (SSEM) SSEM définit les attributs qui rendent un logiciel sécurisable. Les équipes fixent des objectifs pour chaque attribut, évaluent les systèmes par rapport à ceux-ci et s'améliorent de manière incrémentale. Les attributs sont organisés en trois catégories : | **Maintenabilité** | **Fiabilité de confiance** | **Fiabilité** | |:--------------------|:-------------------:|----------------:| | Analysabilité | Confidentialité | Disponibilité | | Modifiabilité | Responsabilité | Intégrité | | Testabilité | Authenticité | Résilience | | Observabilité | | | SSEM ne comporte pas d'attribut d'Autorisation par conception. L'autorisation est une fonctionnalité de sécurité qui est recueillie en tant qu'exigence et mise en œuvre selon des critères d'acceptation. Les attributs ci-dessus sont ce qui rend une telle fonctionnalité sécurisable. L'annexe A du framework décrit des approches pour mesurer chaque attribut. ## Contenu du dépôt - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md) : le framework FIASSE complet et la spécification SSEM en un seul document. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework) : le framework divisé en un fichier par section. Ces fichiers de section constituent la source de vérité du framework. L'[index de code](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) sépare les sections qui s'appliquent directement au code des sections relatives aux processus, aux rôles et à l'adoption. [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) fournit un index pour les modèles de langage. - [skills/](https://github.com/owasp/fiasse/blob/main/skills) : FIASSE et SSEM empaquetés sous forme de skills pour les agents de codage IA (voir ci-dessous). - TODO : Guides d'implémentation pour la méthodologie FIASSE - Les exemples ont été déplacés vers [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) ## Pour commencer 1. Consultez la documentation dans le répertoire [docs](https://github.com/owasp/fiasse/blob/main/docs). Commencez par le [framework complet](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md), ou utilisez l'[index de code](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) pour trouver les sections qui s'appliquent au code concerné. 2. Discutez des concepts et des principes avec vos équipes et dans les [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. Commencez à appliquer les principes dans vos pratiques d'ingénierie logicielle telles que la collecte des exigences, les revues de fusion et l'ingénierie de prompts. 4. Suivez les étapes d'adoption de la section 8 du framework : évaluer les pratiques actuelles, intégrer la terminologie SSEM, identifier les influenceurs clés, éduquer et former les équipes, adopter l'outillage AppSec agentique comme soulagement de capacité, favoriser la collaboration, et surveiller et améliorer en continu. - Bonus : Installez le plugin correspondant à votre IDE ou à votre agent en ligne de commande propulsé par l'IA de votre choix (par exemple GitHub Copilot, Claude Code, OpenCode, etc.) et utilisez les prompts fournis pour générer du code sécurisable. Recherchez « Securability Engineering » ou « FIASSE » dans la bibliothèque de prompts. - FIASSE est également inclus dans le cadre de l'[OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## Skills pour les agents de codage IA Le répertoire [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) empaquette FIASSE/SSEM sous forme de skills prêtes à l'emploi pour les agents de codage IA qui prennent en charge le format [Agent Skills](https://code.claude.com/docs/en/skills) (par exemple Claude Code). Copiez le répertoire de skill dont vous avez besoin dans le chemin de skills de votre agent. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)** : Une référence compacte et entièrement autonome couvrant les dix attributs SSEM et les principes fondamentaux (No Static State of Secure, Isolated Integrity, Canonical Input Handling, Boundary Control, Least Astonishment). Destinée à être utilisée par défaut pour la génération et la revue de code au quotidien. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)** : Une skill approfondie pour les travaux à forte composante contextuelle et architecturalement complexes, tels que la conception de frontières de confiance, les systèmes d'authentification, les flux de données multi-services ou l'architecture des dépendances. Elle oriente vers la section spécifique du framework empaqueté (dans `skills/securable-code/framework/`) pertinente pour le code concerné, en échangeant du contexte supplémentaire contre le raisonnement complet du framework source. Utilisez `securability` par défaut ; recourez à `securable-code` lorsque les décisions de conception sont suffisamment non évidentes pour justifier la lecture du framework lui-même. ## Résumé Ce dépôt définit le logiciel sécurisable comme un logiciel conçu pour rester défendable : structuré de manière à pouvoir être compris, modifié, testé et durci à mesure que le monde qui l'entoure change. Il souligne que la sécurité est un processus continu, et non un acquis statique. Il introduit le Securable Software Engineering Model (SSEM), qui présente la sécurité comme un ensemble inhérent de qualités d'un logiciel bien conçu. Pour ce faire, il présente les catégories d'attributs que sont la Maintenabilité, la Fiabilité de confiance (Trustworthiness) et la Fiabilité (Reliability, qui inclut la Résilience). FIASSE préconise d'intégrer les pratiques de sécurité dans le flux de développement là où elles ont le plus d'impact. Cela fait passer d'une approche « sécurité en réflexion après coup » ou « shift left » à un modèle proactif et collaboratif. Les propriétaires de produit, les développeurs et les professionnels de la sécurité travaillent ensemble dès les premières étapes de la conception, notamment par la définition des exigences de sécurité, la modélisation collaborative des menaces et les critères d'acceptation de sécurité. Cela établit des attentes claires pour les activités de code et les tests. Les revues de fusion agissent comme des garde-fous, et non comme des portes. Chaque fusion produit un Rapport de Sécurisabilité à titre indicatif, et le blocage est une décision de politique assortie d'un chemin de dérogation. Les constats issus de la validation et de la production sont traités comme du renseignement empirique qui remonte vers l'étape en amont qui aurait pu les prévenir. Les ingénieurs logiciels reçoivent des conseils sur l'équilibre entre flexibilité et contrôle. Ils reçoivent également un modèle définitif pour prendre des décisions de sécurité. En fin de compte, cela permet à toutes les parties prenantes de contribuer à la construction de systèmes plus robustes, plus fiables et intrinsèquement sécurisables. FIASSE se distingue des approches existantes en n'exigeant pas des développeurs qu'ils deviennent des experts en sécurité ou qu'ils adoptent un état d'esprit adversarial. Il nomme les anti-patterns courants de l'AppSec, tels que le « Shoveling Left » (déverser la sortie brute des outils sur les développeurs) et la formation axée sur l'exploitation, et les remplace par le Principe du Renseignement de Sécurité Actionnable. Cette approche vise à réduire la charge cognitive des développeurs tout en garantissant que les praticiens de la sécurité peuvent avoir la certitude que leurs préoccupations sont prises en compte grâce à des attributs spécifiques du code et des processus d'ingénierie logicielle. FIASSE se veut ouvert, accessible et collaboratif. ## Feuille de route Jalons initiaux du projet FIASSE : - **Fondation du projet** - Mise en place de la gouvernance du projet, des directives de contribution et des canaux de communication. - **Spécifications de base** - Publication formelle du framework FIASSE et de la spécification SSEM, détaillant les attributs de base et les stratégies d'intégration. - **Adoption et ressources pédagogiques** - Un Manuel SSEM pour présenter le modèle et son application. - Une collection de cas d'usage initiaux et de modèles d'adoption pour illustrer les bénéfices pratiques. - Développement continu de guides de mise en œuvre, d'exemples et d'autres supports pédagogiques. D'autres jalons seront développés avec l'équipe du projet. Les contributions de la communauté sont les bienvenues via [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions). ## Ressources complémentaires Ce dépôt complète le [site web FIASSE](https://fiasse.org). Le projet [OWASP FIASSE](https://owasp.org/www-project-fiasse/) fait partie de la [OWASP Foundation](https://owasp.org/), une organisation à but non lucratif dont la mission est d'éliminer les logiciels non sécurisés. La OWASP Foundation fournit une multitude de ressources et de frameworks qui s'alignent sur les principes de FIASSE. Ce framework est axé sur l'ingénierie de logiciels sécurisables et est complété par d'autres projets OWASP : - Vérification des fonctionnalités de sécurité et bibliothèque d'exigences de sécurité prête à l'emploi : [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - Maturité de l'assurance : [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/) - Conformité de la sécurité produit : [OWASP Product Security Capability Framework (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) OWASP héberge également de nombreux projets qui documentent les exigences et fonctionnalités de sécurité, tels que [OWASP Mobile Application Security](https://mas.owasp.org/). Le [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/) est une ressource complète pour diverses autres ressources OWASP. Une autre excellente ressource pour les exigences de référence et les pratiques d'assurance est [OpenCRE](https://opencre.org/), qui rassemble et met en correspondance divers cadres de sécurité. Les catalogues de contrôles tels que NIST SP 800-53, ISO/IEC 27001 Annexe A et PCI DSS soutiennent la gestion des risques, l'assurance et l'évaluation externe. FIASSE ne les remplace pas. Il les traite comme des entrées pour la collecte des exigences, où un contrôle de catalogue est traduit en une exigence de sécurité avec des critères d'acceptation avant que le développement ne l'implémente. Le [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) du NIST définit un ensemble fondamental de pratiques de développement logiciel sécurisé organisées en quatre groupes. FIASSE ne définit pas un tel ensemble de pratiques. Il s'aligne sur le SSDF en mettant l'accent sur l'intégration de la sécurité dans le cycle de vie du développement logiciel. Le [Software Security Code of Practice](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) du NCSC définit les résultats souhaités et certaines stratégies clés. FIASSE se concentre sur les principes et stratégies de suivi de premier niveau pour atteindre des résultats sécurisables, destinés aux équipes de développement et d'assurance afin de s'aligner sur les stratégies métier. SSEM spécifie les attributs utilisés pour produire les résultats souhaités, et la méthodologie FIASSE fournit des conseils pratiques pour implémenter ces attributs dans les pratiques d'ingénierie logicielle. Les normes de codage sécurisé [CERT](https://www.cert.org/) de l'Université Carnegie Mellon sont un ensemble de règles au niveau du langage fournissant à la fois des exemples « ce qu'il ne faut pas faire » montrant des modèles de code vulnérables et des exemples « ce qu'il faut faire ». FIASSE complète ces règles en fournissant une approche fondée sur des principes qui aide les programmeurs à comprendre le « pourquoi ? » derrière un code sécurisable. Le Software Factory Security Framework ([SF2](https://sf2framework.com/)) « fournit aux responsables de la sécurité une approche stratégique pour mettre à l'échelle les capacités de sécurité tout en améliorant les résultats métier. » Il s'agit d'un cadre au niveau organisationnel qui complète l'accent mis par FIASSE sur les pratiques d'ingénierie logicielle. ## Contribution Les contributions visant à améliorer la documentation et les exemples sont les bienvenues. Veuillez consulter nos [directives de contribution](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md) pour plus de détails. ## Licence Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) - voir le fichier [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) pour plus de détails. ## Remerciements Ce projet est un effort collaboratif de la communauté OWASP. Nous remercions tous les contributeurs pour leur précieuse contribution et leur dévouement à l'amélioration de la sécurité logicielle. Il existe une [liste des contributeurs](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md) ayant participé à ce projet. Certains contributeurs précoces ont aidé à façonner les concepts initiaux et à éprouver les idées (redteam).
