Les chaînes d’approvisionnement en logiciels sont des cibles faciles pour les agresseurs qui souhaitent tirer parti de l’absence d’ouverture, de visibilité et de sécurité des bibliothèques open source qu’ils utilisent pour intégrer du code nuisible pour une grande distribution. De plus, lorsque les entreprises ne savent pas d’où proviennent les bibliothèques de code ou les plans utilisés dans leur application logicielle, cela génère des risques de sécurité et de conformité plus importants.
Le rapport actuel sur la sécurité et l’analyse des risques Open Source de Synopsys a révélé que 97 % du code industriel est composé de code open source et 81 % comprend au moins une vulnérabilité. En outre, 53 % des bases de code examinées présentaient des conflits de licence et 85 % étaient périmées depuis au moins quatre ans.
Il est courant que les groupes d’avancement utilisent des bibliothèques et des packages trouvés sur GitHub et d’autres référentiels de code. Les coûts logiciels des produits (SBOM) sont nécessaires pour suivre chaque logiciel open source (OSS) et chaque bibliothèque utilisés pendant le processus devops, c’est-à-dire lorsqu’ils entrent dans le cycle de vie du développement logiciel (SDLC).
Protéger les chaînes d’approvisionnement en logiciels
Les leaders de l’avancement des logiciels doivent agir et incorporer des SBOM dans leur SDLC et leurs flux de travail pour empêcher la menace de Log4j et de composants OSS infectés comparables d’endommager leur code et d’infecter leurs clients ‘ systèmes. L’analyse de la composition logicielle (SCA) et les SBOM qu’ils produisent fournissent aux équipes devops les outils dont elles ont besoin pour suivre où les composants open source sont utilisés. L’un des objectifs essentiels de l’adoption des SBOM est de créer et de conserver des inventaires indiquant où et comment chaque composant open source est utilisé.
Occasion
Sécurité intelligente Haut
Découvrez le rôle important de l’IA et du ML dans la cybersécurité et des études de cas spécifiques à l’industrie le 8 décembre. Inscrivez-vous pour votre pass gratuit dès aujourd’hui.
Inscrivez-vous maintenant
« L’absence de transparence sur ce que les éditeurs de logiciels achètent, acquièrent et publient est le plus grand défi pour améliorer la sécurité de la chaîne d’approvisionnement », a déclaré Janet Worthington, analyste senior chez Forrester, lors d’un entretien avec VentureBeat.
Le décret 14028 de la Maison Blanche sur l’amélioration de la cybersécurité du pays exige que les fournisseurs d’applications logicielles fournissent un SBOM. L’EO 14028 se concentre sur la résolution du manque de visibilité de la chaîne d’approvisionnement des applications logicielles en exigeant que la NTIA, le NIST et d’autres entreprises gouvernementales offrent une plus grande ouverture et présence dans le processus d’acquisition et d’approvisionnement des applications logicielles tout au long de leur cycle de vie.
En outre, le décret exécutif exige que les organisations fournissant des logiciels fournissent des informations non seulement sur les fournisseurs directs, mais également sur les fournisseurs de leurs fournisseurs, les fournisseurs de niveau 2, de niveau 3 et de niveau n. Le centre de ressources sur les coûts des logiciels de la société de cybersécurité et de sécurité des infrastructures (CISA) offre également des ressources importantes pour les RSSI qui se familiarisent avec les SBOM.
L’EO 14028 a été suivi le 14 septembre de cette année d’un mémorandum rédigé par le directeur du Bureau de la gestion et du plan budgétaire (OMB) à l’intention des chefs des départements et des entreprises de l’exécutif répondant à l’exigence d’amélioration la sécurité de la chaîne d’approvisionnement des applications logicielles fédérales plus loin que ne l’exigeait le décret.
« La combinaison du décret et de la note de service indique que les SBOM vont être essentiels à court terme », a déclaré Matt Rose, CISO de ReversingLabs. Ce qui est le plus remarquable à propos du mémorandum, c’est qu’il exige que les entreprises obtiennent une auto-attestation des fournisseurs de services d’applications logicielles que leurs équipes de développement suivent les procédures d’avancement protégées spécifiées dans la structure de développement d’applications logicielles sécurisées du NIST (SP 800-218) et la chaîne d’approvisionnement des logiciels du NIST. Conseils de sécurité.
Les SBOM aident à développer un code de confiance à grande échelle
L’intégration de SBOM dans les procédures devops, au-delà de la conformité à l’EO 14028, garantit que chaque partenaire en aval, client, organisation d’assistance et gouvernement fédéral l’entité gouvernementale reçoit des applications crédibles construites sur un code solide et sûr. Les SBOM font plus que sécuriser le code. Ils sécurisent également les noms de marque et la réputation des entreprises fournissant des logiciels à l’échelle internationale, en particulier des applications et des plates-formes Web.
Il y a une absence croissante de recours à un code qui n’est pas enregistré, en particulier de la part des entreprises d’approvisionnement et d’achat du gouvernement fédéral. L’obstacle pour de nombreux éditeurs de logiciels est d’atteindre une technique de décalage vers la gauche plus efficace lors de l’intégration des SBOM et des SCA dans leur procédure d’intégration continue/d’expédition continue (CI/CD). La sécurité Shift-left cherche à fermer les espaces que les agresseurs recherchent pour injecter du code nuisible dans les charges utiles.
« Les RSSI et les DSI comprennent de plus en plus que pour agir rapidement et atteindre les objectifs de service, les équipes doivent adopter une culture devops protégée. Le développement d’un pipeline d’avancement automatique permet aux groupes de publier fréquemment et en toute confiance, car les tests de sécurité sont intégrés dès les premières étapes. À la suite d’un problème de sécurité échappant à la production, le fait d’avoir un pipeline reproductible permet d’annuler le code irritant sans affecter les autres opérations », a recommandé Worthington.
Les RSSI doivent également finir par se familiariser avec le code officiel définitions des SBOM maintenant, en particulier s’ils appartiennent à une chaîne d’approvisionnement logicielle qui offre des applications au gouvernement fédéral. Les normes formelles incluent Software application Bundle Data Exchange (SPDX), Software Application ID Tag (SWID) et CycloneDX. Parmi ceux-ci, CycloneDX est le exigence la plus souvent utilisée. Ces normes visent à développer un format d’échange d’informations et des installations communes qui partagent des informations sur chaque package d’application logicielle. Par conséquent, les organisations qui adoptent ces exigences découvrent qu’elles économisent du temps pour corriger et résoudre les déconnexions tout en augmentant la collaboration et la vitesse d’accomplir des tâches conjointes.
Pour les SBOM, la conformité n’est que le début
EO 140 28 et le mémorandum de suivi ne sont que le début des exigences de conformité auxquelles les groupes devops et leurs organisations doivent se conformer pour faire partie de la chaîne d’approvisionnement en logiciels du gouvernement fédéral. Les exigences SBOM de la Federal Energy Regulatory Commission (FERC), de la Fda (FDA) et de l’Agence de l’Union européenne pour la cybersécurité (ENISA) exigent également désormais la présence et la traçabilité de SBOM comme condition préalable à l’exploitation. Les SBOM finissant par être au cœur de la façon dont les gouvernements fédéraux américains et européens définissent avec qui et comment ils travailleront, les RSSI doivent faire de ce domaine une priorité en 2023.
Objectif de VentureBeat est d’être une place publique numérique permettant aux décideurs techniques d’acquérir des connaissances sur les technologies commerciales transformatrices et d’effectuer des transactions. Découvrez nos Briefings.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
