SBOM-eisen voor CRA
25 mrt 2024
Interlynk
Het Europees Parlement heeft de Cyber Resilience Act (CRA) van de EU goedgekeurd op 12 maart.
De CRA gebruikt de Software Bill of Materials (SBOM) om productbeveiliging te beschrijven, vast te leggen en te monitoren. Daarom wordt binnenkort een formeel document verwacht dat de compliance-eisen voor de CRA uiteenzet en specifiek alle SBOM-specifieke eisen beschrijft.
In afwachting van de aanneming van de CRA heeft het Federaal Bureau voor Informatiebeveiliging (BSI) in Duitsland gewerkt aan de verduidelijking van de SBOM-eisen. De Technische Richtlijn TR-03183: Cyber Resilience-eisen voor fabrikanten en producten (Deel 2: Software Bill of Materials (SBOM)) is sinds 28 november gepubliceerd.
TR-03183: SBOM-vereisten voor CRA
Het 17-pagina's tellende eisen document is gepubliceerd hier.
De belangrijkste vereisten kunnen als volgt worden samengevat:
De compilatie van SBOM is verplicht om aan de CRA te voldoen.
Een SBOM MOET bepaalde minimuminformatie bevatten, maar MAG worden uitgebreid en gedetailleerd zoals gewenst.
Een nieuwe, aparte SBOM MOET worden gegenereerd voor elke softwareversie.
Een nieuwe versie van de SBOM voor een gegeven softwareversie MOET worden gegenereerd als en alleen als meer informatie over de opgenomen softwarecomponenten is verstrekt of fouten in de SBOM-gegevens zijn gecorrigeerd.
Het is NIET verplicht om kwetsbaarheidsinformatie in de SBOM op te nemen.
SBOM moet in een van de twee specificaties zijn: CycloneDX versie 1.4 of hoger OF SPDX versie 2.3 of hoger.
De SBOM MOET worden aangemaakt als onderdeel van het buildproces of het equivalent daarvan indien het buildproces niet bestaat.
De maker van de SBOM MOET worden geïdentificeerd per e-mail of terugvallen op een URL.
De datum en tijd van de SBOM-dataverzameling MOET worden opgenomen.
Voor elke component die in de SBOM is opgenomen -
De componentnaam, versie (bij voorkeur SemVer of Calendar), en lijst van componenten waarop deze component afhankelijk is MOET worden opgenomen.
De componentlicentie MOET worden opgenomen voor elke licentie en moet worden geïdentificeerd met hun SPDX identificatie.
Als de licentie niet wordt gevonden in SPDX, moet ScanCode LicenseDB AboutCode worden gebruikt. Deze moeten worden geïdentificeerd met
LicenseRef-scancode-.Als geen van beide de licentie kan vinden, moet
LicenRef-<unique-inventorying-entity>worden gebruikt om te voldoen aan de SPDX licentie-expressiecriteria.De component MOET een hashwaarde bevatten als SHA-256.
De SBOM MAG een SBOM-URI bevatten.
Elke SBOM-component MAG de Source Code URI, de URI van de uitvoerbare vorm van de component, de hashwaarde van de broncode als SHA-256 (exacte methode niet gedetermineerd), en andere unieke identificatoren van de component, zoals CPE of PURL bevatten.
De richtlijnen bevelen ook CSAF (met een VEX-profiel) aan als het formaat voor het afzonderlijk distribueren van kwetsbaarheden van de SBOM.
Technische richtlijn TR-03183 is een belangrijke stap vooruit in de verduidelijking van de exacte stappen die softwarebouwers moeten nemen om aan de CRA-compliance te voldoen. Echter, er moet nog wel een antwoord worden gegeven.
Zonder CPE of PURL als identificatievereiste is het maken van kwetsbaarheidsrapporten vanuit de SBOM gevoelig voor fouten.
De richtlijn gebruikt ‘leveringsomvang’ om de diepte te definiëren waarin de transitieve component moet worden opgesomd. Echter, het bevat geen richtlijnen over de aanvaardbare ‘leveringsomvang.’
De richtlijnen erkennen expliciet dat de methode voor het berekenen van SHA-256 van de broncode nog moet worden voltooid.
De richtlijnen vragen om alle transitieve componenten recursief op te nemen, maar vereisen niet expliciet het specificeren van relaties tussen die componenten. Uit onze ervaring blijkt dat het ontbreken/overslaan van relaties een veelvoorkomend probleem is bij SBOM-generators en een negatieve invloed heeft op het gebruik van SBOM voor kwetsbaarheidsbeheer.
INHOUDSOPGAVE