CRA-leverantörs due diligence: frågelista och varningssignaler

Due diligence för komponenter är en tillverkarskyldighet enligt artikel 13.5 i cyberresiliensförordningen. Den fullständiga ordagranna texten:

"För att uppfylla kraven i punkt 1 ska tillverkarna visa tillbörlig aktsamhet när de integrerar komponenter som kommer från tredje part så att dessa komponenter inte komprometterar cybersäkerheten för produkten med digitala element, inbegripet vid integrering av komponenter i programvara med fri och öppen källkod som inte har tillhandahållits på marknaden i samband med kommersiell verksamhet."

Den här sidan är den operativa följeslagaren till tillverkarens skyldighetsuppsättning. Regelverkets ramar, rollgränserna och importörens kontroller ligger i klusterguiderna: tillverkare, importör, distributör och vem som måste följa förordningen. Det som följer är frågelistan, de leverantörstyp-playbooks som klustersidorna inte täcker (FOSS, moln, ren hårdvara, OSS-förvaltare, modifierad COTS-firmware) och de operativa scenarier som faktiskt drabbar team i den verkliga inköpsvardagen (tyst leverantör, delade uppströmskomponenter, eftersläpningar efter företagsförvärv, synlighet bortom första nivån).

Därför är leverantörsdue diligence viktigt

Även som tillverkare av din egen produkt innehåller din leverans komponenter från andra leverantörer: tredjepartsbibliotek i programvara, hårdvarukomponenter, firmware-moduler, molntjänster. Sårbarheter i de komponenterna blir dina sårbarheter, och din bedömning av överensstämmelse måste ta hänsyn till risker i leverantörskedjan.

Artikel 13.5 gör den bedömningen explicit. CRA föreskriver inte något frågelisteformat, men en skriftlig frågelista är det praktiska sättet att dokumentera att du kontrollerade komponentsäkerhet, sårbarhetshantering, SBOM-tillgång, stödåtaganden och leverantörens svarsvägar före integrationen. Utan daterade anteckningar har du ingen historia att berätta för en marknadskontrollmyndighet om hur risken på komponentnivå hanterades.

Om din roll för en viss produkt också är importör (du för in en icke-EU-tillverkares produkt till EU) är de fyra importörskontrollerna före marknadssläpp en separat verifieringsuppgift. Den här guiden håller sig till tillverkarens komponent-due diligence.

Ramverk för due diligence

Nivåindelat angreppssätt

Inte alla leverantörer kräver samma granskningsnivå:

LEVERANTÖRSNIVÅ-BEDÖMNING

NIVÅ 1 (Kritisk):
- Komponenter med säkerhetsfunktioner (krypto, autentisering, brandvägg)
- Centrala programvaruberoenden
- Hårdvara med firmware
Bedömning: Fullständig frågelista + dokumentationsgranskning + löpande övervakning

NIVÅ 2 (Betydande):
- Komponenter för huvudfunktionalitet
- Nätverksanslutna element
- Komponenter för databehandling
Bedömning: Standardfrågelista + dokumentationsgranskning

NIVÅ 3 (Standard):
- Icke-säkerhetskomponenter
- Hjälpbibliotek
- Perifer hårdvara
Bedömning: Grundläggande frågelista + stickprov

NIVÅ 4 (Minimal):
- Standardkomponenter
- Väletablerad OSS
- Icke-ansluten hårdvara
Bedömning: Grundläggande verifiering + SBOM-inkludering

Bedömningsområden

Din due diligence bör täcka:

Ramverket är generellt, men det bevis varje leverantörstyp faktiskt kan producera varierar. De följande fem avsnitten går igenom de vanligaste leverantörsformerna och den due diligence-väg som passar var och en.

FOSS-specifik leverantörsdue diligence

Artikel 13.5 namnger FOSS-komponenter uttryckligen: komponenter i programvara med fri och öppen källkod som inte har tillhandahållits på marknaden i samband med kommersiell verksamhet. Den rättsliga plikten gäller oavsett om pengar byter ägare eller inte. En blod-undertecknad frågelista från en kommersiell leverantör är inte modellen när uppströms är ett GitHub-projekt med tre underhållare.

För icke-kommersiella FOSS-komponenter förskjuts bevisuppsättningen från leverantörsintygade dokument till projektobserverbara signaler som du själv kan samla in.

CHECKLISTA FÖR FOSS-KOMPONENT-DUE DILIGENCE

PROJEKTHÄLSA:
[ ] Aktiva commits de senaste 90 dagarna
[ ] Antal distinkta bidragsgivare (>1 = avlastad bus-faktor)
[ ] Releaserytm angiven eller observerbar
[ ] Issue tracker svarar (median för tid till första kommentar)

