Vos développeurs sont-ils votre premier risque ou votre première ligne de défense ? Évaluez votre entreprise grâce à notre liste de contrôle du codage sécurisé.

Si l'on observe n'importe quelle organisation, publique ou commerciale, deux certitudes s'imposent. Premièrement, leurs produits et services sont de plus en plus numériques, ce qui implique que des développeurs écrivent des lignes de code. Deuxièmement, ces entreprises numériques subissent la pression de concurrents traditionnels et nouveaux, au sein d'un monde globalisé et en constante mutation.

Dans ce contexte, les DSI sont devenus les nouveaux innovateurs, occupant des positions de pouvoir et d'influence. Cependant, la forte pression pour accélérer la mise sur le marché, améliorer la qualité et accroître la flexibilité a conduit à la création d'équipes de développement complexes et distribuées, axées sur le développement rapide de fonctionnalités sans tenir compte des vulnérabilités qu'elles pourraient engendrer.

Plus que jamais, une nouvelle façon de travailler est nécessaire. Il suffit de constater les dégâts considérables subis par Equifax suite à leur récente faille, causée par un codage non sécurisé. Les DSI et les RSSI doivent se demander si leurs équipes de développement constituent leur première ligne de risque ou si elles sont les véritables champions de la sécurité, leur « première ligne de défense ».

J'ai créé cette liste de contrôle pour le codage sécurisé afin d'aider les DSI et les RSSI à déterminer si leurs équipes de développement sont prêtes à devenir des champions du codage sécurisé, capables d'innover avec un code plus rapide, meilleur et plus sûr.

1. Votre direction générale reconnaît-elle que la sécurité réseau traditionnelle ne suffit plus ?

Sécuriser la couche réseau par des mesures traditionnelles n'est plus suffisant et a rarement été efficace, même face à des pirates semi-professionnels. Parmi de nombreux rapports concordants, le Data Breach Investigations Report 2017 de Verizon indique que 35 % des violations de données actuelles sont causées par des vulnérabilités des applications web. La sécurité des applications web est tout aussi cruciale que la sécurité réseau.

2. Intégrez-vous la sécurité dès le départ ?

Les outils actuels de sécurité des applications se concentrent sur une approche réactive au sein du cycle de vie du développement logiciel (SDLC). Cette méthode privilégie la détection et la réaction : les équipes de sécurité identifient les vulnérabilités dans le code écrit et interviennent pour les corriger. Selon le National Institute of Standards and Technology (NIST), il est 30 fois plus coûteux de détecter et de corriger des vulnérabilités dans un code déjà validé que de les prévenir lors de l'écriture dans l'IDE. Sans parler des retards engendrés par la résolution des problèmes. Les champions du code sécurisé interviennent dès le début du SDLC, en formant continuellement leurs développeurs au codage sécurisé, afin qu'ils deviennent la première ligne de défense de l'organisation et préviennent les vulnérabilités à la source.

3. Développez-vous réellement des compétences en sécurité au lieu de simplement transmettre des connaissances ?

La plupart des solutions de formation (en ligne ou en présentiel) se concentrent sur l'acquisition de connaissances plutôt que sur le développement de compétences. Pour écrire un code sécurisé, les développeurs ont besoin d'un accès régulier à un apprentissage pratique qui les engage activement à construire leurs compétences. Ils doivent étudier les vulnérabilités récentes, sur du code réel, et dans leurs propres langages ou frameworks. Cette expérience d'apprentissage doit leur permettre de comprendre comment localiser, identifier et corriger les vulnérabilités connues dans le code.

4. Mesurez-vous vos compétences en codage sécurisé avec des indicateurs en temps réel ?

Il est essentiel de fournir des preuves démontrant au développeur et à son organisation que ses compétences en codage sécurisé progressent. On ne peut améliorer ce que l'on ne mesure pas. Vos évaluations doivent permettre d'identifier en temps réel la progression de vos équipes de développement, tout en comparant leurs forces et leurs faiblesses en matière de codage sécurisé.

5. Vos prestataires externes appliquent-ils des techniques de codage sécurisé ?

De nombreuses organisations choisissent de sous-traiter le développement à des sociétés spécialisées, locales ou offshore. Dans le meilleur des cas, la seule garantie exigée est une clause contractuelle stipulant que le livrable doit être « sécurisé ». Peu vérifient réellement les compétences de ces prestataires en amont, aboutissant à des logiciels qui ne respectent pas les bonnes pratiques de codage. Dans le pire des cas, ils ignorent ces failles et déploient l'application telle quelle. Le scénario le plus courant est que les vulnérabilités sont découvertes par des spécialistes dédiés (que vous payez), entraînant des retards de mise en production et des litiges contractuels sur la prise en charge des correctifs. Soyez proactifs et évaluez les compétences en sécurité des développeurs qui créeront votre prochaine application.

6. Vos développeurs connaissent-ils les failles de sécurité les plus courantes ?

85,5 % des vulnérabilités exploitées dans les applications web sont attribuées à seulement 10 failles connues : le Top 10 de l'OWASP. Votre formation en sécurité applicative doit couvrir au minimum ces vulnérabilités, ainsi que bien d'autres types. Les exercices que vos développeurs réalisent doivent être continuellement révisés et mis à jour avec de nouveaux défis, adaptés aux nouveaux frameworks de codage ou aux nouveaux types de vulnérabilités.

7. Avez-vous des champions de la sécurité en interne ?

Toute organisation comptant de nombreux développeurs devrait investir dans une personne dédiée à la promotion de la sécurité au sein de ses équipes de développement. Son rôle est d'être un point de contact pour toute question liée à la sécurité, tout en encourageant les pratiques de codage et d'architecture sécurisées.

8. Avez-vous investi dans des outils facilitant le codage sécurisé pour vos développeurs ?

Dans un environnement caractérisé par des changements fréquents ou des méthodes de développement agiles, l'automatisation d'une partie de la sécurité est indispensable pour suivre le rythme et le volume. Il existe des outils adaptés à chaque étape du cycle de vie du développement, agissant comme conseillers, points de contrôle qualité ou outils de détection. Vous devriez utiliser des extensions d'IDE qui ciblent certains types de failles de sécurité, fonctionnant comme des correcteurs orthographiques pendant que le développeur écrit son code. D'autres outils s'intègrent au processus de build pour détecter des vulnérabilités lors de la soumission du code dans un dépôt. Enfin, certains effectuent des tests automatisés simulant des techniques de piratage une fois le logiciel en production. Chacun présente ses avantages et ses défis, sans jamais garantir une sécurité totale. La règle d'or est simple : plus une faille est détectée tôt, plus sa correction est rapide, économique et moins impactante pour votre activité.

Alors que les DSI renforcent activement leurs capacités agiles, les compétences en codage sécurisé deviennent un levier d'innovation, tandis que leur absence constitue un risque majeur. Réfléchissez bien avant de négliger cette capacité essentielle.

Quel est le résultat de votre organisation par rapport à cette liste de contrôle ?

Alors que les DSI renforcent activement leurs capacités agiles, les compétences en codage sécurisé deviennent un levier d'innovation, tandis que leur absence constitue un risque majeur. Réfléchissez bien avant de négliger cette capacité essentielle.