ENISA om frontier AI: 5 konsekvenser för CRA-tillverkare

I januari 2026 stängde curl sitt program för samordnad sårbarhetsredovisning (CVD). AI-genererade rapporter hade begravt underhållarna, och projektet bedömde att intaget kostade mer än det gav. ENISA hänvisar nu till den nedstängningen i en officiell publikation. Här är den del som spelar roll för dig: en CRA-tillverkare kan inte göra samma val. Cyberresiliensförordningen gör ett intag för sårbarhetsredovisning till ett lagkrav från 11 december 2027. curl valde en utväg. Du får ingen.

Det är en av fem kollisioner mellan ENISA:s nya positionspapper och dina CRA-skyldigheter. ENISA publicerade sin syn på cybersäkerhet i frontier AI-eran i juli 2026. De 16 sidorna riktar sig till nationella myndigheter, EU:s beslutsfattare, försvarare och tjänsteleverantörer. Inte ett enda avsnitt är skrivet för produkttillverkare. Konsekvenserna landar ändå på ditt bord.

Vad ENISA faktiskt publicerade

Rapporten är en 16-sidig positionsnot, framtagen tillsammans med EU:s CSIRT-nätverk och EU-CyCLONe mellan maj och juni 2026. Den juridiska noten klargör att rapporten inte skapar någon rättslig skyldighet. Se den som en signal om vart ENISA:s operativa vägledning är på väg, och läs den tillsammans med de CRA-skyldigheter som redan binder dig.

Kärnpåståendet går att mäta. Fönstret mellan att en sårbarhet upptäcks och att den utnyttjas har gått från år till månader till minuter. Data som ENISA hänvisar till sätter angreppet till 15 minuter efter avslöjandet och medianen för exfiltrering till 72 minuter efter första intrånget. NCSC-NL tillägger att autonoma agenter tar bort försvararens fördel av att vara ensam om upptäckten. När en AI-agent väl har hittat en sårbarhet blir det att bygga angreppet en beräkning, inte ett ingenjörsprojekt. Vissa angrepp existerar nu innan fixen gör det, vilket rapporten kallar negativ tid till utnyttjande.

ENISA är öppen om den andra sidan av ekvationen. Rapporten konstaterar att ENISA:s egen kapacitet, tillsammans med tillverkarnas och de nationella CSIRT:ernas, behöver förstärkas eller omprövas för att klara den kommande vågen av upptäckta sårbarheter. Myndigheten bakom den gemensamma rapporteringsplattformen säger, svart på vitt, att volymerna kommer att pressa alla.

De fem avsnitten nedan tar var sitt fynd från rapporten och följer det till en CRA-skyldighet.

1. curl stängde sitt sårbarhetsintag. Det kan inte du.

I början av 2026 hade AI-genererade sårbarhetsrapporter börjat överbelasta delar av kedjan för sårbarhetsredovisning inom öppen källkod. Rapporten namnger skadan konkret: en global bug bounty-plattform pausade nya inlämningar till Internet Bug Bounty efter en våg av AI-assisterade rapporter med varierande kvalitet, och curl avslutade sitt CVD-program i januari 2026 eftersom underhållarna inte klarade av volymen och bruset. Problemet är utspädd signal. Mänskliga granskare lägger sin tid på att skilja verkliga fynd från repetitiva, ytliga eller overifierade inlämningar.

Ett open source-projekt kan stänga dörren. Under CRA kan inte du. Förordningen kräver att du inför och verkställer en policy för samordnad sårbarhetsredovisning, och att du publicerar en kontaktadress för att rapportera sårbarheter i din produkt. Båda skyldigheterna gäller från 11 december 2027. Här är den obekväma sanningen: CRA skrevs utifrån antagandet att rapporter är sällsynta och värdefulla. Rapporten dokumenterar en verklighet där de kommer in i hundratal, maskinskrivna och overifierade. Skyldigheten kvarstår. Antagandet bakom den är borta.

Din CVD-policy behöver alltså en klausul för AI-eran. Tre saker hör hemma i den:

