Kryptografisk materiallista (CBOM): Nyckeln till att säkra din programvaruleveranskedja

Snabbt svar: En kryptografisk materiallista (CBOM) är en strukturerad inventering av varje algoritm, nyckel, certifikat, protokoll och kryptografiskt bibliotek som din programvara och infrastruktur använder, byggd på OWASP CycloneDX-standarden. Det är viktigt eftersom du inte kan migrera från kvantumsårbar kryptografi eller bevisa efterlevnad utan att veta var den finns. Börja med att skanna din kod, dina certifikat och runtime-miljöer för att bygga en baslinje.

Attacker mot leveranskedjor är mångfacetterade och de drabbar både företag och myndigheter. Kommersiell programvara och öppen källkod är båda måltavlor, vilket gör tydlig insyn i varje programvara och kryptografiska tillgångar i dina utvecklings- och distributionsrörledningar till ett grundläggande krav, inte något som är bra att ha. 

År 2020 komprometterade leveranskedjeattacken SolarWinds tusentals organisationer och flera amerikanska myndigheter efter att angripare injicerat en bakdörr, känd som SUNBURST, i Orions IT-uppdateringsverktyg. I februari 2021 bröt sig säkerhetsforskaren Alex Birsan in i Microsoft, Tesla, Uber och Apple med hjälp av en teknik som kallas beroendeförvirring, vilket lurade interna byggsystem att hämta skadliga offentliga paket istället för betrodda interna.

Som svar utfärdade den amerikanska regeringen i maj 2021 Executive Order 14028, "Förbättra nationens cybersäkerhet", som krävde att programvaruleverantörer som säljer till federala myndigheter tillhandahöll en Software Bill of Materials (SBOM). En SBOM är en maskinläsbar lista över varje modul, bibliotek och tredjepartsberoende i en programvara, tillsammans med metadata som licens och version, så att en försvarare snabbt kan identifiera och uppdatera komponenter som påverkats av en attack i leveranskedjan. 

NIST rekommenderade därefter att SBOM-praxis skulle utökas med en kryptografisk materiallista (CBOM) som en del av sin vägledning för migrering efter kvantkryptografi (PQC), särskilt i National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellences SP 1800-38 praxisguide. Den rekommendationen har sedan dess formaliserats: CBOM är nu en inbyggd del av OWASP CycloneDX Bill of Materials-standarden, som lade till stöd för kryptografiska tillgångar i version 1.6 och publiceras som ECMA-424-standarden.

Key Takeaways

• En CBOM är en strukturerad inventering av algoritmer, nycklar, certifikat, protokoll och kryptografiska bibliotek, standardiserad under OWASP CycloneDX (nu publicerad som ECMA-424).
• Till skillnad från en SBOM, som listar programvarukomponenter, listar en CBOM den kryptografi som dessa komponenter faktiskt använder, vilket gör den till utgångspunkten för planering efter kvantmigrering.
• NIST:s utkast till tidslinje för IR 8547 föreslår att RSA, ECDSA, ECDH och finite-field Diffie-Hellman avvecklas efter 2030 och förbjuds efter 2035, en tidslinje som nu stöds för federala system av Executive Order 14412 och OMB Memorandum M-26-15.
• Ett komplett CBOM-program går utöver en engångsskanning: det klassificerar tillgångar efter risk, tillämpar åtkomstkontroller på nycklar, styr den kryptografiska livscykeln och mappar resultat till efterlevnadsramverk som PCI DSS och GDPR.
• CBOM-verktyg har verkliga begränsningar, inklusive blinda fläckar för konfigurationsdriven kryptografi och äldre binärfiler, så behandla det som en kontinuerlig praxis snarare än en enskild granskning.

Vad är en kryptografisk materiallista (CBOM)? 

En kryptografisk materiallista (CBOM) är en maskinläsbar inventering som katalogiserar varje kryptografisk tillgång i ett system: algoritmer och deras parametrar (nyckelstorlekar, lägen), nycklar, digitala certifikat, kryptografiska bibliotek och de protokoll som använder dem. CBOM formaliseras som en utökning av OWASP CycloneDX-standarden, samma fullstack-format för materiallista som används för SBOM, SaaSBOM och hårdvaru-BOM. Medan en SBOM anger vilka programvarukomponenter och versioner du kör, anger en CBOM vilken kryptografi dessa komponenter faktiskt använder, information som enbart en SBOM inte fångar upp.

CBOM vs. SBOM: Vad är skillnaden?

