Varje CRA-tillverkare behöver en levande sårbarhetshantering för varje produkt: veta vad produkten innehåller, hitta och åtgärda sårbarheter, testa regelbundet, publicera advisories, ta emot externa rapporter och leverera säkerhetsuppdateringar säkert och kostnadsfritt. Den här sidan förklarar den operativa modellen och var den övergår till brådskande regulatorisk rapportering.
Sammanfattning
- Sårbarhetshantering är en teknisk operativ modell som varje CRA-tillverkare behöver för varje produkt med digitala element.
- Åtta numrerade skyldigheter: identifiera (med SBOM), åtgärda utan dröjsmål, testa regelbundet, offentliggöra åtgärdade sårbarheter, tillämpa en CVD-policy, underlätta sårbarhetsrapportering, distribuera uppdateringar säkert, leverera säkerhetsuppdateringar kostnadsfritt.
- Kostnadsfritt är icke förhandlingsbart: säkerhetsuppdateringar är kostnadsfria som utgångspunkt, med ett smalt undantag för skräddarsydda produkter till företagsanvändare.
- CVD-policyn är obligatorisk, inte valfri: samordnad sårbarhetsredovisning är en del av CE-märkningsberedskapen, inte en frivillig best practice.
- Sårbarhetshantering löper under hela supportperioden; minimum är fem år från det att produkten släpps på marknaden, om inte den förväntade användningstiden är kortare och redovisad.
- Sårbarhetshantering är inte brådskande regulatorisk rapportering: hantering är den dagliga tekniska processen; rapportering startar endast vid aktiv exploatering eller allvarliga incidenter.
De fyra hållpunkterna för CRA-sårbarhetshantering: omfattning, varaktighet, uppdateringskostnad och gränsen mot brådskande rapportering.
De åtta skyldigheterna för sårbarhetshantering
CRA behandlar inte sårbarhetshantering som en engångschecklista. Den förväntar sig en kontinuerlig livscykel som löper under hela supportperioden, från komponentinventering till åtgärd, offentliggörande och säker uppdateringsleverans. Tabellen grupperar de åtta skyldigheterna efter den operativa fas där var och en normalt löper.
| Fas | Led | Vad det omfattar | Operativt fokus |
|---|---|---|---|
| Detektera och katalogiseraIntag och inventering | Led 1 och 6 | SBOM-baserad identifiering av komponenter och kända sårbarheter, plus en offentlig rapporteringskanal. | Håll komponentdata aktuella och gör det enkelt för externa rapportörer att nå produktsäkerhetsteamet. |
| Utveckla och åtgärdaÅtgärd och testning | Led 2 och 3 | Åtgärd utan dröjsmål och effektiv regelbunden testning av kodbasen och beroenden. | Använd allvarlighetsgrad för att sätta brådska och bevara sedan bevis för att åtgärder och tester skedde i tid. |
| DistribueraSäker uppdateringskanal | Led 7 och 8 | Signerade, autentiserade säkerhetsuppdateringar, separerbara från funktioner och kostnadsfria utom för skräddarsydda B2B-produkter. | Leverera säkerhetsfixar utan att tvinga användare till funktionsuppgraderingar eller betalda underhållsnivåer. |
| Samordna och offentliggöraCVD och advisories | Led 4 och 5 | En tillämpad policy för samordnad sårbarhetsredovisning och offentliga advisories när en fix finns tillgänglig. | Samordna forskarintag, användaravisering och motiverade offentliggörandefördröjningar från en playbook. |
Vad varje skyldighet innebär i praktiken
| # | Skyldighet | Vad den faktiskt kräver |
|---|---|---|
| 1 | Identifiera och dokumentera sårbarheter och komponenter | En SBOM i CycloneDX eller SPDX, som täcker minst beroenden på toppnivå. SBOM:en är det index som gör CVE-matchning möjlig: du kan inte åtgärda det du inte har katalogiserat. |
| 2 | Åtgärda utan dröjsmål, separat från funktioner | Ingen fast SLA; den förväntade hastigheten anpassas efter allvarlighetsgrad. Säkerhetsgrenar måste kunna separeras från funktionsgrenar så att användarna inte kan skjuta upp en patch genom att skjuta upp en release. |
| 3 | Effektiv och regelbunden testning | Statisk analys, dynamisk testning, beroendeskanning mot sårbarhetsflöden och penetrationstestning. "Regelbundet" måste matcha risken och kodbasens förändringstakt. |
| 4 | Offentligt offentliggörande av åtgärdade sårbarheter | När en korrigering levereras, publicera beskrivning, berörd produkt, påverkan, allvarlighetsgrad och åtgärd. Fördröj endast "i vederbörligen motiverade fall" tills användarna kan patcha. CVE plus CSAF är de facto-bäraren. |
| 5 | Policy för samordnad sårbarhetsredovisning | En skriftlig, tillämpad CVD-policy med mottagningskanal, svars-SLA och redovisningsvillkor. ISO/IEC 29147 och 30111 ger en formell ram. |
| 6 | Underlätta extern sårbarhetsrapportering | En kontaktadress för rapportering av problem i produkten och dess tredjepartskomponenter. security.txt enligt RFC 9116 uppfyller kanalkravet. |
| 7 | Säker distribution av uppdateringar | Signerade, autentiserade uppdateringar, automatiska där så är tillämpligt. Produkter utan en uppdateringskanal måste bygga en eller dokumentera varför automatisering inte är tillämplig. Se säkerhetsuppdateringar. |
| 8 | Kostnadsfritt, med advisorymeddelanden | Säkerhetsuppdateringar måste spridas utan dröjsmål och kostnadsfritt (enda undantag: skräddarsydda produkter till företagsanvändare där parterna kommit överens om annat). Varje uppdatering måste innehålla ett advisorymeddelande som beskriver problemet och den åtgärd användaren behöver vidta. En grind med betald support, eller en tyst patch utan advisory, bryter mot led 8. |
Sårbarhetshantering och supportperioden
Sårbarhetshantering löper under hela supportperioden. Standardminimum är fem år från det datum då produkten släpps på EU-marknaden, om inte den förväntade användningstiden är kortare och redovisad. Supportperiodens slutdatum måste anges i produktinformationen. När perioden löper ut upphör de aktiva hanteringsskyldigheterna för den produktversionen, men den tekniska dokumentationen och EU-försäkran om överensstämmelse måste fortfarande bevaras i 10 år efter utsläppandet på marknaden eller under supportperioden, beroende på vilken period som är längst. Se CRA supportperiod.
Sårbarhetshantering är inte brådskande rapportering
CRA skiljer mellan två skyldigheter som verkar på olika ytor och med olika mottagare:
- Sårbarhetshantering är den tekniska processen: SBOM, åtgärd, CVD-policy, offentligt offentliggörande och säkra uppdateringar. Den gäller alla sårbarheter under hela supportperioden och ligger hos tillverkarens produktsäkerhetsorganisation.
- Brådskande regulatorisk rapportering startar endast när det finns en aktivt utnyttjad sårbarhet eller en allvarlig incident som påverkar produktens säkerhet. Den lämnas genom ENISA Single Reporting Platform i en kadens om 24h / 72h, plus en slutrapport (14 dagar efter att en korrigerande eller mildrande åtgärd finns tillgänglig för en aktivt utnyttjad sårbarhet, eller en månad efter 72-timmarsanmälan vid en allvarlig incident), till ENISA och den CSIRT som utsetts som koordinator. För SRP-onboardingmekanik, se ENISA SRP-onboarding.
Ett produktteam kan driva en regelefterlevande sårbarhetshantering utan att någonsin lämna en brådskande rapport, eftersom de flesta sårbarheter åtgärdas innan de aktivt utnyttjas. Rapportering startar först när åtgärden ännu inte hunnit ikapp aktiv exploatering eller en allvarlig incident. Se CRA sårbarhetsrapportering.
Sanktionsrisk
Brister i sårbarhetshantering kan medföra betydande administrativa böter, men den detaljerade nivåindelningen hör hemma i den särskilda handhävningsguiden. Se CRA-böter och handhävning för bötesnivåer, handhävningstriggers och hur brister i sårbarhetshantering passar in i den bredare sanktionsmodellen.
Vanliga frågor
Måste SBOM:en täcka transitiva beroenden?
Den regulatoriska lägstanivån är beroenden på toppnivå, men en praktisk SBOM bör normalt gå djupare. Du kan inte åtgärda en CVE i en transitiv komponent utan dröjsmål om du aldrig har katalogiserat den komponenten. De flesta tillsynsmyndigheter och kunder förväntar sig en djup SBOM som följer BSI TR-03183 eller motsvarande vägledning. CycloneDX och SPDX kvalificerar båda som allmänt använda och maskinläsbara format. Se CRA SBOM-krav.
Vad innebär "utan dröjsmål" i praktiken för åtgärd enligt led 2?
CRA anger ingen fast åtgärds-SLA. "Utan dröjsmål" anpassas efter cybersäkerhetsrisken: en kritisk sårbarhet med aktiv exploatering i det vilda kräver en korrigering på dagar, medan ett problem med låg allvarlighetsgrad kan vänta till nästa ordinarie cykel. Allvarlighetsgrad fastställs med CVSS, skärps med EPSS exploateringssannolikhetsdata och bekräftas med bevis från CISA KEV-katalogen där sårbarheten finns på CISA:s lista över aktivt utnyttjade. Se allvarlighetsgradering för den operativa stegen marknadsmyndigheterna tillämpar när de bedömer om en tillverkare åtgärdat "utan dröjsmål".
Kan säkerhetsuppdateringar avgiftsbeläggas under några omständigheter?
Endast ett undantag finns: skräddarsydda produkter som levereras till en företagsanvändare kan använda ett betalt arrangemang där tillverkaren och företagsanvändaren har kommit överens om annat. För alla andra produkter, inklusive alla konsumentprodukter och standard-B2B SaaS eller hårdvara, måste säkerhetsuppdateringar vara kostnadsfria under hela supportperioden. Att lägga en säkerhetspatch bakom en betald supportnivå utsätter tillverkaren för den högsta sanktionsrisken.
Fortsätter skyldigheterna för sårbarhetshantering efter supportperioden?
Nej. De åtta skyldigheterna för sårbarhetshantering upphör för den produktversionen när supportperioden löper ut. Nya sårbarheter som upptäcks efter end-of-support behöver inte åtgärdas för den versionen, förutsatt att tillverkaren publicerat ett tydligt end-of-support-datum så att användarna kan migrera. Två skyldigheter fortsätter oavsett. Den tekniska dokumentationen och EU-försäkran om överensstämmelse måste fortfarande bevaras i 10 år efter utsläppandet på marknaden eller under supportperioden, beroende på vilken period som är längst. Rapportering är skild från hantering: om tillverkaren får kännedom om en aktivt utnyttjad sårbarhet eller en allvarlig incident i produkten kan rapporteringsskyldigheten enligt artikel 14 fortfarande gälla, eftersom den inte är knuten till supportperioden. Se supportperiod och end-of-support-redovisning.
När kräver en CVD-mottagning brådskande rapportering?
Utlösaren är aktiv exploatering, inte en privat rapport eller ett bevis på exploaterbarhet. En fungerande proof-of-concept bifogad till en CVD-rapport kräver inte i sig rapportering; den gör det när det finns rimlig övertygelse om att en angripare har använt bristen mot ett verkligt mål. När den tröskeln passeras startar 24-timmars tidig varning till ENISA och koordinator-CSIRT, följd av 72-timmarsanmälan och en slutrapport inom 14 dagar från att en korrigerande åtgärd blivit tillgänglig. Se CRA sårbarhetsrapportering.