SÄKERHETSLÄGE:
[ ] SECURITY.md finns med disclosure-adress
[ ] CVD-policy (privat säkerhetsrådgivningskanal, inte bara en issue)
[ ] CVE-historik granskad (NVD, GitHub Security Advisories, OSV)
[ ] Beståndsdelarna i SBOM är själva igenkännbara, inte djupa forkar

LICENS OCH HÄRKOMST:
[ ] SPDX-identifierare matchar det paketmetadata uppger
[ ] Inget licensinkompatibelt transitivt beroende
[ ] Släppta artefakter har verifierbar härkomst (t.ex. SLSA, sigstore)

DIN RESERVPLAN:
[ ] Fork-mål identifierat om uppströms tystnar
[ ] Intern kapacitet att patcha deklarerad (vilken ingenjör, vilken kod)
[ ] Ersättningskandidater listade, med uppskattad utbytesinsats

Två operativa regler. För det första kräver artikel 13.6 att sårbarheter du hittar i en FOSS-komponent rapporteras till uppströmsprojektet och att eventuell fix du tar fram delas tillbaka, i maskinläsbart format när så är lämpligt. Det frågelisteobjekt du kontrollerar är inte uppströmmens åtagande mot dig, det är ditt eget åtagande att flöda sårbarheter och patchar bakåt. För det andra släcker en tyst uppströms inte din plikt. Om projektet blir inaktivt är din reservplan (fork, intern patchning, ersättning) en del av due diligence-anteckningen, inte ett framtida problem.

För projekt som upprätthålls av en stiftelse eller juridisk enhet som agerar som förvaltare av programvara med öppen källkod ändras mönstret för due diligence igen. Det fallet ligger i nästa avsnitt.

OSS-förvaltare jämfört med kommersiell leverantör

En liten men viktig klass av uppströms drivs av en förvaltare av programvara med öppen källkod: en juridisk enhet, vanligen en stiftelse, vars kärnsyfte är att upprätthålla specifika projekt med öppen källkod avsedda för kommersiell användning. Linux Foundation, Eclipse Foundation och Apache Software Foundation är typexempel. Förvaltare ligger under artikel 24, inte artikel 13. Skyldighetsuppsättningen är smalare (en dokumenterad cybersäkerhetspolicy, en samarbetsplikt med marknadskontrollen, partiell tillämpning av artikel 14 om incidentrapportering), och förvaltaren är inte tillverkare av någon kommersiell produkt nedströms.

För gränsen tillverkare-mot-förvaltare, se förvaltare av öppen källkod.

Konsekvensen för due diligence för dig som nedströms integratör är att frågelistans form skiljer sig åt.

Det du fortsätter göra: kontroller av projekthälsa, intag av SBOM, CVE-övervakning, din egen reservplan med fork och patch. Det du slutar förvänta dig: avtalade SLA:er för sårbarhetsnotiser, betalda stödnivåer, revisionsklausuler. Due diligence-anteckningen för en förvaltarunderhållen komponent är tunnare på leverantörspapper och tyngre på dina egna kontroller än för en kommersiell leverantör, och det är den juridiskt korrekta formen.

Due diligence för molntjänstkomponenter

När "komponenten" inuti din produkt är ett API eller en hanterad tjänst (en autentiserings-SaaS, en hanterad meddelandeförmedlare, en serverlös funktion, en molndatabas) ser bevismönstret återigen annorlunda ut. Det finns ingen försäkran om överensstämmelse, ingen SBOM, ingen källkod som du levererar. Det finns ett avtal, en portfölj av säkerhetsattesteringar och en modell för delat ansvar.

DUE DILIGENCE FÖR MOLNTJÄNSTKOMPONENT

SÄKERHETSATTESTERINGAR:
[ ] SOC 2 Type II-rapport (aktuell)
[ ] ISO/IEC 27001-certifikat (aktuellt, omfångskontroll)
[ ] ISO/IEC 27017 (molnspecifika kontroller) där relevant
[ ] ISO/IEC 27018 (PII i publikt moln) där personuppgifter ingår

OPERATIVT BEVIS:
[ ] Statussida med incidenthistorik och post-mortem
[ ] Publicerade RTO/RPO och senaste DR-testdatum
[ ] Lista över underbiträden och notisprocess för ändringar
[ ] Personuppgiftsbiträdesavtal med EU-datalokalisering, där tillämpligt

DELAT ANSVAR:
[ ] Leverantörens ansvarsomfattning dokumenterad
[ ] Ditt ansvarsomfång erkänt (konfiguration, identitet, hemligheter, nätverk)
[ ] Loggning och åtkomst till revisionsspår för ditt ansvarsomfång

CRA-NÄRLIGGANDE:
[ ] Väg för sårbarhetsrapportering för själva API:et
[ ] Tidsfrist för incidentnotis i avtalet (timmar, inte "skyndsamt")
[ ] Notisfönster för tjänsteavveckling (vanligen 12 månader)

