Crédit : Dreamstime
La sécurité fait partie des éléments qui résisteront à la hache budgétaire devrait plonger le monde dans le ralentissement économique, mais il est de plus en plus clair que nous ne pouvons pas simplement investir notre méthode dans un avenir sûr.
Sans aucun doute, SLSA (Supply-chain Levels for Software Application Artifacts), Tekton, et d’autres options peuvent protéger les chaînes d’approvisionnement open source, mais la vérité est que nous comptons toujours principalement sur les développeurs pour faire mieux et « être vigilants », comme l’explique le fondateur de Modal Labs, Erik Bernhardsson. Sans surprise, cette non-stratégie cesse de fonctionner.
Cela déclenche la principale préoccupation 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 utiliser. Dans cet esprit, y a-t-il un espoir que les choses s’améliorent ?
Pas de panacée
Une raison importante pour laquelle la sécurité est difficile est qu’il est difficile de sécuriser un système sans comprendre le système dans son ensemble.
Comme le postule la star de l’open source Simon Willison, « composer un logiciel sûr nécessite une connaissance approfondie de la façon dont tout fonctionne ». Sans cette compréhension essentielle, poursuit-il, les concepteurs peuvent suivre les soi-disant « meilleures pratiques » sans comprendre pourquoi elles le sont, ce qui « est une recette pour commettre involontairement des erreurs qui introduisent de nouvelles failles de sécurité ».
Une réplique commune est que nous pouvons automatiser l’erreur humaine à cause de l’avancement. Il suffit d’imposer des valeurs par défaut sûres et les problèmes de sécurité disparaissent, n’est-ce pas ?
Non. « Je ne pense pas que les outils puissent nous sauver », affirme Willison. Pourquoi? En raison du fait que « peu importe la qualité de l’outillage par défaut, si les ingénieurs ne comprennent pas comment il les protège, ils le renverseront – sans même le vouloir ni comprendre pourquoi ce qu’ils font est mauvais ».
De plus, quelle que soit l’excellence de l’outil, s’il ne s’intègre pas parfaitement dans les processus soucieux de la sécurité, il ne suffira jamais. En fin de compte, la sécurité (similaire à beaucoup de choses) revient aux gens : vous pouvez réparer les logiciels, mais tant que vous n’avez pas réparé les personnes derrière le logiciel, vous n’avez rien réparé.
Néanmoins, les langages de programmation et autres logiciels les outils pourraient introduire des mécanismes pour capturer le code de développeur non sécurisé. Nous avons des superviseurs essentiels de HashiCorp, une bien meilleure authentification grâce à des choses comme AuthO, etc., qui ont toutes en fait amélioré la sécurité, normalement. Pourtant, de tels défauts pour les services « de masse » pourraient ne pas s’appliquer aux fractures de la sécurité d’une entreprise.
Comme l’explique un développeur : « Les problèmes de sécurité les plus importants sont également propres à chaque entreprise et à sa clientèle. » En termes simples, 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 proposée.
C’est vrai, mais ce n’est pas non plus aussi convaincant que certains recommandent. Les valeurs par défaut solides et axées sur la sécurité dans les ORM (choses de cartographie relationnelle) ont principalement éliminé les injections SQL, lorsqu’il s’agit d’une faille de sécurité courante, comme l’appelle Octavian Costache.
La sécurité, c’est les individus
Voici le problème saisonnier des fonctions : « La sécurité et l’innovation sont motivées par divers individus aux objectifs opposés », note Lars Albertsson de Scling.
« La sécurité et la gestion des risques perdront constamment par rapport aux exigences de service direct à long terme. » Ou, comme le révèle Gordon Shotwell de Socure, « La sécurité a généralement une dépense d’efficacité. Ce coût est souvent extrêmement difficile à justifier car la sécurité a des avantages plutôt théoriques à long terme alors que le coût de productivité est réel et instantané. »
Autrement dit, la valeur de la sécurité est généralement évidente avec le recul, mais rarement claire à l’avance.
Non pas qu’elle doive rester ainsi. Comme le suggère Albertsson, les communautés d’AQ et d’opérations ont corrigé la dureté grâce à des changements culturels et à des outils et processus qui considéraient la vitesse d’avancement comme une priorité non négociable. Dès que cela se produit avec la sécurité, comme cela semble être en cours avec le mouvement devsecops, nous devrions voir disparaître ce gouffre entre la sécurité et le développement de nouvelles fonctions.
Revenons aux problèmes individuels et à la pensée systémique holistique. L’un des aspects 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 créateur de Bearer, Guillaume Montard. Si les groupes de développement et les architectures sont de plus petite taille, ils seront mieux à même de comprendre leur système de manière globale et de le sécuriser de manière appropriée.
Nous continuons de croire que la sécurité est quelque chose que nous pouvons acheter, même si cela doit vraiment faire avec la façon dont nous fonctionnons en tant que groupes de développement. La sécurité est toujours un problème individuel, c’est pourquoi les techniques axées sur les processus telles que les devsecops sont véritablement prometteuses.
Toute l’actualité en temps réel, est sur L’Entrepreneur