En SBOM inventerar programvarukomponenter: bibliotek, beroenden och deras versioner och licenser. En CBOM inventerar kryptografin inuti och runt dessa komponenter. De två kompletterar varandra, och NIST:s egen PQC-migreringsvägledning behandlar CBOM som en förlängning av SBOM-praxis snarare än en ersättning för den.

Aspect	SBOM	CBOM
Spår	Programvarukomponenter, versioner, licenser	Algoritmer, nyckelstorlekar, certifikat, protokoll
Primär drivkraft	Executive Order 14028 (2021), risk i leveranskedjan	Post-kvantmigrering, NIST PQC-vägledning
Standardformat	CycloneDX, SPDX	CycloneDX kryptografitillägg (ECMA-424)
svar	"Vilken programvara kör jag?"	"Vilken kryptografi använder den programvaran, och är den kvantsäker?"

Vad bör en CBOM-inventering innehålla? 

En komplett CBOM utökar en standard SBOM-inventering (operativsystem, webb-/applikationsservrar, SSL/TLS-bibliotek som OpenSSL, konfigurations- och logghanteringsverktyg) med de specifika kryptografiska detaljer som dessa komponenter är beroende av. I praktiken innebär det att man samlar in sex kategorier av tillgångar.

Kategori	Exempel	Varför det spelar roll
Algoritmer	RSA, ECDSA, AES, SHA-2/SHA-3	Identifierar vilka algoritmer som är kvantsårbara kontra kvantsäkra
Nycklar	Nyckelstorlek, typ, förvaringsplats	Flaggar för underdimensionerat eller felaktigt förvarat nyckelmaterial
Certifieringar	X.509 certifikat, utgångsdatum	Avslöjar utgångna eller svagt signerade certifikat innan de orsakar ett avbrott
Protokoll	TLS / SSL versioner, SSH, VPN-konfigurationer	Avslöjar föråldrade protokollversioner som fortfarande är i produktion
Bibliotek och moduler	OpenSSL, BoringSSL, språkbaserade kryptobibliotek	Kopplar kända CVE:er direkt till de system som använder dem
hårdvara	HSM, IoT och inbyggda enheter	Utökar insynen bortom programvara till hårdvaran som förankrar förtroendet

Bygga ett kryptografiskt styrningsramverk kring din CBOM

En CBOM är bara så användbar som det styrningsprogram som är byggt ovanpå den. När du kan se varje algoritm, nyckel och certifikat i din miljö är nästa steg att bestämma vad du ska göra med var och en: hur du klassificerar den, om du ska kryptera eller tokenisera data bakom den, vem som kan komma åt den, hur dess livscykel hanteras, hur du återställer om den misslyckas, hur du övervakar den framöver och hur den mappas till de efterlevnadsramverk du lyder under.

Klassificera kryptografiska tillgångar efter risk

Inte varje post i en CBOM har samma brådska. Klassificering innebär att poängsätta varje algoritm och nyckel utifrån dess status som kvantumsårbarhet och känsligheten eller lagringsperioden för de data den skyddar, så att du kan prioritera migrering istället för att behandla en inventering med 5 000 rader som en platt att-göra-lista.

Algoritm eller nyckeltyp	NIST IR 8547 utkaststatus	Rekommenderad åtgärd
RSA-2048, ECC P-256 (~112-bitars säkerhet)	Föreslagen utfasning efter 2030	Planera migreringen nu; prioritera data med lång konfidentialitetstid
RSA-3072, ECC P-384 (varianter med högre hållfasthet)	Föreslagen ogiltigförklarad efter 2035	Migrera före 2035; högre nyckelstorlekar köper tid, inte undantag
ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Färdigställda NIST-standarder, augusti 2024	Målalgoritmer för nya implementeringar och migrering
AES-256, SHA-2, SHA-3	Inte på IR 8547:s utfasningsschema för offentliga nycklar	Ingen påtvingad migrering; fortsätt att verifiera viktiga hanteringspraxis

NIST IR 8547 är fortfarande ett första offentligt utkast från och med mitten av 2026, så betrakta dessa datum som färdriktningen snarare än en slutgiltig regel. Med detta sagt omvandlar Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks", undertecknad den 22 juni 2026, och OMB Memorandum M-26-15, utfärdad den 24 juni 2026, redan IR 8547:s 2030-horisont till en bindande femfasig migreringstidlinje för federala tillgångar med högt värde och system med stor påverkan, med migreringsplaner för myndigheter som ska vara klara i oktober 2026. Ordern definierar till och med en ny roll som "PQC-migreringsledare" som uttryckligen ansvarar för myndighetsomfattande hantering av kryptografisk inventarier, vilket är precis vad en CBOM finns för att stödja.

