Nomenclature logicielle (SBOM) : pourquoi les SBOM sont essentiels à la cybersécurité

Les SBOM sont un atout précieux pour :

• La conformité réglementaire

• La compatibilité entre les anciens packages logiciels et les mises à jour des logiciels open source

• La protection des clients contre les cyberattaques visant la chaîne d’approvisionnement logicielle

• Les mesures de sécurité lors de fusions impliquant des logiciels et des licences

Différence entre SBOM et CBOM

Le Cybersecurity Bill of Materials (CBOM) de 2018 couvre à la fois les logiciels et le matériel dans le cadre d’un décret présidentiel. Le SBOM ne répertorie que les composants logiciels du code, ainsi que leur historique de versions, de correctifs, de licences, de mises à jour et de modifications.

Pourquoi les SBOM sont-ils importants pour la cybersécurité ?

Les cyberattaques ciblant la chaîne d’approvisionnement logicielle sont en hausse. Plus de la moitié de ces attaques sont menées par des groupes de cybercriminels bien établis, connus pour leurs menaces persistantes avancées (APT). Leur objectif est d’exploiter la confiance que les utilisateurs et les fournisseurs accordent à leurs systèmes.

Le manque de transparence entourant les incidents cyber rend la chaîne d’approvisionnement vulnérable. Dans certains cas, les développeurs ne connaissent pas les vulnérabilités potentielles, ce qui peut également exposer les utilisateurs. Les bibliothèques open source dépendent d’autres composants logiciels. La vulnérabilité Log4Shell en est un exemple : de nombreux développeurs ne vérifient jamais ce composant (une bibliothèque de journalisation, dans ce cas), car il ne s’agit pas d’une dépendance logicielle directe, mais transitive, dont dépendent d’autres composants.

Si les équipes de développement reconnaissent déjà la nécessité de la sécurité des applications, les SBOM apportent une visibilité accrue sur les chaînes d’approvisionnement logicielles et les vulnérabilités potentielles. En sachant où des vulnérabilités peuvent se dissimuler dans un produit logiciel et en connaissant les composants du logiciel, surtout s’ils’agit d’open source, les utilisateurs sont mieux à même de déployer des outils de sécurité pour détecter et contrer les attaques potentielles.

En cas de cyberattaque, le SBOM peut aider à déterminer quels logiciels comportent des composants vulnérables et quels risques sont en jeu. Les utilisateurs peuvent ainsi collaborer avec les développeurs pour élaborer un correctif ou une autre solution d’atténuation.

Décret présidentiel 14028 sur les SBOM

Avant Log4Shell, d’autres incidents cyber, comme l’attaque de la chaîne d’approvisionnement SolarWinds et l’incident Equifax lié à Apache Struts, ont mis en évidence la vulnérabilité des agences gouvernementales, ainsi que des grandes entreprises et organisations, dans l’ensemble des infrastructures critiques. Ils ont également montré à quel point toutes les organisations dépendent de la chaîne d’approvisionnement logicielle et comment l’exploitation d’une seule vulnérabilité peut avoir des conséquences en cascade à grande échelle.

Le décret présidentiel 14028 demande aux agences gouvernementales, notamment au National Institute of Standards and Technology (NIST), à la National Security Agency (NSA), à l’Office of Management and Budget (OMB), à la Cybersecurity & Infrastructure Security Agency (CISA) et au Director of National Intelligence (DNI), d’élaborer des normes et des bonnes pratiques pour renforcer la sécurité de la chaîne d’approvisionnement logicielle. Les directives comprennent :

• Des critères d’évaluation de la sécurité des logiciels

• Des critères d’évaluation des pratiques de sécurité des développeurs et des fournisseurs eux-mêmes

• Des outils ou méthodes innovants pour démontrer le respect des pratiques de sécurité

D’ici février 2022, le NIST et les autres agences publieront des directives sur les bonnes pratiques en matière de chaîne d’approvisionnement logicielle. En attendant, consultez notre liste de bonnes pratiques de sécurité de la chaîne d’approvisionnement que vous pouvez mettre en œuvre dès aujourd’hui.

Quand utiliser une nomenclature logicielle ?

Un nouveau SBOM doit être créé à chaque nouvelle version d’un composant logiciel. De même, le SBOM doit être mis à jour à chaque modification d’un composant.

Le socle de référence de la NTIA pour un SBOM exige les informations suivantes :

• nom de l’auteur

• nom du fournisseur

• nom du composant

• empreinte du composant

• chaîne de version

• identifiant

• relation