CRA reglerar inte molnleverantören direkt när leverantören inte släpper en produkt med digitala element på marknaden. Din plikt enligt artikel 13.5 är att bevisa att molnberoendet inte komprometterar din produkts cybersäkerhet. Leveransen är attesteringsportföljen plus en skriftlig redovisning av delat ansvar, inte en CRA-formad frågelista.

Due diligence för ren hårdvara och ODM-leverantörer

När din kontraktstillverkare (ODM, EMS, OEM-liknande montör) skickar fysiska kort och firmwaren är din, levererar leverantören hårdvarusubstratet men inte säkerhetskuvertet. CRA placerar säkerhetskuvertet hos dig, den enhet som flashar och signerar den firmware som hamnar på kortet.

Frågelistan här är tunnare på programvarufrågor och tyngre på hårdvaruförtroende och integritet i leverantörskedjan.

DUE DILIGENCE FÖR REN HÅRDVARA / ODM

HÅRDVARUFÖRTROENDE:
[ ] BOM med kryptografiskt grundad komponentidentifiering
[ ] Kontroller mot förfalskade komponenter (revision av komponentinköp)
[ ] Källa till säkert element och metod för förprovisionering
[ ] Process och revisionsspår för fabriksnyckelinjektion

MONTERINGSINTEGRITET:
[ ] ISO 9001-kvalitetssystem på plats
[ ] Manipuleringsbevis applicerat under montering och transport
[ ] Lot- och serienummerspårning från fabrik till mottagningskaj

ÖVERLÄMNING AV FIRMWARE:
[ ] Vem signerar firmwaren: du, ODM:en eller båda
[ ] Provisioneringsläge vid första uppstart (fabriksinställningar, ägaröverföring)
[ ] Bootloader och secure boot-kedja, vem äger varje länk

EFTER LEVERANS:
[ ] EOL-notisfönster för hårdvaruplattformen
[ ] Åtagande om sista-tillfälle-att-köpa och dess längd
[ ] Tillgång till ersättningsdelar för den stödperiod du åtar dig

Ett vanligt operativt fel: att teckna en flerårig stödperiod med en ODM vars EOL-fönster för hårdvaran är 18 månader. CRA:s stödperiodklocka startar när du släpper produkten på EU-marknaden; om underliggande kisel når EOL inom det fönstret överförs inte stödskyldigheten till din kunds tolerans.

COTS-firmware som du modifierar

Om du tar en kommersiell standardprodukt, modifierar firmwaren och släpper resultatet på EU-marknaden behandlar artikel 22 dig som tillverkare av den modifierade produkten för den del som påverkas av den väsentliga ändringen, eller för hela produkten om ändringen rör cybersäkerhetskuvertet.

"En fysisk eller juridisk person, annan än tillverkaren, importören eller distributören, som utför en väsentlig ändring av en produkt med digitala element och tillhandahåller den produkten på marknaden ska anses som tillverkare vid tillämpningen av denna förordning."

Konsekvensen för due diligence är stor: den ursprungliga tillverkarens försäkran om överensstämmelse och bedömning av överensstämmelse täcker inte längre produkten i den form du släpper den på marknaden. Du ärver tillverkarens skyldighetsuppsättning för den berörda delen eller hela produkten. Den ursprungliga leverantören blir irrelevant för CRA-dokumentationen; din egen ingenjörsavdelning blir den svarande parten.

Due diligence-steget här är därför inte en frågelista till den ursprungliga leverantören. Det är en intern bedömning av modifikationens påverkan. Dokumentera modifikationens omfattning, avgör om den är väsentlig och behandla helheten som tillverkararbete om modifikationen rör autentisering, kryptering, nätverksyta eller uppdateringsmekanismen. En ren anteckning över vilken modifikation som applicerades på vilken enhetsbatch är den artefakt en marknadskontrollmyndighet kommer att fråga efter först.

Frågelistan

Använd den här frågelistan som utgångspunkt för kommersiella programvaru- och hårdvaruleverantörer. De tidigare avsnitten täcker varianterna för FOSS, OSS-förvaltare, moln-API:er, rena hårdvaru-ODM:er och modifierad COTS-firmware.

Avsnitt 1: Företagsinformation

FRÅGELISTA FÖR LEVERANTÖRSDUE DILIGENCE
Avsnitt 1: Företagsinformation

1.1 Företagsuppgifter
    Företagsnamn: _________________________________
    Säte: ________________________________
    Registreringsland: _____________________
    Primär kontakt: _____________________________
    Säkerhetskontakt: ____________________________

1.2 Affärsinformation
    Antal år i verksamhet: _______________________
    Antal anställda: _____________________________
    Årlig omsättning (intervall): ________________

