Dans son dernier rapport dédié aux failles de sécurité, IBM a identifié le coût moyen d’une faille de sécurité à 4 millions de dollars. Cisco évoque également qu’une faille de sécurité peut coûter jusqu’à 20% du chiffre d’affaires d’une entreprise.

Certaines de ces failles de sécurité exploitent des vulnérabilités dans le code informatique afin de voler de l’information, s’introduire sur le système informatique, supprimer des données…

De la conception à la maintenance, les développeur-ses peuvent avoir un rôle à jouer dans la protection des données de l’entreprise.

Même si le risque ne peut pas atteindre le niveau 0, je vous propose quelques règles à suivre qui peuvent aider à renforcer ce rôle, sans modifier drastiquement leur activité principale.

Règle n°1 – Toujours concevoir avant de développer

Plus les lignes de code sont complexes, plus elles sont difficiles à maintenir dans le temps, surtout lorsque les développeur-se-s changent.

Pour réduire cette complexité, les équipes de développement doivent pouvoir dédier du temps à la réflexion et à la conception du code.

Plus l’écriture du code est simple, plus elle sera facile à faire évoluer, à transmettre et à maintenir dans le temps.

Règle n°2 – Automatiser les tests

Il est courant que plusieurs développeur-se-s travaillent sur le même code, ce qui amène des problèmes d’intégration et de qualité.

Afin de détecter ces problèmes, on peut opter pour l’intégration continue. Ce type de pratique regroupe un ensemble de technique pour vérifier la qualité du code de manière automatique. Cela aide aussi à identifier s’il y a eu une régression sur le code, et ce, de manière transparente.

L’intégration continue fonctionne grâce à des outils tels que CircleCI, JetBrains ou Travis CI. Ces outils vont reproduire et simuler un déploiement en production, lancer des tests automatiques définis dans le programme…

Règle n°3 – Faire de la veille de vulnérabilités

Une application ou un logiciel informatique utilise régulièrement des bibliothèques externes. Ces bibliothèques peuvent contenir des vulnérabilités, qui peuvent être exploitées par des hackers.

Pour surveiller l’apparition de nouvelles vulnérabilités, le service CVE a pour mission d’identifier, de définir et de cataloguer les nouvelles failles de cybersécurité.

Compte tenu des milliers de vulnérabilités, il existe des plateformes permettant d’agréger et analyser ces failles, selon son existant, le tout en temps réel : Kenna Security Vulnerability Management, Flexera Vulnerability Manager, Tenable.io ou ZeroNorth.

Règle n°4 – Former les développeurs

Les développeur-se-s ne sont pas ou peu formé-e-s à la cybersécurité. Iels appliquent les exigences de sécurité imposées par le-a RSSI et les bonnes pratiques de développement.

Pourtant, ils utilisent de plus en plus de technologies différentes qui amènent leur lot de failles de sécurité.

Les développeur-ses peuvent être le premier rempart aux risques de sécurité. Pour cela, iels doivent être accompagné-es et formé-es aux bonnes pratiques de développement sécurisé.

Iels peuvent être accompagnés sur plusieurs sujets :

  • Apprendre à configurer, intégrer et utiliser des outils cyber sécurité (outil d’analyse de code et vulnérabilités, outil de tests d’intégration…) ;
  • Apprendre à évaluer les risques liés à l’utilisation d’un outil, définir des critères sécurité avant de choisir un outil, identifier les données sensibles à protéger ;
  • Intégrer des méthodes de développement sécurisé, comme définie par l’organisation OWASP…

Règle n°5 – Faire de la revue de code

La revue de code est un des moyens les plus efficaces pour réduire des risques de cybersécurité.

Elle consiste à procéder à l’examen du code par un-e autre développeur-se, généralement plus expérimenté-e.

Le processus de revue de code est essentiel, il permet :

  • de réaliser un contrôle qualité en continu ;
  • d’enrichir et d’améliorer la qualité des réalisations des développeur-ses

Il existe plusieurs manières de revoir un code :

  • Pair programming ;
  • Pull requests ;
  • Revue périodique…

Règle n°6 – Réaliser des audits de code

L’audit de code permet d’évaluer en profondeur le niveau de sécurité d’un logiciel ou d’une application. Il est mené par une entreprise tierce.

Un audit de code est réalisé dans plusieurs contextes :

  • Au moment du lancement d’une application ou d’un logiciel contraint par des obligations réglementaires,
  • Lorsque l’application ou le logiciel est massivement utilisé,
  • Au moment où l’entreprise devient publiquement connue, les cyber hackers attaquent particulièrement des entreprises visibles.

Il a un double objectif sécurité :

  • Identifier les vulnérabilités de sécurité ;
  • Évaluer la qualité des mesures de sécurité intégrées au code.

A l’issu d’un audit, un plan d’action technique est fourni qui permet à l’entreprise d’identifier ses points d’amélioration.

Règle n°7 – Activer les logs

Les logs désignent un fichier qui stocke l’historique d’activité d’une application, ou d’un serveur. Pour toute application ou logiciel, il est donc nécessaire d’activer les logs, pour les analyser régulièrement.

Grâce à ces logs, il est possible de détecter des cyberattaques, un dysfonctionnement, des problèmes de sécurité, etc. Ces journaux permettent aux dévs de corriger leurs codes et d’identifier des comportements anormaux.

La sécurité dans le code est au centre des enjeux cybersécurité des entreprises.

Elle doit être utilisée comme un moyen d’améliorer la qualité des développements informatiques et de renforcer la protection de l’entreprise contre des cyberattaques.

Ces règles de sécurité sont les bases pour un premier niveau de sécurité. Elles doivent être revues, renforcées, corrigées de manière régulière.

Enfin, il ne faut pas négliger la partie humaine de la sécurité dans le code : le-a développeur-se. Iels sont en première ligne pour corriger les failles de sécurité, iels doivent être accompagné-es et formé-es aux bonnes pratiques de sécurité, afin de les appliquer dans leur travail de conception, de code et de maintenance.