Pour satisfaire aux exigences de référence, des normes SBOM ont été élaborées afin de proposer un format commun utilisable avec différents outils. Ces normes sont les suivantes :

• SPDX : Software Product Data Exchange est une norme ouverte qui permet de communiquer les composants, les licences et les informations de sécurité des packages logiciels. SPDX normalise plusieurs services, chacun disposant de son propre SBOM.

• SWID : Software Identification Tags est un ensemble de normes qui définissent un cycle de vie. Les balises sont ajoutées au point de terminaison lors de l’installation du logiciel. Il existe quatre types de balises : les balises Corpus, utilisées avant l’installation ; les balises primaires, qui fournissent le nom du produit et sont considérées comme un identifiant global unique ; les balises de correctif, qui décrivent les correctifs appliqués au logiciel ; et les balises supplémentaires, qui fournissent toute information additionnelle.

• OWASP Cyclone DX : Une norme SBOM légère utilisée pour l’analyse des composants de la chaîne d’approvisionnement et la sécurité des applications.

• VEX : Vulnerability Exploitability Exchange fournit des informations supplémentaires sur le produit, notamment les vulnérabilités détectées dans ses composants et les mesures correctives recommandées.

SBOM et intégrité logicielle

Les SBOM sont structurés de manière à évaluer l’intégrité de la chaîne d’approvisionnement logicielle et à permettre des évaluations des risques à partir des informations recueillies. À un niveau général, les SBOM servent à inventorier les composants logiciels de la chaîne d’approvisionnement. Mais, lorsqu’elles sont appliquées, les normes SBOM permettent de satisfaire aux exigences de conformité des logiciels open source. Par exemple, la norme SPDX identifie les licences de ces composants et contribue à garantir leur conformité.

Supply Chain Levels for Software Artifacts (SLSA) est un ensemble de normes et de contrôles visant à préserver l’intégrité des artefacts logiciels open source au sein de la chaîne d’approvisionnement. Lancé par Google, ce programme répond aux recommandations du NIST en matière de sécurité de la chaîne d’approvisionnement. SLSA complète les SBOM dans leur mission de protection du vaste éventail de logiciels open source utilisés tout au long du processus de développement.

Utiliser les SBOM pour détecter les dépendances et les vulnérabilités

Les SBOM ont principalement pour objectif de sécurité de repérer les vulnérabilités et les risques dans l’ensemble de la chaîne d’approvisionnement logicielle. Les données relatives aux vulnérabilités évoluent constamment à mesure que des composants sont ajoutés ou modifiés, ce qui peut introduire de nouveaux vecteurs d’exploitation. Les SBOM sont essentiellement statiques : les données utilisées pour les créer, elles, changent et évoluent sans cesse.

Un SBOM est un outil destiné aux clients de logiciels qui souhaitent analyser les vulnérabilités et vérifier que les développeurs mettent à jour les dépendances afin de réduire les risques. Cependant, toutes les vulnérabilités ne présentent pas le même niveau de risque : certaines ne présentent aucun risque. Pour répondre à cette difficulté, la NTIA propose deux mesures :

• Du côté du développement et de la chaîne d’approvisionnement, il faut déterminer l’impact de la vulnérabilité, et notamment si elle affectera certaines parties du logiciel.

• Les informations relatives à la vulnérabilité doivent être clairement communiquées dans les données du SBOM, avec la confirmation que celle-ci n’entraîne pas de risque supplémentaire.

Les SBOM au service de la sécurité de la chaîne d’approvisionnement

Les SBOM renforcent la sécurité de la chaîne d’approvisionnement logicielle de plusieurs façons :

• Une meilleure visibilité sur le produit logiciel, y compris sur les relations entre ses systèmes

• Le partage d’informations sur les vulnérabilités

• Une meilleure communication tout au long de la chaîne d’approvisionnement, du développeur à l’utilisateur, pour faciliter l’identification des risques de sécurité

• Des dossiers détaillés sur les normes de conformité et les audits

Le SBOM est un outil de sécurité évolutif qui améliore la protection et la détection des risques dans toute la chaîne d’approvisionnement logicielle. Grâce à des informations plus exactes et détaillées sur chaque composant logiciel, le SBOM permet de détecter les vulnérabilités dès les premières étapes du cycle de production logicielle et, par conséquent, de les atténuer avant qu’elles ne causent des dommages.

Snyk peut automatiser la création d’un SBOM et permettre aux organisations de suivre plus facilement les composants open source et les dépendances qu’elles utilisent. Snyk peut également analyser ces composants individuellement pour détecter d’éventuelles vulnérabilités et proposer des recommandations concrètes pour y remédier.