Beaucoup de mots ont été écrits ces dernières années sur SBOM – Nomenclature logicielle. Avec toute cette exposition, les gens ont le sentiment de savoir assez bien ce qu'il faut expliquer : il s'agit d'une liste d'ingrédients logiciels, c'est important pour la transparence et la sécurité, et cela permet d'exposer les dépendances transitoires. Tout ceci est vrai.
Pourtant, le SBOM n’est pas aussi clair qu’il y paraît. D'une part, considérez que pour rester à jour, chaque nouvelle version de bibliothèque ou patch nécessite la publication d'un nouveau SBOM. Souvent, vous ne modifiez ou ne corrigez qu'une ou deux bibliothèques à la fois afin de pouvoir simplement décomposer leurs nouveaux ingrédients, les ajouter au SBOM et laisser tout le reste pareil, n'est-ce pas ?
Et qu’en est-il du concept de « connu-inconnu » ? Si les développeurs savent qu'il leur manque quelque chose, ils peuvent le saisir comme « connu-inconnu » et remplir les espaces plus tard (ou pas du tout).
Il existe également des artefacts logiciels très complexes et comprenant plusieurs éléments imbriqués, chacun étant un artefact logiciel à part entière. Chaque élément a souvent son propre SBOM distinct, et l'ensemble de la construction peut avoir un SBOM plus grand et agrégé.
Tout cela montre qu'au lieu d'un fichier SBOM simple et clair, vous pourriez vous retrouver avec une multitude d'éléments différents et en constante évolution que vous devez constamment maintenir aussi à jour que possible.
Tout cela est bien beau, mais quelle différence cela ferait-il pour quiconque si un SBOM ou une partie d'un SBOM n'était pas aussi précis ou à jour qu'il pourrait l'être ? Que pourrions-nous faire pour maintenir à la fois la provenance et l'exactitude du SBOM ?
Dans cet article, nous examinerons l'utilisation du SBOM dans les analyses de vulnérabilités et la divulgation des vulnérabilités. Nous parlerons de la signature cryptographique et verrons comment la signature d'un SBOM, ou de parties de celui-ci, le rend plus utile en tant qu'outil de sécurité et de transparence. Nous parlerons également des métadonnées et de la raison pour laquelle elles sont si importantes dans le SBOM et d'autres productions d'artefacts, en particulier lorsqu'elles sont signées cryptographiquement dans une attestation.
Commencez ici : qu’est-ce que la signature cryptographique ?
Les signatures cryptographiques sont utilisées pour vérifier l'intégrité et l'exactitude des fichiers ou dossiers numériques. Un fichier signé ne peut pas être falsifié sans rendre la signature invalide et il sera donc immédiatement découvert dès que quelqu'un tentera de vérifier le document signé.
Cela fait des signatures numériques un outil inestimable dans l'arsenal des logiciel de sécurité l’industrie et il existe de nombreuses utilisations déjà trouvées pour le simple concept de signature numérique ou cryptographique d’actifs numériques.
Comment ça marche? Les signatures numériques sont basées sur une cryptographie asymétrique dans laquelle une entité dispose de deux clés : une clé privée et une clé publique. Les deux clés sont liées entre elles de telle manière qu'un document signé avec sa clé privée peut être vérifié à l'aide de sa clé publique. Une vérification signifierait à la fois que le document n'a pas été falsifié de quelque manière que ce soit (même la modification d'un seul bit rendrait la signature invérifiable) et prouverait l'identité du signataire, ou du moins l'identité de la clé utilisée.
Que fais-tu avec ce SBOM ?
Les SBOM ne sont pas de simples fichiers longs et complexes contenant des informations sur les composants logiciels. Ils constituent votre passerelle pour savoir exactement quels composants composent votre artefact logiciel. Vous devez connaître la liste complète des composants, car même si vous pensez savoir exactement ce que vous avez inclus, il est probable qu'avec chaque bibliothèque ajoutée que vous avez livrée, vous ayez livré de nombreuses dépendances cachées et transitoires, dont chacune pourrait être porteuse d'une vulnérabilité ou l'exploiter. est désormais inclus dans les logiciels que vous expédiez à vos clients.
Une fois que vous disposez d'un SBOM et de cette liste complète d'ingrédients, vous pouvez analyser cette liste par rapport aux bases de données de vulnérabilités connues et voir quelles vulnérabilités sont incluses dans votre logiciel. Mais ce n'est que le début. Comme le savent tous ceux qui ont déjà effectué une analyse de vulnérabilité, les résultats, même d’une simple analyse d’artefacts, peuvent facilement se chiffrer en centaines (ou plus) de vulnérabilités.
C'est là que commence le travail acharné : cartographier chaque vulnérabilité, voir si elle pourrait être exploitable dans votre composition logicielle spécifique, documenter ces informations et traiter les vulnérabilités exploitables en les corrigeant et en les corrigeant, de préférence par ordre de danger qu'elles représentent (en direct). les exploits dans la nature sont plus dangereux qu'un exploit théorique qui n'a encore jamais eu lieu).
Tout ce travail, cette documentation des vulnérabilités et ces mesures correctives sont importants pour vous en tant que producteur de logiciels, mais ils sont également importants pour vos clients, vos partenaires et vos auditeurs potentiels.
Ils veulent savoir que vous êtes conscient des vulnérabilités potentielles et que vous les maîtrisez, corrigeant et corrigeant les failles, afin que celles-ci ne les impactent pas en tant que clients ou partenaires.
Étant donné que le temps que vous effectuez une analyse est important à cet égard en raison du fait que de nouvelles vulnérabilités apparaissent constamment, signer votre SBOM avec les métadonnées du QUAND il a été créé est un excellent moyen de montrer que vous êtes vraiment au top. de votre liste de vulnérabilités.
De cette façon, vous pouvez prouver que vous connaissiez une vulnérabilité à l'avance et qu'elle n'est pas pertinente (en utilisant un VEXER consultatif), qu'il n'est pas présent dans une certaine version, ou qu'il n'existait même pas au moment où vous avez publié votre dernière version.
Où dois-je signer?
Remplaçons maintenant ce simple fichier de liste d'ingrédients par l'un des cas d'utilisation les plus complexes décrits au début de l'article. Une fois que vous avez combiné plusieurs SBOM pour former une version agrégée plus grande pour décrire votre artefact complet, la signature et la vérification de chaque partie individuelle de cette version agrégée deviennent encore plus importantes. Supposons que vous construisiez une nouvelle version d'un artefact logiciel complexe. Dans cette nouvelle version, la seule chose qui a changé est la partie 1 d'un artefact en 3 parties. Les deux autres parties restent exactement les mêmes. Pourquoi devriez-vous perdre du temps et des ressources à créer le SBOM complet en 3 parties, à analyser les 3 à la recherche de vulnérabilités et à cartographier les 3 pour détecter les exploits pertinents ? Les seules modifications concernaient la partie 1, c'est donc la seule dans laquelle vous devez effectuer le travail. Si vous avez signé les 3 SBOM et les analyses de vulnérabilité la dernière fois que vous les avez créés, vous pouvez inclure les informations des deux autres parties en sachant que cela ne pourrait pas être le cas. n’ont pas été modifiés. Vous pourrez alors prouver à tout moment que les SBOM des parties 2 et 3 sont identiques aux versions originales. Vous pouvez bien sûr refaire les analyses si vous craignez de nouvelles vulnérabilités, mais cela dépend entièrement de vous et de votre logiciel. analyse de risque.
Être capable de prouver à vos clients, partenaires et auditeurs quand et à quelle fréquence vous avez créé des SBOM et les avez analysés à la recherche de vulnérabilités est utile pour de nombreuses raisons. Ce qui n'est pas le moindre, c'est qu'il pourrait être utilisé devant les tribunaux pour prouver que vous n'êtes pas responsable des dommages causés par un exploit puisque vous avez fait tout ce qu'il fallait pour être protégé, obtenant ainsi un port sûr.
Où aller en partant d'ici
Comme nous l'avons indiqué précédemment, l'un des problèmes liés à la signature numérique d'artefacts ou de fichiers logiciels est la difficulté de gérer les systèmes de gestion des clés. Une fois que nous avons supprimé ce problème en utilisant quelque chose comme Sigstore pour contourner l'utilisation d'une PKI traditionnelle et rendre le flux de signature et de vérification automatique, il n'y a vraiment aucune raison de ne pas utiliser cet outil de sécurité. Si l’on considère que l’identité utilisée pour signer un fichier ou un artefact peut également être utilisée dans une politique vérifiant la sécurité de votre pipeline CI/CD, vous devriez être encore plus motivé pour commencer à signer presque tout ce qui est en vue.
Signer des fichiers avec leurs métadonnées peut vous aider à vérifier l'heure et le lieu de leur origine, ainsi que la personne et le système dans lesquels ils ont été créés, toutes les informations pertinentes lorsqu'elles sont examinées à travers le point de vue d'un spécialiste de la sécurité. Être capable de dire que la personne, le système et l'heure correspondent à l'entreprise et au pipeline dans lesquels le logiciel a été créé est une bonne idée lorsqu'une simple substitution peut présenter une contrefaçon convaincante et signée – jusqu'à ce que la personnalité du chanteur soit vérifiée.
Étant donné que l’outil que je suggère pour signer et vérifier les preuves est gratuit, vous ne devriez vraiment avoir aucune excuse. Consultez notre article complet sur Valent – notre outil d'intégrité de validation pour voir ce que vous pouvez faire d'autre avec et commencer à signer vos SBOM et autres preuves générées dès aujourd'hui.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
