Software skal designes, udvikles og produceres, så angrebsfladen er begrænset, også de eksterne grænseflader. Det følger af litra j i bilag I, del I, nr. 2, som myndighederne kan håndhæve fra 11. december 2027.
En angrebsflade er summen af de steder, hvor nogen kan komme i kontakt med produktet. Kravet handler om at holde den så lille, som produktets formål tillader, og om at kunne vise det.
Ordlyden og dokumentationen
Litra j er kort. Produkter skal designes, udvikles og produceres med henblik på at begrænse angrebsflader, herunder eksterne grænseflader. Også her bestemmer risikovurderingen, hvordan kravet udmøntes.
Bilag VII, nr. 2, litra a, kræver, at dokumentationen rummer en beskrivelse af systemarkitekturen, der forklarer, hvordan softwarekomponenterne bygger på eller indgår i hinanden. Det er lovkravet til dokumentationen.
Forordningen kræver ikke en særskilt liste over grænseflader. I praksis er sådan en liste den letteste måde at vise, at kravet i litra j er opfyldt, og at arkitekturbeskrivelsen stemmer med virkeligheden. Listen er derfor praksis, ikke lov.
Hvad hører med til angrebsfladen?
I et softwareprodukt tæller blandt andet:
- netværksporte, produktet lytter på,
- API’er og webgrænseflader, også interne, der kan nås fra netværket,
- fejlsøgnings- og diagnosefunktioner,
- administrationskonsoller,
- filformater, produktet læser, og protokoller, det taler,
- plugin- og udvidelsesmekanismer,
- lokale grænseflader som navngivne rør eller sockets, andre programmer kan bruge.
Hvor langt listen skal gå, afhænger af produktet. Det vigtige er, at den omfatter det, der er tilgængeligt i den version, der leveres. Grænseflader i tredjepartskomponenter tæller med, hvis de er aktive i jeres produkt. Et indbygget webbibliotek, der åbner sin egen statusside, er en del af jeres angrebsflade, selv om I ikke har skrevet koden.
Fra dokument til installeret kopi
Kernen i en gennemgang af litra j er sammenligningen. På den ene side står arkitekturbeskrivelsen og fabrikantens liste over grænseflader. På den anden side står det, en installeret kopi faktisk svarer på.
En almindelig fremgangsmåde er at installere den version, der frigives, med standardindstillinger og registrere, hvilke porte der er åbne, hvilke stier en webgrænseflade svarer på, og hvilke lokale grænseflader der er oprettet. Alt, der ikke står på listen, er et fund. Alt, der står på listen uden at være begrundet i risikovurderingen, er også et fund.
Typiske fund er en fejlsøgningsfunktion, der var slået til under udviklingen og aldrig blev slået fra, en gammel API-version, der stadig svarer, og en administrationsflade, der lytter på alle netværkskort i stedet for kun det lokale. Eksemplerne er tænkte.
Det, ingen bruger
Listens titel taler om funktioner, ingen bruger. Kommissionens vejledning har et eksempel, der viser, hvordan forordningen ser på dem. En sikkerhedsopdatering, der lukker ubrugte netværksporte, er ifølge vejledningen ikke en væsentlig ændring. Omvendt kan en opdatering, der tilføjer nye eksternt tilgængelige grænseflader, gøre en opdatering til en væsentlig ændring.
Det giver en klar retning for designet. Det, der ikke er brug for, bør ikke være der, og det er lettere at fjerne end at tilføje.
Risikobaseret vurdering
Ikke alt kan fjernes. Kommissionens FAQ bruger et hardwareeksempel, der viser tankegangen. En printer har en aktiv fejlsøgningsgrænseflade på bundkortet, som kun kan udnyttes med fysisk adgang og indgreb. Risikoen vurderes som meget lav og dokumenteres. Eksemplet er hardware, og vi nævner det kun, fordi det viser, at en grænseflade kan blive stående, når vurderingen er skrevet ned.
For software kan det tilsvarende være en lokal grænseflade, der kun kan nås af en bruger med administratorrettigheder på maskinen. Om det er forsvarligt, afgøres i risikovurderingen.
Grænsen til driften
Hvad der står åbent hos en kunde i daglig drift, afhænger også af kundens egne valg. Det emne behandles under kontrol af åbne porte og tjenester i drift. Her handler det om produktet, som det forlader fabrikanten.
Angrebsfladen i nye versioner
Angrebsfladen ændrer sig med hver version. En ny integration, et nyt filformat eller en ny administrationsfunktion kan udvide den. Vejledningens pointe om nye eksternt tilgængelige grænseflader betyder, at en sådan udvidelse både skal vurderes efter litra j og efter reglerne om væsentlig ændring. En enkel praksis er at sammenligne listen over grænseflader mellem to versioner og kræve en begrundelse for hver ny linje. Praksis af den slags står ikke i forordningen, men den gør det muligt at vise, at udvidelsen var et valg.
Hvad det kræver, og hvad det koster at lade være
Det kræver en arkitekturbeskrivelse, der er så præcis, at den kan sammenlignes med en installeret kopi, en liste over grænseflader og en begrundelse for hver i risikovurderingen.
Uden den sammenligning ved I ikke, om beskrivelsen passer. En glemt fejlsøgningsport er et af de fund, en myndighed eller kunde kan gøre på få minutter.
Det skal I lade være med
- At lade udviklingsfunktioner følge med i den frigivne version · byg dem ud, eller slå dem fra som standard.
- At beholde gamle API-versioner af bekvemmelighed · hver version, der svarer, er en del af angrebsfladen.
- At skrive arkitekturbeskrivelsen fra hukommelsen · den skal stemme med det, der leveres.
Det skal auditten kunne vise
- ☐ En arkitekturbeskrivelse efter bilag VII, nr. 2, litra a.
- ☐ En liste over porte, API’er, administrations- og fejlsøgningsfunktioner i den frigivne version.
- ☐ Resultat af en sammenligning mellem listen og en installeret kopi.
- ☐ En begrundelse i risikovurderingen for hver grænseflade, der er åben som standard.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra j, og bilag VII, nr. 2, litra a, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 109 og eksempel 47, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.3.1, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Installér den seneste version, skriv op, hvad den svarer på, og læg listen ved siden af arkitekturbeskrivelsen.
- Bilag I, del I: softwarens egenskaber krav for krav
- Den tekniske dokumentation for software efter bilag VII
Læs også: Sikker standardkonfiguration i software · Når noget går galt inde i softwaren
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
