Comment utiliser la nomenclature des logiciels dans le cadre de votre programme de gestion des risques liés aux tiers ?

Initiatives avec exigences du SBOM

Bien que les SBOM existent depuis un certain temps, leur adoption s'est accrue à mesure que les menaces et les réglementations en matière de cybersécurité ont nécessité des approches plus proactives de la gestion des risques liés aux tiers. L'avenir des SBOM dans la gestion des risques liés aux tiers semble prometteur, car de plus en plus d'organisations reconnaissent l'importance de la gestion des risques liés à la chaîne d'approvisionnement en logiciels. En fait, des initiatives sont déjà en cours pour exiger des SBOM pour certains types de logiciels. En voici deux exemples :

• National Telecommunications and Information Administration (NTIA) : Aux États-Unis, la National Telecommunications and Information Administration (NTIA) a pris la tête des efforts visant à développer un format SBOM normalisé, qui a gagné en popularité parmi les leaders de l'industrie et les régulateurs. En outre, la Cybersecurity and Infrastructure Security Agency (CISA) a récemment publié des orientations qui recommandent aux organisations d'intégrer les SBOM dans leurs pratiques de gestion des risques de la chaîne d'approvisionnement en logiciels, en se référant aux recommandations de la NTIA.
• Décret sur l'amélioration de la cybersécurité nationale : Le président américain Biden a pris un décret et publié une mise à jour de la stratégie de cybersécurité qui exigerait la mise en place de SBOM pour tous les logiciels vendus au gouvernement.

Formats et normes du SBOM

L'un des problèmes liés à l'adoption des SBOM est le manque de normalisation. Il existe actuellement quelques normes industrielles différentes pour les SBOM.

• CycloneDX SBOM : L'un des standards les plus utilisés et acceptés est le format CycloneDX SBOM, qui est un standard ouvert développé par le projet CycloneDX. Le format CycloneDX est conçu pour être facile à utiliser et à mettre en œuvre, et il inclut la prise en charge d'un large éventail de composants logiciels et de gestionnaires de paquets.
• SPDX: Un autre format SBOM largement utilisé est SPDX (Software Package Data Exchange), qui est maintenu par le groupe de travail SPDX de la Fondation Linux. SPDX est une norme ouverte permettant de décrire les progiciels et les métadonnées qui leur sont associées, y compris les informations sur les licences et les déclarations de droits d'auteur.
• Étiquettes SWID : Les étiquettes SWID (Software Identification Tags) sont un moyen normalisé d'identifier les composants logiciels et les métadonnées qui leur sont associées.
• BOMXML: BOMXML est un format basé sur XML pour décrire les composants logiciels et leurs relations.

Dans l'ensemble, le choix du format du SBOM peut dépendre des besoins et exigences spécifiques de l'organisation ou du secteur qui l'utilise, ainsi que des outils et systèmes utilisés pour générer et consommer les données du SBOM. Cela accroît la complexité pour les équipes et les technologies de gestion des risques des tiers, car elles peuvent avoir besoin de consommer, d'interpréter et d'analyser des formats multiples.

Comment inclure le SBOM dans votre programme de gestion des risques pour les tiers ?

Indépendamment de la complexité de la situation, l'utilisation des SBOM devrait s'intensifier. Au fur et à mesure que leur utilisation se répandra, il est probable qu'ils deviendront un élément standard des pratiques de gestion des risques des tiers. Les organisations pourront utiliser les SBOM pour identifier les vulnérabilités des logiciels de tiers et prendre des mesures proactives pour atténuer ces risques. En outre, les organismes de réglementation peuvent exiger des organisations qu'elles fournissent des SBOM dans le cadre de leurs exigences de conformité. Voici quelques recommandations pour considérer le SBOM comme un élément de la diligence raisonnable à l'égard des tiers :

1. Exiger des vendeurs qu'ils fournissent des SBOM : Dans le cadre du processus de diligence raisonnable, exigez des fournisseurs qu'ils mettent à jour les SBOM de leurs produits logiciels. Cela vous aidera à identifier les vulnérabilités potentielles ou les problèmes de licence qui peuvent avoir un impact sur la sécurité et la conformité de votre organisation.
2. Évaluer les risques liés aux logiciels tiers : L'utilisation d'un SBOM pour évaluer les risques associés aux logiciels tiers vous aidera à déterminer quels composants peuvent nécessiter un examen plus approfondi ou des mesures d'atténuation.
3. Évaluer la conformité des licences: Les SBOM peuvent être utilisés pour évaluer la conformité des composants logiciels tiers avec les exigences en matière de licence et pour éviter les violations de licence.
4. Contrôler les vulnérabilités: Utiliser un SBOM pour surveiller les vulnérabilités des composants logiciels tiers, identifier les risques potentiels pour la sécurité et prendre des mesures proactives pour atténuer les risques.
5. Élaborer des plans d'atténuation: Les SBOM peuvent vous aider à élaborer des plans d'atténuation des risques et à résoudre les problèmes potentiels de sécurité ou de conformité avant qu'ils ne deviennent un problème.
6. Maintenir les SBOM à jour : Veillez à ce que les SBOM soient actualisés au fur et à mesure de l'ajout de nouveaux composants logiciels et de la mise à jour des composants existants. Cela vous aidera à conserver une vue précise et complète des dépendances logicielles de votre organisation.

En intégrant ces recommandations dans votre processus de diligence raisonnable à l'égard des tiers, vous pouvez vous assurer que votre organisation peut gérer efficacement les risques associés aux composants logiciels tiers.

À l'adresse Prevalent, nous prenons en charge les fichiers SBOM en tant qu'éléments de preuve dans le cadre du processus de diligence raisonnable. Pour en savoir plus sur la façon dont nous pouvons vous aider à intégrer les SBOM dans votre stratégie de programme TPRM, demandez une démonstration dès aujourd'hui.