1.3 EU-representation (om utanför EU)
    Tillverkarens representant namn + adress: ____
    (För full detalj om AR-kaskaden och importörens
    routing när inget EU-säte finns, se
    klusterguiden för importörer:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certifieringar (bifoga kopior)
    [ ] ISO 9001 (Kvalitetsledning)
    [ ] ISO 27001 (Informationssäkerhet)
    [ ] ISO 27701 (Integritet)
    [ ] SOC 2
    [ ] Annat: _________________________________

Avsnitt 2: Produktöverensstämmelse

Avsnitt 2: Produktöverensstämmelse

2.1 Produktidentifiering
    Produktnamn/modell: __________________________
    Version/revision: ___________________________
    Produktkategori: ___________________________

2.2 CRA-klassificering
    [ ] Standard
    [ ] Viktig klass I (bilaga III, del I)
    [ ] Viktig klass II (bilaga III, del II)
    [ ] Kritisk (bilaga IV)
    [ ] Ännu inte klassificerad

2.3 Bedömning av överensstämmelse
    [ ] Modul A (självbedömning)
    [ ] Modul B+C (EU-typkontroll)
    [ ] Modul H (fullständig kvalitetssäkring)
    [ ] Ännu inte slutförd

    Om modul B, C eller H:
    Anmält organs namn: __________________________
    Certifikatnummer: __________________________
    Certifikatdatum: ____________________________

2.4 EU-försäkran om överensstämmelse
    [ ] Försäkran tillgänglig (bifoga kopia)
    [ ] Försäkran ännu inte utfärdad
    Datum för försäkran: ________________________

2.5 CE-märkning
    [ ] CE-märkning applicerad
    [ ] CE-märkning ännu inte applicerad
    Om applicerad, var på produkten: _____________

2.6 Teknisk dokumentation
    [ ] Teknisk dokumentation tillgänglig på begäran
    [ ] SBOM tillgänglig (format: ________________)
    [ ] Riskbedömningsdokumentation tillgänglig
    [ ] Användar- och säkerhetsinstruktioner tillgängliga

Avsnitt 3: Säkerhetspraktik

Avsnitt 3: Säkerhetspraktik

3.1 Säker utveckling
    Följer ni en säker utvecklingslivscykel?
    [ ] Ja - beskriv: __________________________
    [ ] Nej

    Genomför ni säkerhetstestning?
    [ ] Statisk analys (SAST)
    [ ] Dynamisk analys (DAST)
    [ ] Penetrationstestning
    [ ] Fuzz-testning
    [ ] Annat: _________________________________

    Har ni en standard för säker kodning?
    [ ] Ja - vilken: ____________________________
    [ ] Nej

3.2 Komponenthantering
    Hur spårar ni tredjepartskomponenter?
    [ ] SBOM upprätthålls
    [ ] Verktyg för beroendespårning (namn: _________)
    [ ] Manuell spårning
    [ ] Inte systematiskt spårat

    Hur övervakar ni sårbarheter i beroenden?
    [ ] Automatiserad skanning (verktyg: _______________)
    [ ] Manuell CVE-övervakning
    [ ] Förlitar oss på leverantörens notiser
    [ ] Ingen systematisk övervakning

3.3 Säkerhetsarkitektur
    Beskriv produktens centrala säkerhetsfunktioner:
    _____________________________________________

    Vilka kryptografiska standarder används?
    _____________________________________________

    Hur är autentiseringen implementerad?
    _____________________________________________

    Hur skyddas data i vila och under transport?
    _____________________________________________

Avsnitt 4: Sårbarhetshantering

Avsnitt 4: Sårbarhetshantering

4.1 Sårbarhetsavslöjande
    Har ni en policy för samordnat avslöjande av sårbarheter?
    [ ] Ja - URL: ______________________________
    [ ] Nej

    Har ni en security.txt-fil?
    [ ] Ja - URL: ______________________________
    [ ] Nej

    Vilken är säkerhetskontaktens metod?
    [ ] E-post: __________________________________
    [ ] Webbformulär: _______________________________
    [ ] Bug bounty-plattform: ____________________
    [ ] Annat: _________________________________

4.2 Svarsåtaganden
    Vilken är er bekräftelsetid?
    [ ] Inom 24 timmar
    [ ] Inom 72 timmar
    [ ] Inom 7 dagar
    [ ] Inget åtagande

    Vilken är er typiska patchtid för:
    Kritiska sårbarheter: ___________________
    Höga sårbarheter: _______________________
    Medelhöga sårbarheter: _____________________

4.3 ENISA-rapportering
    Är ni redo för ENISA-rapportering (sept 2026)?
    [ ] Ja, process etablerad
    [ ] Pågående
    [ ] Nej
    [ ] Ej tillämpligt (inte tillverkare)

4.4 Historiska sårbarheter
    Hur många säkerhetssårbarheter rapporterades
    i produkten under de senaste 24 månaderna? ______

    Hur löstes de?
    [ ] Alla patchade inom angivna tider
    [ ] Vissa förseningar (förklara): __________________
    [ ] Vissa kvarstår opatchade (förklara): ________

Avsnitt 5: Uppdateringar och stöd

Avsnitt 5: Uppdateringar och stöd

5.1 Stödperiod
    Vilken är den åtagna stödperioden från
    marknadssläppet?
    [ ] 5 år (CRA-minimum)
    [ ] 7 år
    [ ] 10 år
    [ ] Annat: _________________________________
    [ ] Ej definierad

    När släpptes produkten första gången på EU-marknaden?
    Datum: ______________________________________

    När slutar stödperioden?
    Datum: ______________________________________

5.2 Uppdateringsmekanism
    Hur levereras säkerhetsuppdateringar?
    [ ] Automatiska uppdateringar (OTA)
    [ ] Manuell nedladdning från portal
    [ ] Fysiskt media
    [ ] Annat: _________________________________

    Är säkerhetsuppdateringar separata från funktionsuppdateringar?
    [ ] Ja
    [ ] Nej - paketerade ihop

    Kan användare skjuta upp eller hoppa över uppdateringar?
    [ ] Ja
    [ ] Nej - obligatoriska
    [ ] Konfigurerbart

5.3 Uppdateringsverifiering
    Är uppdateringarna signerade?
    [ ] Ja - metod: __________________________
    [ ] Nej

    Kan användare verifiera uppdateringens äkthet?
    [ ] Ja - hur: _____________________________
    [ ] Nej

5.4 Planering vid stödperiodens slut
    Har ni en dokumenterad EOL-process?
    [ ] Ja
    [ ] Nej

    Hur meddelas kunder om EOL?
    _____________________________________________

    Vad händer efter att stödperioden slutar?
    [ ] Produkten fortsätter fungera
    [ ] Produkten tappar funktionalitet
    [ ] Produkten kräver migrering

Avsnitt 6: Dokumentationskrav

Avsnitt 6: Dokumentationskrav

6.1 Tillgänglig dokumentation
    Markera all dokumentation ni kan leverera:

    [ ] EU-försäkran om överensstämmelse
    [ ] Teknisk dokumentation (eller relevanta utdrag)
    [ ] Software Bill of Materials (SBOM)
        Format: [ ] CycloneDX [ ] SPDX [ ] Annat
    [ ] Sammanfattning av riskbedömning
    [ ] Dokument om säkerhetsarkitektur
    [ ] Användarinstruktioner (säkerhetsrelevanta)
    [ ] Policy för sårbarhetsavslöjande
    [ ] Villkor för stöd och underhåll

6.2 Leverans av dokumentation
    Hur kommer dokumentationen att tillhandahållas?
    [ ] På begäran (svarstid: ____________)
    [ ] Via säker portal
    [ ] Paketerad med produkten
    [ ] Annat: _________________________________

6.3 SBOM-detaljer (om tillgänglig)
    SBOM täcker:
    [ ] Endast direkta beroenden
    [ ] Transitiva beroenden inkluderade
    [ ] Hårdvarukomponenter (i tillämpliga fall)

    SBOM-uppdateringsfrekvens:
    [ ] Per release
    [ ] På begäran
    [ ] Inte systematiskt uppdaterad

Avsnitt 7: Avtalsåtaganden

Avsnitt 7: Avtalsåtaganden

7.1 Garanti för efterlevnad
    Garanterar ni CRA-efterlevnad i avtalet?
    [ ] Ja
    [ ] Nej
    [ ] Förhandlingsbart

7.2 Bevarande av dokumentation
    Behåller ni teknisk dokumentation i 10 år?
    [ ] Ja
    [ ] Nej
    [ ] Kortare period: ________________________

7.3 Notisskyldigheter
    Notifierar ni oss om:
    [ ] Säkerhetssårbarheter i produkten
    [ ] Förändringar i status för överensstämmelse
    [ ] Beslut om upphörande av stöd
    [ ] Väsentliga ändringar i säkerhetsarkitekturen

7.4 Revisionsrätt
    Tillåter ni efterlevnadsrevisioner?
    [ ] Ja - obegränsade
    [ ] Ja - med varsel
    [ ] Nej

7.5 Skadestånd
    Skadestår ni för CRA-bristande efterlevnad?
    [ ] Ja
    [ ] Nej
    [ ] Förhandlingsbart

Avsnitt 8: Intygande

Avsnitt 8: Intygande

Jag intygar att informationen i denna frågelista
är korrekt och fullständig efter bästa förmåga.

Jag förstår att [Ert företag] förlitar sig på denna information
för CRA-efterlevnadsändamål och att väsentliga felaktiga uppgifter
kan leda till avtalsuppsägning.

Ifylld av: _____________________________________
Befattning: ___________________________________________
Datum: ____________________________________________
Underskrift: _______________________________________

Varningssignaler (signaler före avtal)

Dessa varningssignaler ska fångas under granskningen av frågelistan och avtalsförhandlingen, innan någon inköpsorder undertecknas. För importörens motsvarighet, tillämpad vid den punkt där en icke-EU-tillverkares produkt släpps på EU-marknaden, se vad du ska vägra och varför på klustersidan för importörer.

Kritiska varningssignaler (diskvalificerar relationen)

Allvarliga varningssignaler (kräver förhandlad mildring)

Gula flaggor (övervaka genom hela relationen)

Verifieringsprocess och övervakning

Initial verifiering

1. Insamling av dokument

   • Begär kopia av försäkran om överensstämmelse
   • Begär SBOM (eller bekräftelse av tillgänglighet)
   • Begär kontaktinformation för säkerhet
   • Begär åtagande om stödperiod

2. Granskning av dokument

   • Verifiera att försäkran är signerad och fullständig
   • Kontrollera att produktidentifieringen stämmer
   • Verifiera påståenden om CE-märkning
   • Granska SBOM-format och fullständighet

3. Stickprovskontroller av efterlevnad

   • Verifiera att security.txt finns (om webbåtkomlig)
   • Kontrollera att CVD-policyn är publicerad
   • Testa att säkerhetskontakten svarar
   • Verifiera påståenden om stödperiod i dokumentationen

Löpande övervakning

SCHEMA FÖR LEVERANTÖRSÖVERVAKNING

Månadsvis:
[ ] Kontrollera publicerade säkerhetsråd
[ ] Verifiera att säkerhetskontakten fortfarande fungerar
[ ] Granska eventuella sårbarhetsavslöjanden

Kvartalsvis:
[ ] Begär uppdaterad SBOM (om betydande releaser)
[ ] Verifiera att CVD-policyn fortfarande är åtkomlig
[ ] Kontrollera nya certifieringar eller bortfall

Årligen:
[ ] Fullständig uppdatering av frågelistan
[ ] Granska status för stödperioden
[ ] Verifiera att dokumentationen fortfarande är tillgänglig
[ ] Granskning av affärsmässig stabilitet

Händelsestyrt:
[ ] Större säkerhetsincident → omedelbar granskning
[ ] Ägarbyte → full omvärdering
[ ] Produkten utgår → EOL-planering
[ ] Avtalsförnyelse → omverifiering av efterlevnad

När en leverantör inte svarar

Den enskilt vanligaste operativa bristen i leverantörs-due diligence är inte ett misslyckat svar på frågelistan: det är frånvaron av svar. Leverantören tystnar, drar ut på tiden i månader eller skickar en enradare på "vi följer alla tillämpliga regler". Det finns ingen lagstadgad sanktion mot leverantören (de har ingen CRA-plikt att svara på din frågelista), så eskaleringsflödet måste vara kommersiellt och procedurellt.

ESKALERING VID UTEBLIVET LEVERANTÖRSSVAR

VECKA 1: Initial frågelista skickad
        Rimligt svarsfönster: 15 arbetsdagar för nivå 1,
        30 arbetsdagar för nivå 2, 45 för nivå 3-4.

VECKA 3: Första uppföljning till den namngivna säkerhetskontakten
        och den primära kommersiella kontakten. Inköpsledaren på kopia.

VECKA 5: Eskalering till leverantörens account executive och till
        din egen inköpsdirektör. Sätt ett hårt datum.

VECKA 7: Om inget substantiellt svar fortfarande:
        a) Dokumentera utebliven respons i leverantörsanteckningen
        b) Märk komponenten "efterlevnad ej verifierad"
        c) Starta utvärdering av ersättningsleverantör
        d) Underrätta produktägare som är beroende av komponenten

