La saison des conférences 2023 a officiellement débuté le 1er février à Seattle. Plus de 1000 participants, conférenciers et fournisseurs d’outils de sécurité se sont réunis à Seattle pour CloudNativeSecurityCon, le premier événement autonome en personne de ce type. Au cours de 2 jours et de plus de 70 présentations, la communauté de la sécurité native du cloud a partagé ses connaissances sur l’état de la sécurité open source. En cours de route, nous avons eu de bons moments et des conversations sur les SBOM, les SLSA, les SCA et les nombreux défis de sécurité auxquels nous sommes tous confrontés.
Avec tant de choses emballées dans les deux jours de l’événement, il serait impossible de tout couvrir, alors voici quelques faits saillants.
Un événement né de la communauté
En commençant par le premier discours, nous avons appris que CloudNativeSecurityCon est né de conversations communautaires lors de l’événement phare de la Cloud Native Foundation KubeCon + CloudNativeCon en 2019. La co-responsable de l’événement, Emily Fox d’Apple, a raconté comment un petit groupe de personnes avait eu une conversation pendant une session ouverte et a ensuite lancé une rencontre sur la sécurité, qui a finalement abouti à cet événement autonome. Cela m’a beaucoup rappelé la célèbre citation de Margaret Mead : « Ne doutez jamais qu’un petit groupe de citoyens réfléchis et engagés puisse changer le monde : en effet, c’est la seule chose qui ait jamais changé. »
Priyanka Sharma, directrice exécutive de la Cloud Native Computing Foundation, CNCF, a présenté l’ensemble de l’événement et a souligné l’importance de ce rassemblement. Elle a expliqué qu’au cours de l’année prochaine, environ 188,3 milliards de dollars devraient être dépensés pour la sécurité. Il faudra plus que des solutions descendantes pour résoudre les problèmes auxquels l’industrie est confrontée. Au lieu de cela, le changement doit être piloté par les développeurs alors que le monde entier continue de se déplacer vers la gauche. Dans le même temps, 77 % des organisations interrogées par la CNCF ont déclaré que la « mauvaise formation » et le « manque de collaboration » étaient des défis majeurs auxquels elles devaient faire face. L’avenir ne peut être assuré que si nous travaillons tous ensemble, si nous voyons tout le monde dans la même équipe et si nous nous concentrons sur une meilleure éducation. Ces principes sont au cœur de la mission de l’événement.
L’horizon de la menace
Un thème qui a été soulevé lors de plusieurs sessions et dans les conversations de couloir était les nouvelles menaces et la meilleure façon de nous préparer à ce qui émerge.
Dans son discours d’ouverture « Fighting The Next War— Future Threats to OSS and Software Supply Chain Security », Brian Behlendorf, directeur général de l’Open Source Security Foundation, a expliqué un peu comment nous en sommes arrivés là, depuis les premiers jours d’Internet lorsque le cryptage n’était pas encouragé. Aussi choquant que cela puisse paraître pour quelqu’un qui débute dans le domaine de la sécurité, au début, la cryptographie était considérée comme le domaine de l’armée et des gouvernements ; les créateurs d’applications ont été découragés d’utiliser le chiffrement. Heureusement, cela a changé, mais l’héritage est que de nombreux exploits persistent qui auraient dû être corrigés au début d’Internet, mais qui ne l’ont tout simplement pas été.
Brian a déclaré que nous avions besoin d’un nouvel ensemble d’hypothèses pour mieux nous préparer à l’avenir. Ceux-ci inclus:
- Il n’existe pas de véritable architecture zéro confiance. Il y a toujours un biais intégré.
- Les attaques considérées comme difficiles deviendront plus faciles avec le temps.
- S’il y a un problème où vous pensez que « personne ne ferait ça », quelqu’un finira par le faire, puis l’automatisera pour que quiconque puisse l’exploiter.
- Les choses s’effondrent avec suffisamment de temps, en particulier les logiciels. Tous les bogues sont finalement détectables et exploitables.
Brian a terminé son discours d’ouverture avec un rapide tour d’horizon des nouvelles surfaces d’attaque. Il pense que nous verrons un nouveau niveau de sophistication dans les attaques de spear phishing automatisées, ce qui rendra encore plus vital la recherche de nouvelles façons d’activer l’authentification multifacteur. La MFA elle-même nécessite également une vigilance constante, car de plus en plus de schémas d’autorisation MFA sont victimes de processus de réinitialisation corrompus. Il prédit également que nous verrons des modèles d’IA corrompus qui sont formés pour introduire des défauts intentionnellement, ce qui signifie que plus nous comptons sur des choses comme ChatGPT pour écrire du code, plus nous verrons de vulnérabilités de sécurité au fil du temps. Il prédit en outre que nous verrons l’intelligence artificielle être abusée pour faire des choses comme bloquer les demandes d’extraction du jour zéro, ce qui rendra plus difficile la recherche et l’application des correctifs appropriés.
Heureusement, des groupes de bénévoles dévoués travaillent sur des solutions à ces problèmes. Brian aimerait que vous les rejoigniez et que vous donniez un coup de main là où vous le pouvez. Vous pouvez en savoir plus en visitant le site Web OpenSSF.
Zack Butcher, l’ingénieur fondateur de Tetrate, a poursuivi la conversation sur les menaces émergentes avec cette conférence, « De Google au NIST – L’avenir de la sécurité native du cloud ». Il nous a demandé de considérer l’une des plus grandes préoccupations lorsque l’on réfléchit à la confiance zéro : « et si l’attaquant vient de l’intérieur du réseau ? » Bien qu’il n’y ait pas de réponse unique, Zack a présenté cinq grands éléments de la liste de contrôle utilisés chez Google pour répondre à cette préoccupation :
- Chiffrement en transit
- Authentification des services
- Autorisation de service à service
- Authentification de l’utilisateur final
- Autorisation de l’utilisateur final à la ressource
Si vous sentez que vous avez une bonne réponse pour chacun de ces points à chaque saut, alors vous êtes en bonne position. Cependant, il a souligné que cela doit être abordé à chaque étape de vos pipelines, pas seulement à la porte d’entrée.
Le panel d’opinions et de bonnes prises
La session que j’ai entendue le plus référencée ou citée dans les couloirs était la table ronde « Cloud Native Security Landscape : Myths, Dragons, and Real Talk », animée par Edd Wilder de Sysdig, avec le directeur technique de Sysdig et le fondateur Loris Degioanni, Kim Lewandowski, le fondateur de Chainguard, Isaac Hepworth, chef de produit du groupe Google et Randall Degges, responsable des relations avec les développeurs et de la communauté chez Snyk. Les réponses imprimées ici ne sont que des résumés. Je vous encourage vivement à regarder l’enregistrement.
La première question, « Quelle est la chose la plus importante en matière de sécurité à laquelle les gens devraient prêter attention ? »
Isaac : Il y a un sentiment universel que les dépendances open source introduisent un certain niveau de risque dans la chaîne d’approvisionnement des logiciels, mais personne n’a une bonne compréhension de cela ou de ce qu’il faut faire à ce sujet.
Randall : Le fait est que les développeurs ne se soucient pas vraiment de la sécurité, surtout si cela devient « trop ». Nous devons travailler pour automatiser tout ce qui soulage les développeurs.
Loris : Il est tout aussi important de comprendre le cycle de vie complet du logiciel que de comprendre les dépendances, ce sur quoi de nombreuses personnes se concentrent actuellement. L’accent mis sur l’exactitude et la précision est l’une des principales raisons pour lesquelles les gens sont dépassés. Nous devons rendre cela plus facile à consommer et le rendre moins stressant.
Kim : La sécurité de la chaîne d’approvisionnement est le problème le plus urgent, et nous devons adopter un parcours en trois étapes pour y remédier : « Connaître, réparer, forcer ». Sachez ce qui s’exécute, où il s’exécute et ce qu’il contient. Réparez toutes les choses qui le rendent peu sûr. La force, au contraire, applique la conformité dans toute l’organisation. Si certaines parties de votre infrastructure ou de votre organisation ne sont pas sécurisées, alors tout est non sécurisé.
Ensuite, le sujet s’est tourné vers les rôles de développeur par rapport aux rôles de l’équipe de sécurité.
Kim : Idéalement, nous faisons tous partie de la même équipe, mais la réalité dans de nombreuses entreprises est l’« équipe de sécurité » par opposition à l’« équipe de développement ». Les développeurs veulent éviter les obstacles pendant qu’ils font leur travail.
Randall : Les trois clés pour qu’un développeur répare des trucs sont « l’éducation, la gamification de l’expérience et l’outillage transparent ». YouTube et les blogs sont bons pour l’éducation, mais que fait l’équipe de sécurité pour mieux organiser ce qui est disponible pour l’équipe de développement ? Si nous pouvons rendre l’expérience de la résolution des problèmes de sécurité amusante en utilisant des concours et des prix, alors nous le devrions. Et enfin, si un outil ne peut pas être intégré de manière transparente, il ne sera probablement pas utilisé. Nous devrions donner la priorité à l’extension des outils que les développeurs ont déjà adoptés, en les rendant super puissants.
Loris : Au lieu de nous concentrer sur les outils, nous devons nous concentrer sur la construction d’un langage commun pour nous mettre d’accord sur la résolution des problèmes de sécurité. Un langage commun conduira à la visibilité et permettra une communication qui n’est pas possible actuellement. L’accord conduit à des personnes autonomes.
Isaac : Les SBOM sont obligatoires, et cela a poussé beaucoup d’équipes à se démener. Le 15 juin, date de mise en conformité associée au décret, nous aurons plus de 250 000 SBOM au dossier, mais que faisons-nous de ceux-ci ?
Au lieu d’être simplement submergé par les métadonnées de sécurité des SBOM, nous pouvons voir cela comme le début du « bus pour la résolution des dépendances ». C’est un moment unique pour nous de construire éventuellement une nouvelle couche de transport de métadonnées de la chaîne d’approvisionnement, bien que les outils nécessaires à cette transformation n’aient pas encore émergé. Bien qu’il ne s’agisse pas d’une solution miracle, les SBOM peuvent servir de base pour trouver une meilleure voie à suivre pour la sécurité.
Le ‘S’ dans ‘SBOM’ ne signifie pas Silver bullet.
Randall a clôturé la table ronde avec un appel à l’action pour tous ceux qui peuvent soumettre une pull request : nous devrions nous concentrer sur la résolution des CVE connus plutôt que sur des problèmes moins répandus mais surmédiatisés comme le typosquatting. Si nous nous engageions tous à corriger chacun un petit bogue de sécurité, nous aurions un écosystème globalement plus sécurisé.
Les SBOM sont dans toutes les têtes
Nous avons déjà abordé le sujet de la nomenclature logicielle dans la section précédente ; Les SBOM ont été un sujet majeur tout au long de l’événement.
Dans son discours « Panic in San Francisco : The Critical Vulnerability That Wasn’t », Shane Lawrence de Shopify a expliqué comment les SBOM ont été utilisés dans une situation réelle pour sauver Internet. En août 2021, une nouvelle version d’OpenSSL introduisait un bug qui, en cas de débordement de buffer, pouvait provoquer un déni de service ou, pire, permettre l’exécution de code à distance. Cela est devenu public à l’Halloween 2021. Lorsque le correctif a été annoncé, le défi suivant était de comprendre où cette version d’OpenSSL était installée, et c’est là que les SBOM ont sauvé la mise.
Shane nous a rappelé à tous que les SBOM ne sont pas nouveaux ; ils existent depuis des années, initialement utilisés pour le suivi des licences. L’équipe OpenSSL a pu tirer parti des SBOM disponibles pour suivre l’emplacement du bogue dans les piles réseau et corriger rapidement et efficacement les problèmes.
Quand…