Gir en CRA-SBOM-sjekkliste deg en lisensside?

Produktteam bør betrakte 2026 til 2027 som vinduet for å etablere komponentoversikt, SBOM-generering, sårbarhetsprosesser og (separat) arbeidsflyter for lisensoffentliggjøring. Å vente til samsvarsvurderingen med å oppdage at dere ikke har noen gjennomgått tredjepartslisensoversikt, skaper dobbel krisehåndtering.

Tidslinjene varierer etter produktklasse og gjennomføringsrettsakter, og dokumentasjonen må holdes oppdatert gjennom hele supportperioden. Bekreft alle datoer med juridisk rådgiver; denne siden er ikke juridisk rådgivning.

Omfanget avhenger av produktklassifisering, ikke selskapsstørrelse: Produkter med digitale elementer som plasseres på EU-markedet, omfattes, mens produkter som allerede dekkes av sektorspesifikke EU-regler (medisinsk utstyr, motorvogner, sivil luftfart) og rene skytjenester uten en produktvinkling, som regel er unntatt. Installerbar programvare, firmware, tilkoblede enheter, og mange kommersielle open source-distribusjonsmodeller kan falle innenfor omfanget når de selges i EU.

Rene SaaS-unntak finnes i den generelle markedsforståelsen, men krever produktspesifikk juridisk gjennomgang.

CRA krever en SBOM, men det dekker ikke lisensoffentliggjøring. Annex I, del II forplikter produsenter til å identifisere og dokumentere komponenter, inkludert en SBOM i et vanlig brukt, maskinlesbart format som minst dekker avhengighetene på toppnivå, noe som er komponentidentitetsdata, ikke gjennomgått lisenstekst.

Den forpliktelsen fremskynder innføringen av SBOM blant leverandører som selger i EU. Team produserer CycloneDX eller SPDX fra CI, ofte for første gang, og overleverer filer til sikkerhet eller etterlevelse. SBOM-en oppfyller CRAs komponentdokumentasjon. Den gir ikke automatisk notice, navngivelse eller fullstendig lisenstekst for hver komponent.

CRAs dokumentasjon for cybersikkerhet dekker risikovurdering, sårbarheter, oppdateringer og sikker utvikling. Produktsikkerhet, PSIRT og juridisk eier det arbeidet. Lisensetterlevelse dekker immaterialrettslige forpliktelser i tredjepartsprogramvare: Notice, navngivelse, copyleft-betingelser. En annen arbeidsflyt med menneskelige godkjenningssperrer.

Å blande dem sammen skaper falsk trygghet. Et team kan bestå en intern CRA-beredskapsgjennomgang med SBOM-er og patch-SLA-er, men likevel stryke på en kjøpers forespørsel om lisensetterlevelse fordi ingen har gjennomgått lisensteksten.

• CRA-SBOM: Komponentidentitet for sikkerhets- og regulatorisk dokumentasjon.
• Lisensoffentliggjøring: Fullstendig tekst og navngivelse for juridisk og innkjøp.
• CRA: Sårbarhetsrapportering til myndigheter under definerte betingelser.
• Lisens: Opphavsretts- og distribusjonsbetingelser i OSS-lisenser.
• Samme lockfile som grunnlag, ulike utdata og ulike eiere.

CRA forventer at dokumentasjonen oppdateres gjennom supportperioden når sårbarheter og komponenter endres. Det samme avviket i avhengigheter bryter lisensfremstillingene hvis ingen gjennomgår på nytt det som faktisk ble levert.

Team med flere personer merger pakkeoppdateringer kontinuerlig. Uten ny import og republisering ved utgivelse, beskriver både CRA-SBOM-en og lisensoffentliggjøringen dagens produkt slik det var i går. Regulatorisk dokumentasjon og kjøpervendte oversikter må følge kodebasen.

Store kunder kobler leverandørers CRA-status inn i sine egne forsyningskjede-programmer, og limer fortsatt inn lisensdeler fra RFP-maler skrevet før CRA fantes. De ber om SBOM pluss open source-lisensside pluss en attestasjon på at listen vedlikeholdes.

CRA-opplærte innkjøpsteam vil forvente varig tilgang til etterlevelsesartefakter. Det erstatter ikke innholdet i lisensoffentliggjøringen. Det hever kravet til hvor oppdaterte og tilgjengelige oversiktene deres må være.

Sikkerhetsorganisasjonen: SBOM-generering, sårbarhetshåndtering, hendelsesrapportering, grunnlag for CRA-samsvar, sikker levering av oppdateringer.

Etterlevelse / juridisk / ingeniørdrift: Oversikt over tredjepartslisenser, gjennomgang, publiseringssperrer, offentliggjøringseksporter, svar på kjøperspørreskjemaer.

Felles grunnlag: Lockfiler og SBOM-er fra CI. Ulike utdata: Sikkerhet bruker SBOM-en til CVE-er; etterlevelse bruker den samme importen til gjennomgåtte lisensoversikter.