Combien de temps les développeurs passent-ils réellement à écrire du code ?

Selon de récents études, les développeurs passent plus de temps à maintenir, tester et sécuriser le code existant qu’à écrire ou à améliorer le code. Les vulnérabilités de sécurité ont la mauvaise habitude d’apparaître au cours du processus de développement logiciel, pour ne faire surface qu’après le déploiement d’une application. La partie décevante est que bon nombre de ces failles de sécurité et bogues auraient pu être résolus à un stade antérieur et qu’il existe des méthodes et des outils appropriés pour les découvrir.

Combien de temps un développeur passe-t-il à apprendre à écrire un code fonctionnel ? Et combien dépense-t-on pour se renseigner sur la sécurité du code ? Ou apprendre à ne pas coder ? »

Ne serait-il pas préférable d’éradiquer le problème du système plutôt que de l’avoir là, puis d’essayer de détecter et d’arrêter une attaque en cours le ciblant ?

Vous pouvez tester vos compétences en codage sécurisé avec ce court auto-évaluation.

Le vrai coût des bugs

Tout le monde fait des erreurs, même les développeurs. Les bugs logiciels sont inévitables et sont acceptés comme le « coût de faire des affaires » dans ce domaine.

Cela étant dit, tout bogue non corrigé dans le code est la pierre angulaire des attaquants. S’ils peuvent trouver au moins un bogue dans un système qui peut être exploité de la bonne manière (c’est-à-dire une vulnérabilité logicielle), ils peuvent exploiter cette vulnérabilité pour causer des dommages massifs, potentiellement à l’échelle de dizaines de millions de dollars – comme nous voir à travers des cas très médiatisés qui font la une des journaux chaque année.

Et même lorsqu’il s’agit de vulnérabilités moins graves, leur correction peut être très coûteuse, en particulier si une faiblesse est introduite beaucoup plus tôt dans le SDLC en raison d’un défaut de conception ou d’une exigence de sécurité manquante.

Pourquoi l’approche actuelle de la sécurité logicielle est-elle insuffisante ?

1 — Trop de dépendance à la technologie (et pas assez à l’humain)

Les outils d’automatisation et de cybersécurité sont censés réduire la charge de travail des développeurs et du personnel de sécurité des applications en analysant, détectant et atténuant les vulnérabilités logicielles, cependant :

• Bien que ces outils contribuent aux efforts de cybersécurité, des études montrent qu’ils ne peuvent découvrir que 45 % des vulnérabilités globales
• Ils peuvent également produire des « faux positifs », entraînant des inquiétudes, des retards et des retouches inutiles
• … ou pire encore, des « faux négatifs », créant un faux sentiment de sécurité extrêmement dangereux

2 — La déconnexion DevSec

La déconnexion DevSec fait référence à la tension bien connue entre les équipes de développement et les équipes de sécurité en raison de priorités différentes (et souvent contradictoires) en ce qui concerne les nouvelles fonctionnalités et les corrections de bogues.

En raison de ce frottement, 48% des développeurs finissent par pousser régulièrement du code vulnérable en production. Les vulnérabilités découvertes plus tard dans le cycle de développement ne sont souvent pas atténuées ou finissent par créer des coûts, des retards et des risques supplémentaires plus tard. Ce sont les conséquences d’une réflexion à court terme : en fin de compte, il serait préférable de résoudre le problème à la source au lieu de consacrer du temps et des ressources à rechercher des failles de code plus tard dans le cycle de vie du développement logiciel.

3 — Surveillez votre chaîne d’approvisionnement mais pas votre propre logiciel

Une autre erreur courante consiste à se concentrer uniquement sur la sécurité de la chaîne d’approvisionnement logicielle et à ne traiter que les vulnérabilités connues des produits et packages logiciels existants répertoriés dans la célèbre base de données Common Vulnerabilities and Exposures ou la National Vulnerability Database.

Traiter les vulnérabilités des composants tiers, vos dépendances ou l’environnement d’exploitation est essentiel, mais cela ne vous aidera pas avec les vulnérabilités de votre propre code.

