Et SBOM-værktøj kan skabe værdifuld maskinlæsbar dokumentation, men dets output er kun så fuldstændigt som de oplysninger og artefakter, det kan se. Under Cyber Resilience Act har producenter brug for styrede komponentoplysninger, der understøtter bredere teknisk dokumentation og sårbarhedshåndtering.
En fil er ikke det samme som komponentstyring
Når teams begynder at forberede sig på Cyber Resilience Act (CRA), er et oplagt første skridt at vurdere et SBOM-værktøj, forbinde det med en buildpipeline og generere en maskinlæsbar fil. Det er nyttigt, men det løser ikke den underliggende opgave.
CRA definerer en software bill of materials (SBOM) som en formel fortegnelse med detaljer om og forsyningskædeforhold mellem komponenter, der indgår i softwareelementerne i et produkt med digitale elementer. Bilag I, del II kræver, at producenter identificerer og dokumenterer sårbarheder og komponenter, herunder ved at udarbejde en SBOM i et almindeligt anvendt maskinlæsbart format, der som minimum dækker produktets afhængigheder på øverste niveau. Regulation (EU) 2024/2847
Det er et fastlagt juridisk minimum, ikke et løfte om, at én scanning giver et fuldstændigt billede af alle relevante komponentforhold. Produktrisiko, arkitektur og den dokumentation, der er nødvendig for at forklare produktet, kan begrunde en mere dybdegående dækning. SBOM'en indgår også i et bredere sæt forpligtelser: Den tekniske dokumentation skal omfatte forhold som produktet, dets udformning og udvikling, produktion, processer for sårbarhedshåndtering og SBOM'en. Den skal udarbejdes, før produktet bringes i omsætning, og opdateres, hvor det er relevant, i supportperioden. Regulation (EU) 2024/2847
Hvad automatiserede værktøjer kan og ikke kan vise
Automatiseret generering kan analysere kildekode, pakkehåndteringsregistre eller buildartefakter og omsætte synlige oplysninger til en SBOM. Det er ofte meget effektivt, særligt når afhængigheder deklareres gennem veletablerede softwareøkosystemer.
Hver metode har dog sit særlige perspektiv. En scanning af kildekode, en pakkehåndteringsfortegnelse, en analyse af buildartefakter og en binær analyse kan hver især afdække forskellige oplysninger. CISA's vejledning om SBOM-framing anerkender automatiseret generering gennem livscyklussen, manuel generering for ældre systemer og heuristisk analyse af færdig software som særskilte fremgangsmåder. Den skelner også mellem design-, kildekode-, build- og implementerede SBOM'er. CISA SBOM Framing
Dette er særligt vigtigt for indlejrede produkter. Teams kan eksempelvis have behov for at bekræfte status for:
- firmware, der leveres med et indkøbt modem, en trådløs chip eller en sensor;
- proprietære biblioteker, der modtages som binære filer fra en leverandør; og
- programrettelser, drivere og konfigurationer i en tilpasset board support package.
Disse komponenter kan være synlige via leverandørdokumentation, en leverandør-SBOM, tekniske registre eller en bestemt analysemetode. De er muligvis ikke synlige i alle kildeartefakter eller for alle værktøjer. Hvis et enkelt automatiseret output behandles som det samlede komponentbillede, kan det derfor efterlade uudforskede huller.
Opbyg komponentfortegnelsen omkring produktet
En pålidelig tilgang starter med et kontrolleret overblik over produktet og dets version frem for med output fra ét værktøj. Den tekniske fortegnelse bør identificere direkte afhængigheder og, hvor det er relevant for risiko, arkitektur eller dokumentationsbehov, dybere afhængigheder og deres relationer. Den bør også tydeliggøre, hvilke oplysninger der er bekræftet, hvilken dokumentation der understøtter dem, og hvad der fortsat er ukendt.
CISA beskriver en SBOM som en formel, maskinlæsbar fortegnelse over softwarekomponenter, afhængigheder, komponentoplysninger og relationer. Vejledningen angiver, at fortegnelsen bør være så fuldstændig som muligt og oplyse, når relationer ikke kan beskrives. Dette er operationel vejledning frem for CRA's juridiske minimum, men det er en nyttig disciplin til håndtering af ufuldstændig synlighed. CISA SBOM Framing
En teknisk komponentliste, der vedligeholdes fra den tidlige designfase, kan danne et praktisk grundlag for dette arbejde. Den kan opdateres, når et bibliotek, modul, firmwareimage eller leverandørdel indføres, ændres eller fjernes. Den bør ikke forveksles med et særskilt juridisk formatkrav. Dens værdi ligger i, at den skaber sporbarhed mellem designvalg, leverandøroplysninger, builds og den endelige SBOM.
Brug værktøjer som en del af en kontrolleret arbejdsgang
Værktøjer kan oprette, berige, sammenligne og validere SBOM-oplysninger. Deres mest nyttige rolle afhænger af produktet og den tilgængelige dokumentation. En praktisk arbejdsgang kan omfatte følgende kontroller:
- Definér produktgrænsen, produktversionen og de softwareelementer, der er omfattet.
- Registrér direkte afhængigheder, og afgør, om dybere afhængigheder skal medtages ud fra produktets risiko og arkitektur.
- Indhent og vurder leverandørdokumentation for eksternt leveret software, firmware og komponenter.
- Registrér kendte begrænsninger og relationer, der endnu ikke kan beskrives, i stedet for stiltiende at behandle dem som fraværende.
- Udarbejd den krævede maskinlæsbare SBOM i et almindeligt anvendt format.
- Sammenlign komponentfortegnelsen og SBOM'en med kilde-, build- eller implementerede artefakter efter behov, og undersøg derefter væsentlige forskelle.
- Forbind komponentoplysninger med sårbarhedshåndtering, herunder den produktkontekst, der er nødvendig for at vurdere, om en rapporteret sårbarhed påvirker produktet.
- Kontrollér opdateringer, så komponentfortegnelsen, SBOM'en og den tekniske dokumentation forbliver afstemt i supportperioden.
SPDX og CycloneDX er tilgængelige formater til repræsentation af maskinlæsbare SBOM-oplysninger. Ingen af formaterne garanterer i sig selv fuldstændighed, sårbarhedsstatus eller overensstemmelse med CRA. SPDX specifications CycloneDX SBOM capabilities
Hold sårbarhedshåndtering adskilt fra fortegnelsen
En SBOM er vigtig dokumentation for sårbarhedshåndtering, men den er ikke i sig selv en sårbarhedsvurdering. En vurdering af, om et produkt er påvirket, kræver også pålidelig komponentidentitet, relevante sårbarhedsoplysninger, produktkontekst og analyse.
CRA kræver, at producenter dokumenterer en cybersikkerhedsrisikovurdering og tager dens resultat i betragtning under planlægning, design, udvikling, produktion, levering og vedligeholdelse. Den kræver også processer for sårbarhedshåndtering. En SBOM kan understøtte disse aktiviteter, men en scanning eller en SBOM alene fastslår ikke overensstemmelse. Regulation (EU) 2024/2847
Et eksempel fra industriel udvikling
For produkter til industriel automatisering og styresystemer giver IEC 62443-4-1:2018 et eksempel på praksis for sikker produktudvikling gennem livscyklussen. Dens anvendelsesområde omfatter hardware, software og firmware, og dens tilgang til komponentstyring behandler sikkerhedsrisici fra eksternt leverede komponenter. Den kan være en nyttig kontrolmodel til håndtering af leverandørleveret teknologi og vedligeholdelse af en fortegnelse til fejlhåndtering.
Standarden er ikke i sig selv et CRA-krav, og anvendelse af den fastslår ikke overensstemmelse med CRA. IEC 62443-4-1:2018
Hvad en kontrollant bør kunne spore
En kontrollant bør kunne spore produktet og den omfattede version, de direkte afhængigheder og enhver valgt dybere dækning, dokumentationen for eksternt leveret software og firmware, erklærede ukendte forhold og begrænsninger, den maskinlæsbare SBOM, sammenligninger med relevante artefakter, beslutninger om sårbarhedshåndtering og kontrollerede opdateringer af den tekniske dokumentation.
Denne sporbarhed er forskellen mellem at generere en komponentfil og at styre komponentoplysninger gennem hele produktets livscyklus.