Franchement, nous essayons de ne pas parcourir votre base de code, nous essayons d'écrire des outils pour le faire pour nous.
Tout d'abord, la théorie. La sécurité est une exigence d'un système logiciel, donc comme d'autres exigences (fonctionnalité, utilisabilité, accessibilité, performances, etc.), elle doit être prise en compte à chaque étape du flux de travail d'ingénierie logicielle, de la collecte des exigences au déploiement et à la maintenance. En effet, cela est possible et des conseils existent pour aider les équipes de projet logiciel à le faire. Même si je travaille principalement avec des développeurs iOS, ma description préférée du «cycle de vie de développement sécurisé» provient de Microsoft Press .
Dans ce modèle, la sécurité des applications commence lorsque nous essayons d'obtenir des exigences de nos utilisateurs. Nous devons découvrir leurs préoccupations en matière de sécurité et de confidentialité, ce qui n'est pas facile car nous sommes les experts, pas les utilisateurs, et lorsqu'ils comprennent leurs exigences en matière de sécurité, il peut être difficile de les exprimer. Nous devons également découvrir à quels risques le logiciel sera exposé lors du déploiement et quel niveau de risque est acceptable.
Nous concevons notre application en répondant à ces exigences. Nous écrivons le code dans le but de répondre à ces exigences et d'éviter les risques supplémentaires associés aux erreurs de sécurité au niveau du code. Nous testons le logiciel pour nous assurer que notre modèle de sécurité est cohérent avec ce que nous avons vraiment construit, puis nous déployons le logiciel d'une manière qui correspond aux hypothèses que nous avons faites sur l'environnement lorsque nous avons conçu la chose. Enfin, nous fournissons un support et une maintenance qui aident l'utilisateur à utiliser le logiciel d'une manière cohérente avec ses exigences de sécurité, et qui lui permet (ainsi qu'à nous) de réagir à de nouveaux changements dans les risques présentés.
Ok, tant pis pour la théorie. En pratique , pour des raisons qui sont très bien expliquées (quoique de manière non technique) en géekonomie et qui sont principalement dues à la façon dont les éditeurs de logiciels sont motivés, la plupart des choses ci-dessus ne se produisent pas. Au lieu de cela, nous obtenons cela. Les développeurs:
- embaucher un gars ou une fille de sécurité pour être présent quand ils soumissionnent pour un contrat, pour montrer qu'ils "obtiennent" la sécurité.
- écrire des logiciels.
- embaucher un responsable de la sécurité ou une fille pour valider le logiciel avant sa sortie, corrigeant de nombreux problèmes survenus à l'étape 2.
- patchez tout le reste après le déploiement.
Alors que la plupart des gens de la sécurité de l' application sont vraiment en train de faire est, comme vous le dites, trouver des bogues. C'est vraiment une revue de code glorifiée, mais c'est une revue de code très ciblée effectuée par des personnes qui sont des experts dans les types de bogues que cette revue recherche, il est donc toujours utile d'obtenir de l'aide extérieure pour le faire. C'est une règle générale de teting, bien sûr: demandez toujours à quelqu'un d'autre de tester qui n'a pas participé à la fabrication de la chose.
Si nous acceptons ce qui précède comme vrai, il s'ensuit que les personnes qui prennent des décisions d'achat assimilent probablement «un gars de la sécurité capable» à «trouve beaucoup de bugs». Ceux qui obtiennent des ordinateurs pour faire le travail pour eux trouveront plus de bogues que ceux qui ne le font pas, alors bien sûr, ils s'appuient fortement sur des outils d'analyse statique et viseront à consacrer plus de temps à étendre les outils qu'à coder pour des problèmes spécifiques pour des clients spécifiques. Nous concluons ensuite que les personnes chargées de la sécurité des applications sont plus susceptibles d'écrire des outils pour lire du code que pour lire du code.
** Attention: ce qui reste, c'est l'opinion personnelle et la spéculation **
La réalité est brisée. Vous remarquerez que la théorie de la sécurité des logiciels consistait à identifier et à répondre au risque de s'appuyer sur un système logiciel, alors que la pratique consistait à trouver autant de bogues que possible. Bien sûr, cela réduira toujours le risque, mais seulement comme effet secondaire. Le but du jeu est devenu moins important que de "gagner" le jeu, donc les règles sont modifiées pour faciliter la victoire.
Que pouvez-vous faire en tant que développeur de logiciels à ce sujet? Jouez le jeu selon ses règles d'origine. Trouvez quelqu'un dans votre équipe (de préférence en fait dans votre équipe, plutôt qu'un entrepreneur, afin qu'ils soient motivés à fournir des résultats à long terme plutôt qu'une victoire rapide) qui comprend l'importance de la sécurité et en forme le bejeezus. Donnez à cette personne la responsabilité de diriger l'équipe en assurant la sécurité de bout en bout décrite au début de ma réponse.
Donnez également à cette personne le pouvoir de poursuivre . Si une conception n'exprime pas les exigences de sécurité, elle doit être révisée. Si l'implémentation ne répond pas aux exigences de sécurité, elle ne doit pas être publiée . Votre responsable de la sécurité peut rendre le jugement, mais doit être autorisé à donner suite à ce jugement. Je me rends compte que cela pourrait ressembler au gars de la sécurité qui dit "la sécurité OMFG est la chose la plus importante", mais ce n'est pas ce que je veux dire. Si votre produit ne répond pas non plus aux exigences de fonctionnalité, de convivialité ou de performances, vous ne devriez pas non plus publier cette chose.
Pourquoi voudriez-vous faire ça? Cela devrait être moins cher: nous avons tous vu (et probablement cité pour un représentant +10 pas cher) le tableau Code Complete où les défauts deviennent plus chers plus tard vous les corrigez, non? Les défauts de sécurité sont également des défauts. I les règles du jeu du monde réel, la plupart d'entre eux sont des problèmes dans les exigences qui sont fixées dans la maintenance. C'est bon marché?
Ok, maintenant, que puis- je faire en tant que pistolet de sécurité à louer? Il se trouve que je peux aussi refuser de jouer selon les règles modifiées. Je peux dire aux développeurs qu'il s'agit de réduire les risques, que cela peut être fait à chaque étape, puis je peux les aider à le faire.