VECKA 9: Beslutspunkt.
        Substantiellt svar mottaget → gå vidare till granskning.
        Inget svar → byt till ersättningsleverantör och
        dokumentera bytet som ett CRA-drivet beslut.

Utebliven respons är i sig due diligence-bevis. En marknadskontrollmyndighet som frågar varför du avbröt en leverantör kommer att acceptera ett dokumenterat eskaleringsspår och ett bytesbeslut långt lättare än ett vagt "de var svåra att arbeta med". Den artefakt du behåller är det daterade eskaleringsspåret plus beslutspromemoria.

Delade uppströmskomponenter och samordnad granskning

När flera tillverkare integrerar samma uppströmskomponent (ett brett använt kryptografibibliotek, ett vanligt SDK för bildbehandling, ett populärt inbäddat OS) bär varje nedströms tillverkare sin egen plikt enligt artikel 13.5. Plikten överförs inte till den mest noggranna kollegan, och "alla andra använder det" är inget försvar.

Det finns två samordningsmönster som minskar dubbelarbete utan att lyfta av plikten:

Due diligence-anteckningen bör namnge källan till den delade granskningen uttryckligen: "granskningsrapport från [arbetsgrupp], daterad [X], granskad och accepterad den [Y], luckor spårade i [system]". En kopia från en kollegas due diligence-fil är ingen ersättning för ditt eget beslutsspår.