• Valideringskrav: ange vad en rapport måste innehålla för att komma in i triage. Berörd produkt och version, reproduktionssteg eller ett proof of concept, samt den observerade effekten. En rapport utan detta får en begäran om komplettering, inte en triageplats.
• Deduplicering före triage: AI-verktyg skickar in samma svaghet i många formuleringar. Klustra inkommande rapporter mot dina kända fynd först, och räkna kluster, inte e-postmeddelanden.
• Triageåtaganden efter allvarlighetsgrad: publicera svarstider du klarar av att hålla vid tio gånger dagens volym. En bekräftelse-SLA som du bryter varje vecka är sämre bevisning än en blygsam SLA som du faktiskt håller.

En nyans till från rapporten: ENISA noterar att de senaste månaderna har fört med sig en verklig förbättring av AI-rapporternas kvalitet, så en generell regel om att avvisa AI-rapporter kastar bort signal. Filtrera på fullständighet och reproducerbarhet, inte på vem som skrev rapporten. Att publicera intagets mekanik via security.txt håller kontaktpunktsskyldigheten granskningsbar.

2. AI blåser upp vad "känd" och "utnyttjningsbar" betyder

Rapporten innehåller ett tal som förändrar hur du bygger din releaseprocess. En branschorganisation berättade för ENISA att den gick från cirka 80 CVE:er under Q1 2025 till nära 500 under Q1 2026, och därefter till ungefär 500 om dagen efter att ha börjat använda frontier AI-verktyg. ENISA kallar det den ekonomiska devalveringen av upptäckt: att hitta brister industrialiseras, så avslöjandevolymen ökar snabbare än någon hinner åtgärda.

CRA förbjuder att släppa ut en produkt på marknaden med kända sårbarheter som kan utnyttjas. Två ord bär upp den regeln. AI utökar känd rent mekaniskt: varje skannerkörning mot din SBOM ger fler fynd, varje kvartal. Det AI inte förändrar är utnyttjningsbar, och det är där din efterlevnadsbevisning nu finns. Arbetet med allvarlighetsgradering för att skilja inneboende allvarlighetsgrad från sannolikheten för utnyttjande slutar vara en optimering och blir själva releasegrinden.

Kedjeeffekten går åt båda hållen. ENISA varnar för att lågriskbrister inte längre kan avfärdas som ofarliga, eftersom modeller kedjar samman dem till fungerande angrepp. Så "lågt CVSS, ignorera" är dött som triageregel. Men en ren CVE-räknargrind i CI dör också: vid 500 fynd om dagen blockerar den varje release för alltid. Det som överlever är dokumenterad utnyttjningsbarhet per fynd. Rapporten namnger de två verktygen: EPSS från FIRST för sannolikheten för utnyttjande, och VEX för att dokumentera om din produkt över huvud taget berörs.

3. Varje patch du släpper kartlägger hålet i dina äldre versioner

Rapportens avsnitt om N-day-angrepp konstaterar att patchdiffar och binära ändringar historiskt har fött reverse engineering och utveckling av angrepp, och att utnyttjandefönstret öppnas innan patchen ens är utrullad. Frontier AI krymper den reverse engineeringen från dagar av specialistarbete till en beräkning. Rapporten noterar också att AI-assisterad analys snabbar upp förståelsen av kod i äldre system.

Sätt nu in din egen produktlinje i den bilden. Du släpper en säkerhetsfix för version N. Diffen beskriver sårbarheten exakt. Om version N-1 delar den berörda koden och redan har passerat sitt supportslut, är din egen patch den bästa tillgängliga guiden för att angripa din egen installerade bas. I mänskligt tempo var det här en känd men långsam risk. I maskintempo sker det samma dag.

Det förändrar vad två CRA-beslut betyder:

• Supportperioden, minst fem år i de flesta fall, avgör vilka versioner som fortfarande får fixar. Versioner utanför den försvinner inte från fältet. De förblir nåbara, och varje fix du publicerar för dina versioner med support lär angriparna om dem. Versionsspridning är nu en attackyta, så färre, längre supportperioder för dina versioner slår många kortlivade. Se supportperiod för hur längden fastställs.
• Redovisningen av supportslut som du är skyldig att lämna till köpare före köpet blir operativ information, inte hyllpapper. En köpare som kör produkten förbi det datum du redovisat kör en produkt som din egen patchström beskriver för angripare. Säg det rakt ut i redovisningen. Sidan om redovisning av supportslut beskriver var datumet måste anges.