De même, la surveillance des attaques potentielles via des systèmes de détection d’intrusion (IDS) ou des pare-feu suivis d’une réponse aux incidents est une bonne idée – et est reconnue par le Top 10 de l’OWASP comme une nécessité – mais ces activités ne traitent que des conséquences des cyberattaques plutôt que de la cause.

La solution : faire du codage sécurisé un sport d’équipe

Votre cybersécurité est aussi solide que votre maillon le plus faible. Le développement de logiciels n’est pas un travail à la chaîne et, malgré toutes les prévisions, il ne sera pas entièrement automatisé de si tôt. Les programmeurs sont des résolveurs de problèmes créatifs qui doivent prendre des centaines de décisions chaque jour lorsqu’ils écrivent du code, car le développement de logiciels est un type de savoir-faire.

En fin de compte, qu’un morceau de code soit sécurisé ou non dépend des compétences des développeurs individuels.

Les processus, les normes et les outils peuvent aider à favoriser et à renforcer les meilleures pratiques, mais si un développeur n’est pas au courant d’un type particulier de mauvaise pratique, il est susceptible de continuer à commettre la même erreur (et à introduire le même type de vulnérabilité dans le code) maintes et maintes fois.

6 conseils pour renforcer le codage sécurisé

Le nombre de vulnérabilités nouvellement découvertes augmente et les menaces posées par les cyber-acteurs malveillants deviennent de plus en plus sophistiquées. La plupart des organisations commencent à mettre en œuvre un cycle de vie de développement sécurisé après un incident, mais si vous nous demandez quand vous devriez commencer, la réponse, bien sûr, sera toujours le plus tôt sera le mieux.

En effet, lorsqu’il s’agit de vulnérabilités critiques, même des heures peuvent faire la différence entre l’absence de dommages durables et un désastre financier.

Voici nos meilleurs conseils pour y parvenir :

1 — Décalage à gauche – étendre la perspective de sécurité aux premières phases de développement

S’appuyer sur l’automatisation des outils de sécurité de style DevSecOps ne suffit pas en soi, vous devez mettre en œuvre un véritable changement de culture. SAST, DAST ou test d’intrusion se trouve à droite dans le SDLC ; décaler vers la gauche vers le début du cycle de vie du développement logiciel pour une couverture plus complète.

2 — Adopter une approche sécurisée du cycle de vie du développement

MS SDL ou OWASP SAMM, par exemple, fourniront un cadre pour vos processus et agiront comme un bon point de départ pour votre initiative de cybersécurité.

3 — Couvrir l’ensemble de votre écosystème informatique

Les vulnérabilités tierces présentent un risque énorme pour la cybersécurité de votre entreprise, mais vos propres développeurs peuvent également introduire des problèmes dans l’application. Vous devez être en mesure de détecter et de résoudre les vulnérabilités sur site, dans le cloud et dans des environnements tiers.

4 — Passer de la réaction à la prévention

Ajoutez des concepts de programmation défensive à vos directives de codage. La robustesse est ce qu’il vous faut. Une bonne sécurité est une question de paranoïa, après tout.

5 – L’état d’esprit compte plus que la technologie

Les pare-feu et les IDS ne protégeront pas à eux seuls votre logiciel contre les pirates ; ils traitent simplement des conséquences des vulnérabilités déjà existantes. Attaquez le problème à sa racine : l’état d’esprit et la responsabilité personnelle des développeurs.

6 — Investissez dans une formation au code sécurisé

Recherchez un qui couvre un large éventail de langages de programmation et fournit une couverture complète des normes de codage sécurisé, des bases de données de vulnérabilités et des types de faiblesses logicielles critiques reconnus par l’industrie. Les exercices pratiques en laboratoire dans les environnements natifs des développeurs sont un énorme avantage pour les mettre rapidement à niveau et combler cet embêtant savoir-faire.

Le parcours d’apprentissage mixte de Cydrill propose une formation en codage sécurisé proactif et efficace aux développeurs des entreprises Fortune 500 du monde entier. En combinant formation dirigée par un instructeur, apprentissage en ligne, laboratoires pratiques et gamification, Cydrill fournit une approche nouvelle et efficace pour apprendre à coder en toute sécurité.