Välj mellan kryptering och tokenisering

Din CBOM visar var känsliga data skär en given algoritm, vilket är precis den information du behöver för att välja rätt kontroll. Använd kryptering när applikationen behöver återställa det ursprungliga värdet eller när data flyttas mellan system som du inte helt kontrollerar. Använd tokenisering när du vill ta bort känsliga värden (betalkortsnummer är det klassiska fallet) från ett system helt och minska systemets efterlevnadsomfattning, eftersom en token inte har någon matematisk relation till det ursprungliga värdet och inte kan återställas utan det separata valv som utfärdade den.

Tillämpa åtkomstkontroller på nycklar och certifikat

Varje nyckel och certifikat som din CBOM avslöjar behöver en ägare och en åtkomstpolicy. Det innebär rollseparation mellan de personer som begär nycklar och de personer som godkänner eller utfärdar dem, lagring i en hårdvarusäkerhetsmodul istället för platta filer eller källkod, och schemalagd rotation av autentiseringsuppgifter istället för nycklar som förblir oförändrade i åratal. En CBOM utan åtkomststyrning dokumenterar bara problemet; den åtgärdar det inte.

Styr den kryptografiska tillgångens livscykel

Varje post i en CBOM går igenom en livscykel: utfärdande, rotation, förnyelse, återkallelse och pensionering. Styrning innebär att definiera vem som utlöser varje steg och hur det registreras, så att ett utgånget certifikat eller en algoritm som är planerad för utfasning får schemalagt arbete istället för att visas som ett avbrott.

Planera återställning innan du behöver den

En CBOM identifierar vilka nycklar och certifikatutfärdare som är bärande för ditt företag, vilket är precis den lista du behöver för katastrofåterställningsplanering. Det innebär nyckelförvaring och säkerhetskopieringsprocedurer för krypteringsnycklar, en dokumenterad återställningsväg för en komprometterad eller otillgänglig certifikatutfärdare och regelbunden återställningstestning, inte bara en säkerhetskopia som aldrig har återställts.

Övervaka kontinuerligt, inte bara vid revisionstillfället

En CBOM som genereras en gång om året är inaktuell den dag ett nytt beroende skickas. Kontinuerlig övervakning innebär att man skannar om varje version eller distribution, varnar när certifikatet löper ut innan det orsakar driftstopp och flaggar avvikelser när ny kod introducerar en algoritm eller nyckelstorlek som faller utanför din godkända baslinje.

Kartlägg resultat till efterlevnadskrav

En aktuell CBOM är direkt bevis för de kryptografirelaterade kontrollerna i PCI DSS, HIPAA, GDPR och ISO/IEC 27001 bilaga A, och den blir snabbt relevant även för EU-specifika skyldigheter: EU:s Cyber ​​Resilience Act och DORA ökar båda trycket på verifierbar, fullstack-insyn i den kryptografi som är inbäddad i produkter och system inom finanssektorn. Genom att mappa varje CBOM-post till den specifika kontroll den uppfyller förvandlas ett inventeringsblad till revisionsbevis.

Hur man bygger en CBOM: En process i fyra steg

Att bygga en CBOM är en iterativ process, inte en enda skanning. Dessa fyra steg täcker identifiering genom automatisering.

1. Upptäck de kryptografiska enheterna:

   Identifiera kryptografiska enheter i ditt system: tredjepartsapplikationer (databaser, konfigurationshantering och automatiseringsverktyg), källkod, data i vila (konfigurationsfiler, digitala certifikat , lösenord och nycklar), data i rörelse ( SSL/TLS- protokoll och VPN-konfigurationer) och hårdvara ( HSM:er och IoT-enheter).

2. Generera och underhåll lagret:

   Bestäm när du ska generera inventering i varje steg av utveckling och driftsättning. Varje steg bör komplettera det föregående och bevara länken mellan var en komponent introducerades och var den används, så att du kan spåra och åtgärda sårbarheter. Olika intressenter behöver olika omfattning: ett produktteam bryr sig vanligtvis om källkod, beroenden och applikationskonfiguration, medan IT-drift behöver en bredare överblick som omfattar programvara, PKI , SaaS, nätverk, data och hårdvara.

