“Responsabiliser les développeurs de logiciels pour leurs erreurs”

Cette année encore, le SANS Institute et MITRE publient une liste des 25 erreurs de programmation les plus dangereuses. La principale nouveauté consiste en l’ajout d’un contrat standard, en vue de responsabiliser les créateurs de logiciels pour des erreurs conduisant à des problèmes de sécurité.

Cette année encore, le SANS Institute et MITRE publient une liste des 25 erreurs de programmation les plus dangereuses. La principale nouveauté consiste en l’ajout d’un contrat standard, en vue de responsabiliser les créateurs de logiciels pour des erreurs conduisant à des problèmes de sécurité.

Le fameux SANS Institute, spécialisé dans la formation en matière de sécurité IT, et MITRE, une ONG qui utilise l’information et la connaissance en ICT pour le bien-être général, ont, tout comme l’an dernier, publié [une liste des 25 erreurs de programmation les plus dangereuses]. Ces 25 erreurs de programmation sont de nouveau subdivisées en 3 grandes catégories: interaction peu sûre entre les composantes, gestion risquée des ressources et sécurisation ICT poreuse.

“Ces 25 erreurs de programmation ont été la cause de quasiment chaque cyber-attaque importante, dont les récentes tentatives d’effraction chez Google, dans des centrales électriques, des systèmes militaires et des millions d’autres agressions commises à l’encontre de petites entreprises et d’utilisateurs domestiques”, affirment les deux organisations. Pour établir cette liste, elles ont reçu le soutien de 28 organisations internationales en matière de sécurité et de logiciels (dont NSA, Apple, Microsoft, Juniper, McAfee, …).

Ce qui est étonnant, c’est que la liste s’accompagne cette année d’un [‘contrat standard’] entre acheteurs et éditeurs de logiciels. Ce contrat a été élaboré par le groupe de travail en cyber-sécurité de l’Etat de New York. Dans ce contrat, le fournisseur est entre autres tenu d’effectuer des recherches dans le code du logiciel pour y relever d’éventuelles erreurs, ainsi que de garantir régulièrement une formation en sécurité à ses développeurs, et ce pour responsabiliser le moins possible les acheteurs pour des brèches sécuritaires dans le code du logiciel qu’ils n’ont pas eux-mêmes écrit.