Tu réponds comme si on partait d'une appli développée depuis 0.
Hors je pense qu'il parle plutôt de l'évolution d'applisi connues pour avoir des problèmes de sécurité à répétition:
Le source est plutôt gros, la base de clients importante.
On te charge de sécuriser l'appli, tu fais quoi:
- Tu dis que tu vas tout auditer et le résultat sera là quand il sera prêt?
- Tu dis que tu réécris tout depuis 0 et pareil: zut à la base utilisateur de la version actuelle, faudra patiente?
- Ou tu définis une liste de priorité afin de parer au plus urgent dans les mise-à-jour?
Je crois que l'approche décrit ce qu'il y a à faire dans le 3ème cas de figure, et que l'idée et de ne pas foncer tête baissée.
Cette approche me rappelle les approches qualité en production (production de composants): le but est d'améliorer constamment la fiabilité du processus/composant:
- On commence par des tableaux avec tous les problèmes connus pouvant arriver.
- On pondère avec la gravité du problème et sa fréquence estimée.
- On traite dans l'ordre de la pondération, sauf si un problème inconnu avec plus d'impact intervient.
Si tu penses que ce n'est pas la meilleure approche pour quelque chose qui existe déjà avec ses problèmes, que proposes-tu?
On rappelle qu'il ne s'agit pas ici de partir de 0, mais d'améliorer l'existant.
[^] # Re: Pratiques d'une ère (dé)passée
Posté par Maclag . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 7.
Hors je pense qu'il parle plutôt de l'évolution d'applisi connues pour avoir des problèmes de sécurité à répétition:
Le source est plutôt gros, la base de clients importante.
On te charge de sécuriser l'appli, tu fais quoi:
- Tu dis que tu vas tout auditer et le résultat sera là quand il sera prêt?
- Tu dis que tu réécris tout depuis 0 et pareil: zut à la base utilisateur de la version actuelle, faudra patiente?
- Ou tu définis une liste de priorité afin de parer au plus urgent dans les mise-à-jour?
Je crois que l'approche décrit ce qu'il y a à faire dans le 3ème cas de figure, et que l'idée et de ne pas foncer tête baissée.
Cette approche me rappelle les approches qualité en production (production de composants): le but est d'améliorer constamment la fiabilité du processus/composant:
- On commence par des tableaux avec tous les problèmes connus pouvant arriver.
- On pondère avec la gravité du problème et sa fréquence estimée.
- On traite dans l'ordre de la pondération, sauf si un problème inconnu avec plus d'impact intervient.
Si tu penses que ce n'est pas la meilleure approche pour quelque chose qui existe déjà avec ses problèmes, que proposes-tu?
On rappelle qu'il ne s'agit pas ici de partir de 0, mais d'améliorer l'existant.