Efter företagsförvärv: ärvda leverantörsrelationer

När ditt företag förvärvar ett annat företag ärver du även dess leverantörslista. En vanlig verklighet efter företagsförvärv är dussintals eller hundratals leverantörsrelationer utan någon CRA-formad due diligence-anteckning alls. Arbetet kan inte göras över en natt, men en triage är möjlig inom ett enda kvartal.

LEVERANTÖRSTRIAGE EFTER FÖRVÄRV (90 DAGAR)

DAG 1-15: Inventering
[ ] Hämta leverantörslistan från den förvärvade enhetens ERP- och inköpssystem
[ ] Korsreferera mot aktuella produkt-BOM:ar
[ ] Identifiera vilka leverantörer som matar in i CRA-omfattande produkter
[ ] Sortera bort leverantörer utanför omfattning från aktiv triage

DAG 15-30: Nivåindelning
[ ] Tillämpa din nivåmodell på den ärvda listan
[ ] Märk leverantörer utan befintlig due diligence-anteckning
[ ] Flagga leverantörer vars produkter faller i viktig klass II eller kritisk

DAG 30-60: Frågelistor till nivå 1
[ ] Skicka frågelistan till varje nivå-1-leverantör utan anteckning
[ ] Skicka om till varje nivå-1-leverantör vars anteckning är äldre än 24 månader
[ ] Fånga svar centralt