NCSC Irlands råd i rapporten är rakt på sak: granska tillgångsregister, prioritera patchdisciplin och bedöm exponeringen mot komponenter utan support. För en tillverkare är spegelbilden av den plikten att hindra gapet mellan den "patchade grenen" och den "övergivna grenen" från att växa i det tysta.

4. AI-skrivna patchar levereras fortfarande under din CE-märkning

ENISA räknar med att åtgärdsarbetet kommer att använda samma verktyg som upptäcktsarbetet. Resultatet är rapportens verifieringsflaskhals: tekniska team möter en skalutmaning i att granska och validera AI-genererade patchar så att de inte introducerar nya sårbarheter i kodbasen. Rapporten beskriver också trycket från andra hållet, ett auktoritetsgap där mänskliga ändringsråd inte hinner godkänna insatser inom de minuter som finns tillgängliga för att möta autonoma angrepp.

CRA har ingen uppfattning om vem eller vad som skriver din kod. Den har en bestämd uppfattning om vem som svarar för den. Förordningen kräver effektiv och regelbunden säkerhetstestning av din produkt, och den försäkran om överensstämmelse du undertecknar under bedömning av överensstämmelse täcker varje patch du distribuerar under supportperioden. En AI-genererad fix som öppnar ett nytt hål är din bristande överensstämmelse, i maskintempo.

Den praktiska konsekvensen: din patchpipeline behöver testbevisning som skalar med patchvolymen. Mänsklig granskning av varje AI-skriven rad skalar inte till 500 fynd om dagen. Dokumenterad, automatiserad säkerhetstestning i patchflödet gör det, och den ger de underlag din tekniska dokumentation behöver. Om du använder AI-assisterad åtgärdning, dokumentera vilka patchar som var maskingenererade och vilken validering var och en klarade. När en tillsynsmyndighet frågar hur du höll din testplikt ärlig i det tempot, är svaret en logg, inte ett policydokument.

5. Dina sårbarhetsrapporter blir en offentlig säkerhetshistorik

Den sista konsekvensen är den tystaste i rapporten. ENISA skriver att korrelerad EUVD-data kan identifiera hotspots i leveranskedjan, systemiska svagheter och sårbarhetstrender som drivs på av AI-assisterad upptäckt. En mening längre fram står det: CRA-relaterad rapportering kan hjälpa till att validera tillverkares härdningspåståenden mot verklig utnyttjningsbarhet och incidentmönster.

Läs det som tillverkare. Från 11 september 2026 anmäler du aktivt utnyttjade sårbarheter och allvarliga incidenter inom 24 timmar via den gemensamma rapporteringsplattformen, därefter en uppföljning inom 72 timmar, och sedan en slutrapport inom 14 dagar från fixen. Varje anmälan hamnar i en infrastruktur som ENISA planerar att korrelera. Med tiden blir den korrelationen en säkerhetshistorik per leverantör: hur ofta du blev utnyttjad, hur snabbt du fixade, och hur din historik står sig mot dina påståenden.

• Skriv produktsäkerhetspåståenden du kan försvara med din egen rapporteringshistorik. "Härdad" och "secure by design" på ett datablad kommer förr eller senare att stå bredvid din rad i EUVD. Marknadsföring som springer om datan blir ett samtal med marknadskontrollmyndigheten.
• Behandla rapporteringskvalitet som rykte, inte pappersarbete. En precis 72-timmarsanmälan med verkliga korrigerande åtgärder läses annorlunda än en minimal en, och ENISA:s uttalade mål är att sluta gapet mellan avslöjande och samordnat gensvar med hjälp av den här datan. Själva rapporteringskedjan togs i drift i etapper i år, då ENISA tog in sina första CVE Numbering Authorities i maj 2026.

Rapportens sammanfattning säger att SRP:n måste användas, när den väl är i drift, för att hantera utmaningarna från den nya utvecklingen. ENISA har förbundit sig till det skriftligt. Dina rapporter är underlaget.

Den här artikeln är enbart för informationsändamål och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, kontakta kvalificerad juridisk rådgivare.