3. Revidera och granska regelbundet:

   Schemalägg regelbundna granskningar för att bekräfta att kryptografiska enheter fortfarande uppfyller gällande säkerhetsstandarder och för att upptäcka allt som har avvikit: sårbara nyckelstorlekar, svaga algoritmer, certifikat som behöver förnyas eller återkallas.

4. Automatisera och integrera i CI/CD:

   Manuella, punkt-i-tid-skanningar skalar inte bortom ett fåtal databaser. Verktyg med öppen källkod byggda på CycloneDX CBOM-schemat, tillsammans med kommersiella skannrar, kan automatiskt extrahera kryptografisk metadata från källkod, containrar och infrastruktur-som-kod-mallar. Genom att koppla CBOM-generering till din CI/CD-pipeline förvandlas den från en årlig revisionsövning till en live, versionsbaserad artefakt.

Hur förbättrar CBOM er säkerhetsställning? 

En CBOM ger din organisation detaljerad inblick i de kryptografiska tillgångar som är kopplade till varje kommersiell och öppen källkodskomponent du kör, vilket förbättrar din säkerhetsställning på tre konkreta sätt. För det första stärker den kryptoagiliteten: du kan vidta proaktiva åtgärder mot attacker i leveranskedjan och reagera snabbare när en inträffar, eftersom du redan vet vilka komponenter som påverkas. För det andra minskar den de operativa och ekonomiska konsekvenserna av ett intrång; utan en CBOM är det långsamt och manuellt att identifiera varje exponerad tillgång efter en incident, och den förseningen är dyr. För det tredje stöder en uppdaterad CBOM-inventering direkt anpassning till regelverk som NIST-vägledning, ISO 27001 och GDPR.

Eftersom en CBOM ger dig en detaljerad bild av dina kryptografiska tillgångar, är den också planeringsunderlaget för migrering från kvantsårbara algoritmer som RSA , DSA, ECDSA och ECDH till de NIST-standardiserade postkvantalgoritmerna: ML-KEM (FIPS 203), ML-DSA (FIPS 204) och SLH-DSA (FIPS 205), alla slutförda i augusti 2024. Du kan inte sekvensera en migrering som du inte kan se, och en CBOM är det som gör den sekvenseringen möjlig.

Vilka är begränsningarna med en CBOM? 

En CBOM är ett nödvändigt verktyg, inte en komplett lösning, och det är värt att gå in med klara ögon om var den brister.

• Namngivningstvetydighet: Olika skanningsverktyg kan rapportera samma algoritm under olika namn eller parametergrupperingar, vilket komplicerar jämförelser mellan verktyg.
• Konfigurationsdriven kryptografi: Chiffersviter och algoritmval som väljs vid körning, eller genom konfiguration snarare än kod, är svårare att upptäcka enbart genom statisk analys.
• Tillhandahållande kontra konsumtion: En CBOM behöver skilja mellan en komponent som implementerar kryptografi och en som bara anropar ett annat biblioteks implementering, och den skillnaden är inte alltid uppenbar från källkoden.
• Täckningsbrister: Kompilerade binärfiler, firmware och äldre system utan källkodsåtkomst är svårare att skanna än moderna, källkodstillgängliga applikationer.
• Problemet med ögonblicksbilden: En CBOM är bara korrekt från det ögonblick den genererades. Utan kontinuerlig skanning blir den inaktuell lika snabbt som din nästa driftsättning.

Ett verkligt exempel: Migrera en äldre certifikatutfärdare

Så här passar delarna ovan ihop i praktiken. En CBOM-skanning av en intern certifikatutfärdare visar flera tusen aktiva certifikat som fortfarande är utfärdade med 2048-bitars RSA-nycklar. Genom att jämföra detta fynd mot klassificeringstabellen ovan markeras RSA-2048 som föreslaget för utfasning efter 2030 enligt NIST:s utkast till IR 8547-tidslinje, så säkerhetsteamet tilldelar det en migreringsprioritet baserat på hur länge varje certifikats skyddade data behöver förbli konfidentiella. Certifikat kopplade till långlivade data (signerad firmware, arkivposter) schemaläggs först; kortlivade, ofta roterade certifikat schemaläggs sist. Teamet använder sedan en PKI-as-a-Service-plattform för att utfärda hybridcertifikat som parar ihop den befintliga RSA-signaturen med en ML-DSA-signatur, så att förlitande parter som ännu inte stöder post-kvantumalgoritmer fortsätter att fungera under övergången. CBOM skannas om efter varje migreringsvåg för att bekräfta att antalet RSA-2048 faktiskt minskar, snarare än att anta att planen är enligt plan.