DAG 60-90: Beslutspunkt
[ ] Nivå-1-leverantörer med godkända svar → integrerade
[ ] Nivå-1-leverantörer med varningssignaler → mildringsplan eller ersättning
[ ] Nivå-2- och 3-leverantörer → schemalägg in i den ordinarie årscykeln

LÖPANDE:
[ ] Rulla in ärvda leverantörer i ditt normala övervakningsschema
[ ] Märk det förvärvsdrivna ursprunget i leverantörsanteckningen för revisionsändamål

CRA ger ingen anståndsperiod vid företagsförvärv; den förvärvande enheten ärver tillverkarens skyldighet på avslutsdagen, för de komponenter som idag sitter i levererad produkt. Triagen ovan är den praktiska kompromissen: bevisa att ett försvarbart due diligence-program körs, även när hela anteckningen håller på att byggas om.

Synlighet vid underleverantörer bortom första nivån

Din nivå-1-leverantör kan själv lägga ut till en nivå-2-leverantör, som i sin tur integrerar komponenter från en nivå-3-uppströms. CRA-plikten är din oavsett var i kedjan sårbarheten uppstår. Praktisk synlighet tar dock snabbt slut bortom nivå 1.

Tre konkreta kontroller som ger verklig synlighet bortom första nivån:

• Klausul om transitiv SBOM. Avtalet kräver att leverantörens SBOM inkluderar transitiva beroenden, inte bara direkta beroenden. En SBOM med enbart direkta beroenden döljer nästan hela den faktiska riskytan.
• Lista över underbiträden och underleverantörer. Avtalet kräver att leverantören avslöjar och uppdaterar listan över namngivna underleverantörer som rör säkerhetsrelevanta delar av komponenten. Klausulen ger dig ingen veto, men den ger dig synlighet.
• Pass-through för sårbarheter. Avtalet kräver att leverantören flödar sårbarheter som upptäcks i transitivt integrerade komponenter till dig på samma tidslinje som sårbarheter i direkt utvecklad kod.

Utan en transitiv SBOM kan du inte köra beroendeträdsskanningar mot komponenten, och du kan inte visa för en marknadskontrollmyndighet att risken bortom första nivån bedömdes. Utan en lista över underbiträden är ett uppströms byte av underleverantör (med sin egen härkomst, sina egna kontroller och sin egen bus-faktor) osynlig för dig. Utan pass-through för sårbarheter blir nivå-1-leverantörens tystnad om ett nivå-2-problem din tystnad om en säkerhetsincident.

Klausuler i leverantörsavtal

Inkludera dessa bestämmelser i leverantörsavtal. Varje klausul är den avtalsmässiga kroken för ett av de due diligence-utfall som beskrivs ovan.

Utfästelse om efterlevnad:

Leverantören utfäster och garanterar att produkten/-erna
överensstämmer med Förordning (EU) 2024/2847
(cyberresiliensförordningen) och att leverantören har slutfört
den nödvändiga bedömningen av överensstämmelse.

Tillhandahållande av dokumentation:

Leverantören ska på begäran tillhandahålla:
(a) kopia av EU-försäkran om överensstämmelse
(b) Software Bill of Materials i [CycloneDX/SPDX]-format,
    inklusive transitiva beroenden
(c) teknisk dokumentation relevant för köparens
    efterlevnadsskyldigheter
Svarstid: [5 arbetsdagar]

Notis om sårbarhet:

