Logiciels modernes : qu’y a-t-il vraiment dedans ?
Alors que l’industrie de la cybersécurité approche de la saison des conférences, il est incroyable de voir des membres de la communauté désireux de partager leurs expériences. On pourrait dire que le processus d’appel à conférenciers offre un aperçu détaillé et large de ce qui préoccupe collectivement l’ensemble de l’écosystème de la cybersécurité. L’un des sujets de discussion les plus intrigants observés dans le « RSAC 2023 Call for Submissions Trends Report » de cette année était dans et autour de l’open source, qui est devenu plus omniprésent et moins cloisonné qu’auparavant. Les logiciels modernes ont changé, et avec eux viennent des promesses et des périls.
Est-ce que quelqu’un écrit encore son propre logiciel ?
Sans surprise, les professionnels de la cybersécurité passent beaucoup de temps à parler des logiciels, de la manière dont ils sont assemblés, testés, déployés et corrigés. Les logiciels ont un impact significatif sur toutes les entreprises, quelle que soit leur taille ou leur secteur. JLes équipes et les pratiques ont évolué à mesure que l’échelle et la complexité ont augmenté. En conséquence, « les logiciels modernes sont plus assemblés qu’ils ne sont écrits », déclare Jennifer Czaplewski, directrice principale chez Target, où elle dirige DevSecOps et la sécurité des terminaux ; elle est également membre du comité du programme de la conférence RSA. Ce n’est pas simplement une opinion. Les estimations de la quantité de logiciels dans l’industrie comprenant du code de composants open source qui est directement ciblé dans les petites et grandes attaques vont de 70 % à près de 100 %, créant une énorme surface d’attaque changeante à protéger et un domaine d’intérêt critique pour l’approvisionnement de tous. chaîne.
L’assemblage de code crée des dépendances généralisées et des dépendances transitives en tant qu’artefacts naturels. Ces dépendances sont bien plus profondes que le code réel, et les équipes qui l’intègrent doivent également mieux comprendre les processus utilisés pour l’exécuter, le tester et le maintenir.
Aujourd’hui, presque toutes les organisations dépendent inévitablement du code open source, ce qui a entraîné la demande de meilleures façons d’évaluer les risques, de cataloguer l’utilisation, de suivre l’impact et de prendre des décisions éclairées avant, pendant et après l’intégration de composants open source dans les piles logicielles.
Bâtir la confiance et les composantes du succès
L’open source n’est pas seulement une question de technologie. Ou un problème de processus. Ou un problème de personnes. Cela s’étend vraiment à tout, et les développeurs, les responsables de la sécurité de l’information (CISO) et les décideurs jouent tous un rôle. La transparence, la collaboration et la communication entre tous ces groupes sont essentielles pour établir une confiance critique.
Un point focal pour l’établissement de la confiance est la nomenclature logicielle (SBOM), qui a gagné en popularité après Décret exécutif du président Biden de mai 2021. Nous commençons à voir des observations tangibles des avantages quantifiables de sa mise en œuvre, notamment le contrôle et la visibilité des actifs, des temps de réponse plus rapides aux vulnérabilités et une meilleure gestion globale du cycle de vie des logiciels. La traction de SBOM semble avoir engendré des nomenclatures supplémentaires, parmi lesquelles DBOM (données), HBOM (matériel), PBOM (pipeline) et CBOM (cybersécurité). Le temps nous dira si les avantages l’emportent sur le devoir de diligence imposé aux développeurs, mais beaucoup espèrent que le mouvement BOM pourrait conduire à une manière uniforme de penser et d’aborder un problème.
Politiques et collaborations supplémentaires, y compris la loi sur la sécurisation des logiciels libres, Structure des niveaux de la chaîne d’approvisionnement pour les artefacts logiciels (SLSA)et Cadre de développement logiciel sécurisé (SSDF) du NISTsemblent encourager les pratiques qui ont rendu l’open source si omniprésent, la communauté collective travaillant ensemble dans le but d’assurer une chaîne d’approvisionnement logicielle sécurisée par défaut.
L’accent manifeste sur les « contre » autour du code open source et de sa manipulation, de ses attaques et de son ciblage a donné naissance à de nouveaux efforts pour atténuer les risques associés, à la fois avec les processus de développement et les rapports, ainsi qu’avec la technologie. Des investissements sont en cours pour éviter d’ingérer des composants malveillants en premier lieu. Cette introspection et ces apprentissages réels autour du développement logiciel, du cycle de vie du développement logiciel (SDLC) et de la chaîne d’approvisionnement dans son ensemble sont incroyablement bénéfiques pour la communauté à ce stade.
En fait, l’open source peut grandement profiter à l’open source ! Les développeurs s’appuient sur des outils open source pour intégrer des contrôles de sécurité critiques dans le cadre de la intégration continue/livraison continue (CI/CD). Des efforts continus pour fournir des ressources, telles que le tableau de bord OpenSSF, avec sa promesse de notation automatisée, et le cadre Open Source Software (OSS) Secure Supply Chain (SSC), un cadre axé sur la consommation conçu pour protéger les développeurs contre l’offre OSS réelle menaces en chaîne, ne sont que deux exemples d’activités prometteuses qui soutiendront les équipes lors de l’assemblage de logiciels.
Plus forts ensemble
L’open source a et continuera de changer le jeu logiciel. Cela a affecté la façon dont le monde construit des logiciels. Cela a contribué à accélérer la mise sur le marché. Elle a stimulé l’innovation et réduit les coûts de développement. On peut dire que cela a eu un impact positif sur la sécurité, mais il reste du travail à faire. Et pour construire un monde plus sûr, il faut qu’un village se rassemble pour partager des idées et des meilleures pratiques avec l’ensemble de la communauté.