- risque = vulnérabilité * menace
Personnellement, j'ai formé plusieurs centaines de personnes(développeurs, architectes, ...) sur le sujet du "secure coding"; ce que demande le PCI-DSS par exemple. Et a force, je pense que le développeur n'est pas la bonne personne pour résoudre l'équation précédente....
En ce sens je rejoins en partie la vision de Dinis Cruz (Security must be invisible to developers).
Néanmoins, je suis un peu moins 'intégriste' que lui sur le sujet... Je ne dis pas que l'architecte ne doit pas être impliquer, pour moi c'est lui qui le doit....
Il est clair qu'aujourd'hui former des développeurs au secure coding est important. Néanmoins il convient que ces développeurs n'ai qu'une approche simple du problème.
Je m'explique par un exemple : injection SQL.
Toutes les formations le disent : il faut utiliser des requêtes paramétrées => OUI ! Mais pas seulement !
Depuis que je fais des revues de code (près de 3 ans...), j'ai pu apprécié l'approche "développeur" de cette dernière pratique....Et trouver des tonnes d'injections SQL dans les codes, car oui, on utilise des requêtes paramétrées mais on fait des concaténations dedans....(cf example 2 ici ).
Et la c'est le mal !
Bien sur, le développeur lors de la présentation du rapport ne vous crois pas jusqu'à la démonstration...
Alors que si on lui avait donner une simple interface d'appel aux fonctions sous-jacentes, et bien notre ami n'aurait pas eu de soucis et son code aurait été "safe". Il ne faut pas lui en vouloir a notre ami le développeur, il suit les consignes. Il faut en vouloir plutôt à l'architecte qui aurait du fournir une API/framework permettant d'effectuer ces appels.
Donc pour être clair : Il faut former les développeurs au secure coding, mais il faut surtout demander aux architectes logiciels de mettre à disposition des frameworks sécurisé et à eux de faire du "secure-coding"!
votre avis ?
PS: oui le rôle d'architecte nécessite de coder !
PS2: une idée à rechercher se trouve dans ce que fait Microsoft sur le framework .NET 4 (cf par exemple Entity Framework....). Attention quand même a faire attention pour ne pas faire des trucs "horribles"...L'abstraction parfois.....
PS3: comme d'habitude ce post n'engage que moi....
PS4: je remercie d'avance les quelques personnes qui reprennent mes idées chez leur client de faire référence à l'auteur ;)....
