🔒 Les méthodologies de Secured Software Development sont nombreuses, populaires et font même l’objet de normes gouvernementales depuis une demi-décennie. Trois raisons de s’en méfier, donc.
📐 Chercheurs, gouvernements et praticiens s’accordent sur un socle commun de pratiques : évaluation des risques, création d’une culture de la sécurité et standards de code. En dehors de ce noyau commun, les pratiques recommandées divergent.
🤡 Les auteurs de cette revue de littérature relèvent l’absence quasi-totale de justification des pratiques recommandées par ces méthodologies. La charge de la preuve leur incombe, pourtant. Ils notent également l’absence d’évaluation de l’efficacité de telles méthodologies, pointant ironiquement que les entreprises desquelles elles sont issues ont été remarquées pour des hacks massifs depuis la parution de leurs méthodes.
⛓️ Ajoutons que très peu de méthodes envisagent le développeur comme un acteur de la sécurité. Au mieux leur impose-t-on des standards de code et des revues de leur travail par des experts. La plupart des frameworks se contentent de faire de la gestion de risque, à mille lieux de méthodologies de développement, sécurisé ou non.
SOURCE
Kudriavtseva, Arina and Olga Gadyatskaya. “Secure Software Development Methodologies: A Multivocal Literature Review.” ArXiv DOI:abs/2211.16987 (2022)
Enzo Sandré
📄 Lien public DOIs: 10.48550/arXiv.2211.16987