Hur kan krypteringskonsulting hjälpa? 

CBOM Secure är Encryption Consultings plattform för kryptografisk upptäckt och inventering. Den skannar din miljö efter algoritmer, nycklar, certifikat och protokoll, bygger en CycloneDX-baserad CBOM och lyfter fram svag eller kvantumsårbar kryptografi så att ditt team kan prioritera migrering med bevis istället för gissningar.

När er CBOM är byggd omvandlar Encryption Consultings PQC Advisory Services den inventeringen till en sekvenserad migreringsfärdplan: en detaljerad riskbedömning av era lokala, moln- och SaaS-miljöer, en strategi och färdplan för att minska den kvantumsårbara kryptografin som CBOM uppvisar, och praktiskt stöd vid implementering av de tekniker och processer som leder er till en kvantumsäker miljö. Stöds av ISO/IEC 27001:2022- och SOC 2-certifierade metoder.

För relaterad läsning, se hur ett kryptografiskt inventeringssystem matar en bredare kryptoagilitetsstrategi , vad köpare bör leta efter i post-kvantumklar PKI-as-a-Service och var CBOM passar in i Encryption Consultings femnivås PQC-mognadsmodell.

Slutsats

Att identifiera och hantera din organisations programvaru- och kryptografiska tillgångar genom SBOM respektive CBOM är grunden för att försvara sig mot både programvaruleveranskedjans och kryptografiska attacker. En CBOM som byggs en gång och lämnas orörlig är bara marginellt bättre än ingen CBOM alls; värdet kommer från att para ihop den med klassificering, åtkomstkontroller, livscykelstyrning, återställningsplanering, kontinuerlig övervakning och efterlevnadskartläggning, och sedan hålla den aktuell när dina system förändras och deadlines efter kvantmigreringen närmar sig.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan en CBOM och en SBOM?

En SBOM (Software Bill of Materials) listar programvarukomponenter, bibliotek och beroenden i en applikation, tillsammans med metadata som version och licens. En CBOM (Cryptographic Bill of Materials) listar de kryptografiska tillgångar som dessa komponenter använder: algoritmer, nyckelstorlekar, certifikat och protokoll. NIST behandlar CBOM som en förlängning av SBOM-praxis specifikt för planering av migrering av kryptografi efter kvantumkryptografi.

Vilket format ska en CBOM använda?

Det dominerande formatet är OWASP CycloneDX, som lade till inbyggt stöd för kryptografiska tillgångar i version 1.6 och nu publiceras som ECMA-424-standarden. Genom att använda ett standardformat snarare än ett proprietärt kalkylblad fungerar din CBOM med det växande ekosystemet av öppen källkod och kommersiella CycloneDX-verktyg.

Vem ansvarar för att upprätthålla en CBOM inom en organisation?

Ansvaret delas vanligtvis upp efter omfattning: produkt- och applikationssäkerhetsteam äger CBOM för källkod och applikationsberoenden, medan IT-drift eller en dedikerad kryptografisk styrningsfunktion äger det bredare lagret över PKI, nätverk, moln och hårdvara. Federala myndigheter formaliserar nu detta under Executive Order 14412, som skapade en namngiven PQC-migreringsledande roll med ansvar för myndighetsomfattande hantering av kryptografisk lagerhantering.

Hur stöder en CBOM migrering efter kvantkryptografi?

En CBOM identifierar exakt var kvantumsårbara algoritmer som RSA och ECDSA används, vilket låter dig prioritera migrering efter datakänslighet och lagringsperiod istället för att migrera system i en godtycklig ordning. Den prioriteringen är det som gör det möjligt att uppfylla tidslinjer som NIST:s utkast till avveckling 2030 och 2035 förbudsdatum för klassiska algoritmer med offentlig nyckel.

Kan en CBOM automatiseras, eller kräver den manuella granskningar?

Båda. Automatiserade verktyg byggda på CycloneDX CBOM-schemat kan extrahera kryptografisk metadata från källkod, containrar och infrastruktur-som-kod-mallar som en del av en CI/CD-pipeline, vilket håller inventariet aktuellt. Regelbundna manuella granskningar är fortfarande viktiga för att fånga konfigurationsdriven kryptografi och äldre system som automatiserade skannrar inte helt kan nå.