Leverantören ska underrätta köparen inom [24/48] timmar från det
att leverantören får kännedom om en säkerhetssårbarhet i
produkten/-erna eller i någon transitivt integrerad komponent
som:
(a) aktivt utnyttjas, eller
(b) har en CVSS-poäng på 7,0 eller högre, eller
(c) är föremål för publikt avslöjande

Åtagande om stödperiod:

Leverantören förbinder sig att tillhandahålla säkerhetsuppdateringar
för produkten/-erna under minst [5/7/10] år från
datumet för första marknadssläpp i EU.

SBOM-uppdateringar:

Leverantören ska tillhandahålla en uppdaterad SBOM inom [10]
arbetsdagar efter varje produktsläpp som innehåller
ändringar av direkta eller transitiva tredjepartskomponenter.

Revisionsrätt:

Köparen får revidera leverantörens efterlevnad av detta
avtal och tillämpliga CRA-krav efter [30 dagars]
skriftligt varsel, högst en gång per år
om inte utlöst av en efterlevnadsfråga.

Avslöjande av underleverantörer:

Leverantören ska upprätthålla och på begäran tillhandahålla en lista
över underleverantörer som bidrar till eller har åtkomst till
säkerhetsrelevanta delar av produkten/-erna. Leverantören
ska underrätta köparen om varje väsentlig ändring av den listan
inom [30] dagar.

Vanliga misstag

Att förlita sig på självintygande

Problem: Att acceptera en leverantörs muntliga försäkringar utan dokumentation.

Åtgärd: Skaffa alltid skriftligt bevis. Ingen kopia av försäkran, inget köp. En signerad frågelista är golvet, inte taket.

Engångsbedömning

Problem: Due diligence enbart vid avtalstecknande.

Åtgärd: Inför övervakningsschemat ovan. Efterlevnadsstatusen ändras; frågelistor blir inaktuella.

Att ignorera nivå-3- och nivå-4-leverantörer

Problem: Att enbart bedöma "stora" leverantörer och bortse från mindre.

Åtgärd: Även mindre komponenter inför sårbarheter (log4j-läxan). Skala bedömningen; hoppa inte över nivån.

Inget avtalsstöd

Problem: Att förlita sig på leverantörens goda vilja utan avtalsvillkor.

Åtgärd: Sätt efterlevnadsskyldigheterna på pränt. Klausulerna ovan är golvet.

Att vänta till december 2027

Problem: Att starta leverantörsbedömningar precis innan CRA:s tillämpningsdatum.

Åtgärd: Börja nu. Leverantörssvar släpar. Icke-efterlevande leverantörer behöver månader för att åtgärda eller ersättas.

Checklista för leverantörsdue diligence

CHECKLISTA FÖR LEVERANTÖRSDUE DILIGENCE

FÖRE ENGAGEMANG:
[ ] Leverantörsnivå fastställd (1/2/3/4)
[ ] Leverantörstyp fastställd (kommersiell, FOSS, OSS-förvaltare,
    moln, ren hårdvara, modifierad COTS)
[ ] Lämplig variant av frågelistan vald
[ ] Intern granskare utsedd

INITIAL BEDÖMNING:
[ ] Frågelista skickad
[ ] Frågelista mottagen och granskad
[ ] Varningssignaler identifierade och hanterade
[ ] Dokumentation insamlad:
    [ ] EU-försäkran om överensstämmelse (eller skäl till ej tillämpligt)
    [ ] SBOM med transitiva beroenden (eller bekräftad tillgång)
    [ ] CVD-policy
    [ ] Åtagande om stödperiod
[ ] Stickprov slutförda:
    [ ] security.txt verifierad
    [ ] Säkerhetskontakt testad
    [ ] CE-märkning verifierad

AVTALSFÖRHANDLING:
[ ] Efterlevnadsklausuler inkluderade
[ ] Bestämmelser om dokumentation överenskomna
[ ] Villkor för sårbarhetsnotis satta (timmar, inte "skyndsamt")
[ ] Åtagande om stödperiod säkrat
[ ] Revisionsrätt inkluderad
[ ] SBOM-uppdateringsschema överenskommet
[ ] Klausul om underleverantörsavslöjande inkluderad

EFTER AVTAL:
[ ] Övervakningsschema etablerat
[ ] Första dokumentationsleveransen bekräftad
[ ] Kontakter registrerade i leverantörshanteringssystemet
[ ] Granskningsdatum kalenderlagda

LÖPANDE:
[ ] Månadskontroller utförda
[ ] Kvartalsgranskningar utförda
[ ] Årlig omvärdering utförd
[ ] Händelsestyrda gransknigar utförda (incident, ägarbyte, EOL)

Relaterade guider

• Så genererar du en CRA-kompatibel SBOM: verktyg, format och CI/CD-integration
• CRA-tillverkarguiden
• CRA-distributörens checklista

Den här artikeln är endast avsedd som information och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, konsultera kvalificerat juridiskt ombud.