Nous avons tous beaucoup entendu parler SBOM récemment. Nous avons entendu parler de leur utilité, de leur composition et de leurs exigences en matière de sécurité et de réglementation. Cette fois, je veux prendre le temps de parler d'un segment un peu moins connu du SBOM CyclonDX : le Dependency Graph.
Contrairement à son nom, le graphique de dépendance n'est pas un aspect visuel du SBOM. Son objectif est d'aider à décrire la dépendance des composants vis-à-vis d'autres composants. Cela repose sur un composant nom-réf – un identifiant unique pour chaque composant SBOM. L’idée est de montrer quels éléments dépendent ou sont connectés les uns aux autres. Cela semble assez simple, non ?
Scribe utilise beaucoup le Dependency Graph pour décider quoi faire. éléments du SBOM sont importants et auxquels nous devons prêter attention. Dans cet article, nous examinerons la manière Scribe utilise le SBOM Dependency Graph et les avantages pratiques que nous pouvons en tirer. Nous examinerons quelques exemples JSON d'un graphique de dépendance SBOM et conclurons par un aperçu de ce que nous pouvons faire d'autre avec celui-ci à l'avenir.
Qu'est-ce que le graphique de dépendance ?
Le Dependency Graph a été ajouté au format CyclonDX en 2019. Son objectif déclaré était de lier les composants ensemble à l'aide d'un identifiant unique qui sera plus tard connu sous le nom de nom-réf. Dans le Exemple de cas d'utilisation de CycloneDX, nous pouvons voir comment les dépendances utilisent l'ID de référence des composants pour montrer ce qui dépend de quoi :
Même sans donner d'exemples, je suis sûr que vous pouvez voir que la possibilité de connecter un élément à d'autres peut être utile. D'une part, en tant que cas d'utilisation le plus courant, il vous permet de voir immédiatement toutes les dépendances d'une bibliothèque en un seul endroit.
Un graphe de dépendances peut représenter à la fois des relations directes et transitives et s'étend généralement sur un nœud.
Bien qu'un arbre de dépendances complet puisse être représenté, cela n'est pas recommandé car cela pourrait entraîner des boucles sans fin en raison de dépendances circulaires ou d'autres relations complexes. Il est conseillé de garder vos graphiques simples en représentant un seul nœud.
Comment Scribe utilise-t-il le graphique de dépendances ?
Scribe utilise largement les métadonnées collectées avec le SBOM pour donner le contexte des preuves. Le contexte de la preuve inclut le lieu et le moment où elle a été collectée, quel est son sujet, etc. Alors que Scribe s'efforce d'offrir des informations fiables et réutilisables, nous utilisons le graphique de dépendances pour créer des connexions pouvant être utilisées entre différents clients et projets.
Voici les liens des graphiques de dépendances pris en charge par Scribe :
Source: Documentation du scribe
- Fichier de package: Cette connexion nous permet de voir quels fichiers appartiennent à chaque package. Évidemment, si nous trouvons un fichier dans un paquet auquel il n'appartient pas, c'est une indication claire d'un problème.
- Indication de couche et couche de package: Savoir quels packages se trouvent dans quelle couche d'image est pratique car nous pouvons ainsi classer les vulnérabilités par couches. Les problèmes dont vous avez hérité de votre image de base ou de votre image parent n'auront pas la même urgence et votre capacité directe à les influencer que ceux que l'on trouve sur les calques que vous avez créés vous-même.
- Fichier de calque: Semblable à la connexion package-fichier, cette connexion nous permet de voir quels fichiers sont associés à chaque couche. En tandem avec les autres connexions, nous pouvons vérifier que les fichiers sont associés au bon package et à la bonne couche et qu'il n'y a aucun fichier à des endroits où ils ne devraient pas être.
- Commit et Commit-Fichier: En identifiant quels fichiers proviennent de quel commit, nous pouvons nous assurer qu'il n'y a eu aucune modification excessive dans les fichiers de commit avant qu'ils ne soient utilisés pour créer l'image finale.
En utilisant toutes ces informations ensemble, nous pouvons dresser une image assez complète du SBOM sur les fichiers qui doivent être trouvés et où. En conséquence, nous avons plus de chances de détecter les valeurs aberrantes ou les aberrations qui pourraient indiquer un problème dans votre image – qu’il s’agisse d’un problème d’intégrité ou d’une attaque potentielle.
Graphique de dépendance et application des politiques
Scribe exploite ce graphique de dépendance complet pour appliquer efficacement des politiques complexes. Par exemple, le Fichier de validation la dépendance est exploitée pour faire respecter les politiques du propriétaire du code. Cela nous permet de vérifier qui a commis quel fichier et quand. Le Fichier de package la dépendance est utilisée pour garantir les politiques d’intégrité des packages. Cela nous permet de vérifier quels fichiers sont censés être liés à chaque package et de vérifier que c'est bien le cas. De plus, le Couche de paquet la dépendance est utilisée pour adapter les politiques de package aux exigences spécifiques de chaque couche. Étant donné que chaque image logicielle peut construire ses couches différemment, il est inestimable de pouvoir savoir avec certitude quels packages sont liés à quelle couche de l'image.
Personnalisation des informations de votre graphique de dépendance
Nous savons que tout le monde n’est pas disposé à partager toutes ces informations ou qu’il ne souhaite pas les voir ou les utiliser de quelque manière que ce soit.
Pour résoudre ce problème, Scribe vous permet de créer des versions plus spécifiques de votre SBOM. Voici les options de personnalisation que vous pouvez utiliser avec notre Valent outil lors de la création de SBOM que nous prenons actuellement en charge. Des options supplémentaires seront disponibles à l'avenir :
- Pour inclure uniquement des groupes de composants spécifiques, utilisez -Composants pour choisir entre les types de groupes.
- Pour inclure ou exclure des types de packages spécifiques, utilisez -Type d'emballage or – type d'exclusion de package pour sélectionner un type de package spécifique.
- Pour inclure les packages installés trouvés (groupe de packages installer) ou les packages référencés par les sources (groupe de packages indice), utilisation –groupe-paquet pour choisir entre les options.
- Pour exclure des composants, utilisez –filtre-regex, –portée du filtre, et –filtre-purl pour exclure tout composant que vous souhaitez exclure.
- Pour joindre n'importe quel contenu de fichier, utilisez –attacher-regex pour inclure le contenu de fichiers externes.
- Pour inclure des environnements et des étiquettes personnalisés, utilisez –env et -étiquette pour joindre vos champs personnalisés. Cela vous permet d'ajouter des métadonnées personnalisées au SBOM que vous créez.
Regarder vers l'avenir
Scribe considère le contexte et les liens que nous établissons entre les différents composants de votre SBOM en l'utilisant de la plus haute importance. Avec la capacité de notre Valint à signer, vérifier et gérer les politiques nous considérons qu’il est tout à fait possible d’envisager un avenir où l’on pourra faire plus que simplement gérer les politiques de sécurité. Nous pouvons imaginer un avenir dans lequel les informations du graphique de dépendance pourront être utilisées dans le contrôle qualité, pour répondre à des besoins de conformité spécifiques et même dans des domaines non liés comme la technologie financière et l'agriculture.
La plate-forme Scribe propose un niveau gratuit avec lequel vous pouvez commencer à l'essayer dès maintenant avec toutes les fonctionnalités à portée de main pour jouer. Je vous encourage à Essaie, voyez l'utilité de ces informations accumulées au fil du temps et voyez à quoi vous pouvez utiliser ces informations. J'espère que vous vous joindrez à nous alors que nous souhaitons un avenir plus sûr pour nous tous.
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
