En intégrant la sécurité au développement, les équipes de sécurité applicatives peuvent trouver et corriger les vulnérabilités avant qu’elles ne deviennent des problèmes coûteux, difficiles et pénalisant pour l’image de l’entreprise. Un avis d’expert signé Mackenzie Jackson, developer evangelist chez GitGuardian.
Avec l’expansion des modèles DevOps et DevSecOps, le concept de “Shift Left” associé au cycle de vie du développement logiciel (SDLC) est devenu populaire. Le fait de déplacer les actions opérationnelles et de sécurité clés plus tôt dans le cycle permet de détecter les vulnérabilités le plus tôt possible. Cela a une valeur significative, car plus une vulnérabilité est découverte tard, plus il est difficile et coûteux d’y remédier.
Pour ce faire, les entreprises doivent intégrer les contrôles de sécurité et la détection des vulnérabilités à chaque étape du cycle de développement logiciel, plutôt que de les considérer comme des points de passage. Le “shift left” consiste à axer davantage la sécurité sur les développeurs et à leur fournir des informations de sécurité pendant qu’ils codent.
Pourquoi transférer la sécurité vers le développement ?
La sécurité “shift-left” est essentielle à la livraison rapide de logiciels de qualité. Au lieu d’effectuer des audits de sécurité à la fin du SDLC, le shift-left fait de la sécurité une partie intégrante du travail de chacun : développeurs, opérations, sécurité des applications ou équipes de threat response.
Les tâches en matière de sécurité doivent être automatisées et intégrées dans le processus de développement et de déploiement. Les analyses automatisées doivent se produire à chaque changement incrémentiel, au moment exact où ils sont écrits de sorte que :
- Les vulnérabilités ne soient pas découvertes tard dans le cycle de développement.
- Les développeurs et les responsables des opérations soient rapidement avertis dès que des vulnérabilités potentielles apparaissent, ce qui leur permet de détecter et de corriger rapidement les problèmes de sécurité dans le cadre de leur travail quotidien.
- Les développeurs puissent rapidement tirer des enseignements de leurs erreurs et appliquer les meilleures pratiques en matière d’hygiène du code.
En intégrant mieux les objectifs de sécurité des applications dans le travail quotidien, les équipes peuvent atteindre des niveaux de performance plus élevés en matière de livraison de logiciels et créer des applications plus sûres. Cela contribue à responsabiliser les membres de l’équipe sur les sujets de sécurité.
Les développeurs peuvent craindre que les analyses de sécurité n’ajoutent une charge supplémentaire et ne ralentissent les déploiements. Cette crainte est compréhensible, connaissant la pression exercée sur les équipes de développement pour produire du code rapidement. Mais les développeurs sont également désireux d’améliorer la qualité et la sécurité de leur travail.
Pourtant la détection “shift-left” peut atténuer ces préoccupations en intégrant et en automatisant les analyses de sécurité dans les outils et processus existants. En outre, cela diminue le stress le jour J lorsque l’équipe de sécurité bloque la publication à cause d’une vulnérabilité dont le développeur n’avait pas connaissance.
Une approche centrée sur le développeur permet à ce dernier de répondre aux alertes au fur et à mesure qu’il code. Le temps réel est bien plus efficient que des jours plus tard lors du déploiement – ou des mois plus tard dans un rapport de test de vulnérabilités. C’est essentiel en termes d’exposition aux vulnérabilités et de coût de la remédiation. Il est important de prévenir les brèches avant qu’elles n’aient un impact sur la sécurité de l’entreprise et de traiter et corriger rapidement les vulnérabilités nouvellement découvertes.
Mettre le “Shift Left” en pratique avec la détection des secrets*
La sécurité des applications repose sur la détection de différents types de vulnérabilités dans le modèle de maturité DevSecOps de l’OWASP, y compris les secrets codés en clair. En effet, l’automatisation de la détection des secrets permet de mettre en pratique une approche “shift left”.
Comme les développeurs travaillent avec du code dans Git, il est logique d’y appliquer des contrôles de sécurité. En ce qui concerne les fuites de secrets, le “Shift Left” signifie détecter automatiquement les secrets dans le code et permettre aux différents membres du SDLC de collaborer.
La correction des secrets exposés dans les dépôts Git est une responsabilité partagée entre les développeurs, les opérations et l’équipe de sécurité applicative (si le secret est exposé dans les dépôts de code internes) ou l’équipe de threat response (si le secret est exposé publiquement). Les processus dépendent de la taille de l’organisation, de sa culture et de la manière dont elle répartit les responsabilités entre les équipes.
Ils ont tous besoin les uns des autres, mais les développeurs sont en première ligne. Ils savent souvent à quoi le secret exposé donne accès. Cependant, ils ne peuvent pas toujours révoquer le secret seuls, car cela pourrait avoir un impact sur les systèmes de production ou sur les autres développeurs utilisant les mêmes informations d’identification. En outre, il ne s’agit pas seulement de révoquer le secret, mais aussi de le redistribuer (rotation), ce qui relève de la responsabilité des opérations.
Tout en prenant des mesures correctives, il est également important que les équipes de sécurité gardent un œil sur le problème. Ils peuvent garantir que les étapes de remédiation appropriées sont suivies et guider et éduquer les développeurs sur les risques. Les développeurs ne prenant pas toujours la mesure du problème. Pour les équipes de sécurité, les alertes doivent être exploitables et comporter le moins de faux positifs possible pour éviter qu’elles ne soient tout bonnement ignorées.
La remédiation est une responsabilité partagée qui nécessite de multiples contributions et une communication multidirectionnelle. Les bons outils de collaboration permettent de s’assurer que les informations peuvent être recueillies auprès des différentes parties prenantes.
Où mettre en œuvre la détection automatique des secrets
Plus une faille de sécurité est découverte tôt, moins il est coûteux de la corriger. Les secrets codés en dur ne font pas exception. Si le secret est découvert après avoir atteint le système contrôle de version centralisé (VCS) côté serveur, il est considéré comme compromis. Il faut alors procéder à une rotation (révocation et redistribution) de l’identifiant exposé, ce qui peut être complexe et impliquer plusieurs parties prenantes.
La détection des secrets côté client au début du cycle de développement logiciel est utile pour empêcher les secrets de pénétrer dans le VCS. La détection des secrets côté serveur est indispensable car c’est là que réside la menace ultime. Depuis le serveur, le code peut se propager de manière incontrôlée dans de nombreux endroits avec les secrets codés en dur qu’il contient.
Le problème de la détection côté client est la complexité du déploiement : plus l’équipe de développement est grande, plus c’est complexe. La mise en œuvre de “hooks” côté client à un niveau organisationnel est difficile. De nombreux professionnels de la sécurité applicative affirment qu’ils ne sont pas sûrs de pouvoir le faire en raison de la difficulté de déployer et de mettre à jour le poste de travail de chaque développeur. Il s’agit également d’une solution non coercitive : les hooks côté client peuvent et doivent être faciles à contourner. Les hooks côté client sont en grande partie de la responsabilité du développeur individuel ; d’où la nécessité d’avoir une visibilité sur les étapes ultérieures. Par contre le déploiement de ces contrôles côté client soulage grandement les équipes de sécurité, les volumes de secrets exposés diminuant drastiquement.
Renforcer les capacités des développeurs et améliorer la sécurité
Le “Shift Left” permet aux équipes de tester en continu même les petites modifications incrémentielles du code et évite une énorme quantité de travail à la fin du SDLC. L’intégration des analyses et des tests de sécurité à chaque étape du processus de développement réduit ainsi la surface de vulnérabilité de l’organisation.
Le “Shift Left” implique d’automatiser la sécurité autant que possible et de donner aux développeurs une boucle de rétroaction rapide et continue en matière de sécurité. Les résultats des analyses doivent être simples et exploitables, et le processus doit être entièrement automatisé. Les alertes doivent être pertinentes et limiter les faux positifs. Même la remédiation doit être facilitée et automatisée dans la mesure du possible.
Elle contribue à instaurer une culture où la sécurité est valorisée et respecte le temps des développeurs. Les développeurs veulent créer un code sécurisé sans devenir des experts en sécurité ; les experts en sécurité veulent un code sécurisé qui exploite les connaissances des développeurs pendant la remédiation.
*Secret : dans le contexte du développement de logiciels, les secrets font généralement référence aux systèmes d’authentification numérique qui permettent d’accéder à des systèmes ou à des données. Il s’agit le plus souvent de clés API, de noms d’utilisateurs et de mots de passe, ou de certificats de sécurité.
