Ett SBOM-verktyg kan ge värdefull maskinläsbar evidens, men resultatet är bara så fullständigt som den information och de artefakter det kan se. Enligt Cyber Resilience Act behöver tillverkare styrd komponentinformation som stöder bredare teknisk dokumentation och sårbarhetshantering.
En fil är inte samma sak som komponentstyrning
När team börjar förbereda sig för Cyber Resilience Act (CRA) är ett självklart första steg att utvärdera ett SBOM-verktyg, ansluta det till en byggpipeline och generera en maskinläsbar fil. Det är användbart, men det löser inte den underliggande uppgiften.
CRA definierar en programvaruförteckning, software bill of materials (SBOM), som ett formellt register med uppgifter om och leveranskedjerelationer mellan komponenter som ingår i programvaruelementen i en produkt med digitala element. I bilaga I, del II krävs att tillverkare identifierar och dokumenterar sårbarheter och komponenter, bland annat genom att upprätta en SBOM i ett allmänt använt, maskinläsbart format som minst omfattar produktens beroenden på högsta nivå. Förordning (EU) 2024/2847
Detta är ett fastställt rättsligt minimum, inte ett löfte om att en enda skanning ger en fullständig bild av varje relevant komponentrelation. Produktrisk, arkitektur och den evidens som behövs för att förklara produkten kan motivera en djupare täckning. SBOM:en ingår också i en bredare uppsättning skyldigheter: den tekniska dokumentationen måste omfatta bland annat produkten, dess utformning och utveckling, produktion, processer för sårbarhetshantering och SBOM:en. Den ska upprättas innan produkten släpps ut på marknaden och uppdateras när det är lämpligt under supportperioden. Förordning (EU) 2024/2847
Vad automatiserade verktyg kan och inte kan visa
Automatiserad generering kan analysera källkod, uppgifter från pakethanterare eller byggartefakter och omvandla synlig information till en SBOM. Detta är ofta mycket effektivt, särskilt när beroenden deklareras genom välkända programvaruekosystem.
Varje metod har dock ett särskilt perspektiv. En källkodsskanning, en inventering från en pakethanterare, en analys av byggartefakter och en binäranalys kan var och en visa olika information. CISA:s vägledning om SBOM-ramverk erkänner automatiserad generering under livscykeln, manuell generering för äldre system och heuristisk analys av färdig programvara som skilda sätt att skapa en SBOM. Den skiljer också mellan SBOM:er för design, källkod, bygge och driftsättning. CISA SBOM Framing
Detta är särskilt viktigt för inbyggda produkter. Team kan till exempel behöva bekräfta statusen för:
- fast programvara som följer med ett inköpt modem, trådlöst chip eller en sensor;
- proprietära bibliotek som erhålls som binärfiler från en leverantör; och
- patchar, drivrutiner och konfigurationer i ett anpassat BSP-paket.
Dessa komponenter kan vara synliga genom leverantörsdokumentation, en leverantörs-SBOM, tekniska register eller en särskild analysmetod. De kanske inte är synliga i varje källartefakt eller för varje verktyg. Att behandla ett automatiserat resultat som hela komponentbilden kan därför lämna luckor som inte har granskats.
Bygg komponentregistret kring produkten
Ett tillförlitligt arbetssätt utgår från en kontrollerad bild av produkten och dess version, snarare än från resultatet från ett enda verktyg. Det tekniska registret bör identifiera direkta beroenden och, när det är relevant för risk, arkitektur eller evidensbehov, djupare beroenden och deras relationer. Det bör också tydliggöra vilken information som har bekräftats, vilken evidens som stöder den och vad som fortfarande är okänt.
CISA beskriver en SBOM som en formell, maskinläsbar inventering av programvarukomponenter, beroenden, komponentinformation och relationer. Vägledningen anger att inventeringen bör vara så heltäckande som möjligt och att den bör ange när relationer inte kan uttryckas. Detta är operativ vägledning snarare än CRA:s rättsliga minimum, men det är en användbar disciplin för att hantera ofullständig insyn. CISA SBOM Framing
En teknisk komponentlista som upprätthålls från den tidiga designfasen kan utgöra en praktisk grund för detta arbete. Den kan uppdateras när ett bibliotek, en modul, en avbildning av fast programvara eller en leverantörsdel introduceras, ändras eller tas bort. Den bör inte misstas för ett separat rättsligt formatkrav; dess värde ligger i att den skapar spårbarhet mellan designval, leverantörsinformation, byggen och den slutliga SBOM:en.
Använd verktyg som en del av ett kontrollerat arbetsflöde
Verktyg kan skapa, berika, jämföra och validera SBOM-information. Deras mest användbara roll beror på produkten och den tillgängliga evidensen. Ett praktiskt arbetsflöde kan omfatta följande kontroller:
- Definiera produktgränsen, produktversionen och de programvaruelement som omfattas.
- Registrera direkta beroenden och fastställ om djupare beroenden behöver fångas utifrån produktens risk och arkitektur.
- Inhämta och bedöm leverantörsevidens för externt tillhandahållen programvara, fast programvara och komponenter.
- Registrera kända begränsningar och relationer som ännu inte kan uttryckas, i stället för att tyst behandla dem som frånvarande.
- Ta fram den erforderliga maskinläsbara SBOM:en i ett allmänt använt format.
- Jämför komponentregistret och SBOM:en med käll-, bygg- eller driftsatta artefakter när så är lämpligt, och utred sedan väsentliga skillnader.
- Koppla komponentinformationen till sårbarhetshanteringen, inklusive det produktsammanhang som behövs för att bedöma om en rapporterad sårbarhet påverkar produkten.
- Styr uppdateringar så att komponentregistret, SBOM:en och den tekniska dokumentationen förblir samordnade under supportperioden.
SPDX och CycloneDX är tillgängliga format för att representera maskinläsbar SBOM-information. Vart och ett av formaten garanterar inte i sig fullständighet, sårbarhetsstatus eller överensstämmelse med CRA. SPDX specifications CycloneDX SBOM capabilities
Håll sårbarhetshanteringen skild från inventeringen
En SBOM är viktig evidens för sårbarhetshantering, men den är inte i sig ett beslut om sårbarhet. Bedömningen av om en produkt påverkas kräver också tillförlitlig komponentidentitet, relevant sårbarhetsinformation, produktsammanhang och analys.
CRA kräver att tillverkare dokumenterar en cybersäkerhetsriskbedömning och tar hänsyn till resultatet under planering, utformning, utveckling, produktion, leverans och underhåll. Den kräver också processer för sårbarhetshantering. En SBOM kan stödja dessa aktiviteter, men en skanning eller enbart en SBOM fastställer inte överensstämmelse. Förordning (EU) 2024/2847
Ett exempel från industriell utveckling
För produkter för industriell automation och styrsystem ger IEC 62443-4-1:2018 ett exempel på praxis för säker produktutvecklingslivscykel. Dess tillämpningsområde omfattar hårdvara, programvara och fast programvara, och dess metod för komponenthantering behandlar säkerhetsrisker från externt tillhandahållna komponenter. Detta kan vara en användbar kontrollmodell för att hantera teknik från leverantörer och upprätthålla en inventering för felhantering.
Standarden är inte i sig ett CRA-krav, och användning av den fastställer inte överensstämmelse med CRA. IEC 62443-4-1:2018
Vad en granskare bör kunna spåra
En granskare bör kunna spåra produkten och den version som omfattas, de direkta beroendena och eventuell vald djupare täckning, evidensen för externt tillhandahållen programvara och fast programvara, deklarerade okända förhållanden och begränsningar, den maskinläsbara SBOM:en, jämförelser med relevanta artefakter, beslut om sårbarhetshantering och kontrollerade uppdateringar av den tekniska dokumentationen.
Denna spårbarhet är skillnaden mellan att generera en komponentfil och att styra komponentinformation genom hela produktlivscykeln.