La sécurité est l’une des rares choses qui survivront à la hache budgétaire si le monde plongeait dans la récession, mais il est clair que nous ne pouvons pas simplement passer notre chemin vers un avenir sûr. En effet, SLSA (Supply-chain Levels for Software Artifacts), Tekton et d’autres solutions peuvent sécuriser les chaînes d’approvisionnement open source, mais la réalité est que nous comptons encore principalement sur les développeurs pour faire mieux et «être vigilants», comme le fondateur de Modal Labs Erik Bernhardsson souligne. Sans surprise, cette non-stratégie continue d’échouer.
Cela incite La question centrale de Bernhardsson: “Pourquoi la sécurité est-elle si difficile en 2022 ?” Une réponse est que les systèmes deviennent de plus en plus complexes, laissant des trous que les pirates peuvent exploiter. Dans cet esprit, y a-t-il un espoir que les choses s’améliorent ?
Pas de panacée
L’une des principales raisons pour lesquelles la sécurité est difficile est qu’il est difficile de sécuriser un système sans comprendre le système dans son intégralité. En tant que luminaire open source Simon Willison postule“L’écriture de logiciels sécurisés nécessite une connaissance approfondie de la façon dont tout œuvres.” Sans cette compréhension fondamentale, poursuit-il, les développeurs peuvent suivre les soi-disant « meilleures pratiques » sans comprendre Pourquoi ils sont tels, ce qui “est une recette pour commettre accidentellement des erreurs qui introduisent de nouvelles failles de sécurité”.
Une réplique courante est que nous pouvons automatiser l’erreur humaine hors du développement. Appliquez simplement les valeurs par défaut sécurisées et les problèmes de sécurité disparaissent, n’est-ce pas ?
Non. “Je ne pense pas que les outils puissent nous sauver” Willison soutient. Pourquoi? Parce que “peu importe la qualité de l’outillage par défaut, si les ingénieurs ne comprennent pas comment il assure leur sécurité, ils le subvertiront, sans même le vouloir ni comprendre pourquoi ce qu’ils font est mauvais”. De plus, quelle que soit la qualité de l’outil, s’il ne s’intègre pas parfaitement aux processus axés sur la sécurité, il ne suffira jamais. En fin de compte, la sécurité (comme pour la plupart des choses) revient aux gens : vous pouvez réparer le logiciel, mais tant que vous n’avez pas réparé les personnes derrière le logiciel, vous n’avez vraiment rien réparé.
Même ainsi, les langages de programmation et autres outils logiciels pourraient introduire des mécanismes pour intercepter le code de développeur non sécurisé. Nous avons des gestionnaires clés de HashiCorp, une meilleure authentification grâce à des choses comme AuthO, etc., qui ont tous amélioré la sécurité, en général. Pourtant, de tels défauts pour les solutions « grand public » peuvent ne pas s’appliquer aux fissures dans la sécurité d’une entreprise. Comme un développeur ajoute, “Les problèmes de sécurité les plus percutants sont également propres à chaque entreprise et à sa clientèle.” En d’autres termes, aussi bonne qu’une posture de sécurité renforcée puisse être dans l’authentification d’une application, les failles de sécurité ont tendance à être beaucoup plus spécifiques à l’architecture d’une entreprise donnée.
C’est vrai, mais ce n’est pas aussi convaincant que certains le suggèrent. Après tout, les valeurs par défaut fortes et orientées vers la sécurité dans les ORM (mappage relationnel objet) ont largement éliminé les injections SQL, autrefois une faille de sécurité courante, comme Appels d’Octavian Costache dehors.
La sécurité c’est les gens
Voici le problème permanent des fonctionnalités : “La sécurité et l’innovation sont motivées par différentes personnes avec des objectifs contradictoires”. note Lars Albertsson de Scling. “La sécurité et la gestion des risques seront toujours perdantes face aux besoins commerciaux directs à long terme.” Ou, comme l’exprime Gordon Shotwell de Socure : « La sécurité a presque toujours un coût de productivité. Ce coût est souvent très difficile à justifier car la sécurité a des bénéfices à long terme quelque peu théoriques alors que le coût de productivité est réel et immédiat.
Autrement dit, la valeur de la sécurité est généralement apparente avec le recul mais rarement claire à l’avance.
Pas que ça devoir reste ainsi. Comme le suggère Albertsson, l’AQ et les opérations communautaires ont corrigé la dissonance grâce à des changements culturels et à des outils et processus qui ont fait de la vitesse de développement une priorité non négociable. Une fois que cela se produit avec la sécurité, comme cela semble être en cours avec le mouvement devsecops, nous devrions voir ce gouffre entre la sécurité et le développement de nouvelles fonctionnalités fondre.
Revenons au problème des personnes et à la pensée systémique holistique. L’un des aspects les plus difficiles de la sécurité est que “la complexité de la sécurité provient de la complexité de l’ingénierie qui elle-même provient (principalement) de la complexité de l’organisation”. selon le fondateur de Bearer Guillaume Montard. Si les équipes de développement et les architectures sont plus petites, elles seront mieux à même de comprendre leur système de manière holistique et de le sécuriser en conséquence.
Nous continuons à penser que la sécurité est quelque chose que nous pouvons acheter, mais en réalité, il s’agit de la façon dont nous fonctionnons en tant qu’équipes de développement. La sécurité est toujours un problème de personnes, c’est pourquoi les approches axées sur les processus telles que les devsecops sont très prometteuses.
Copyright © 2022 IDG Communications, Inc.