Exigences SBOM pour CRA

Le document de requirements de 17 pages est publié ici.

Ses exigences clés peuvent être résumées comme suit :

1. La compilation du SBOM est obligatoire pour répondre à la CRA.

2. Un SBOM DOIT contenir certaines informations minimales mais PEUT être élargi et détaillé selon les besoins.

3. Un nouveau SBOM séparé DOIT être généré pour chaque version de logiciel.

4. Une nouvelle version du SBOM pour une version de logiciel donnée DOIT être générée si et seulement si plus d'informations sur les composants logiciels inclus sont fournies ou si des erreurs dans les données du SBOM sont corrigées.

5. Il n'est PAS requis d'inclure des informations sur les vulnérabilités dans le SBOM.

6. Le SBOM doit être dans l'une des deux spécifications : CycloneDX version 1.4 ou supérieure OU SPDX version 2.3 ou supérieure.

7. Le SBOM DOIT être créé dans le cadre du processus de construction ou son équivalent lorsque le processus de construction n'existe pas.

8. Le créateur du SBOM DOIT être identifié par e-mail ou rediriger vers une URL.

9. La date et l'heure de la collecte des données du SBOM DOIVENT être incluses.

10. Pour chaque composant inclus dans le SBOM —

11. Le nom du composant, la version (préférée SemVer ou Calendrier), et la liste des composants dont dépend ce composant DOIVENT être inclus.

12. La licence du composant DOIT être incluse pour chaque licence et doit être identifiée avec son identifiant SPDX.

13. Si la licence n'est pas trouvée dans SPDX, ScanCode LicenseDB AboutCode doit être utilisé. Ceux-ci doivent être identifiés avec LicenseRef-scancode-.

14. Si aucun des deux ne trouve la licence, alors LicenRef-<unique-inventorying-entity> doit être utilisé pour répondre aux critères d'expression de licence SPDX.

15. Le composant DOIT inclure une valeur de hachage en tant que SHA-256.

16. Le SBOM PEUT inclure un SBOM-URI.

17. Chaque composant SBOM PEUT inclure le Code URI source, l'URI de la forme exécutable du composant, la valeur de hachage du code source en tant que SHA-256 (méthode exacte laissée indéterminée), et d'autres identifiants uniques du composant, tels que CPE ou PURL.

18. Les directives recommandent également le CSAF (avec un profil VEX) comme format pour distribuer les vulnérabilités séparément du SBOM.

La Directive Technique TR-03183 est une étape importante vers la clarification des étapes exactes que les constructeurs de logiciels doivent suivre pour respecter la conformité à la CRA. Cependant, il reste encore des réponses à apporter.

Sans CPE ou PURL comme exigence d'identification, la création de rapports de vulnérabilité à partir du SBOM est sujette à des erreurs.

‍La directive utilise ‘portée de livraison’ pour définir la profondeur à laquelle le composant transitif doit être énuméré. Cependant, elle n'inclut aucune orientation sur la ‘portée de livraison’ acceptable.

‍Les directives reconnaissent explicitement que la méthode pour calculer le SHA-256 du code source doit encore être finalisée.

Les directives appellent à inclure tous les composants transitifs de manière récursive mais ne requièrent pas explicitement de spécifier les relations entre ces composants. D'après notre expérience, le fait de manquer/sauter des relations est un problème courant avec les générateurs de SBOM et affecte négativement l'utilisation du SBOM pour la gestion des vulnérabilités.