Bilag I, del I: softwarens egenskaber krav for krav

Bilag I, del I, i Cyber Resilience Act lister de egenskaber, et produkt skal have, når det forlader huset. Kravene er skrevet bredt, fordi de skal passe på alt fra en lille app til et styresystem, og risikovurderingen afgør, hvordan hvert krav udmøntes i jeres software. Artiklerne her tager kravene et for et og viser, hvordan en gennemgang prøver dem i en installeret kopi frem for i en beskrivelse. Kravene gælder fra 11. december 2027.

Ved frigivelse og første opstart

• Ingen kendte udnyttelige sårbarheder ved frigivelse: hvornår er en sårbarhed “kendt” og “udnyttelig”? Status ved release, dokumenteret.
• Sikker standardkonfiguration i software: installation, første opstart og standardkonti Sikker uden ekstra indstillinger.
• Automatiske sikkerhedsopdateringer som standard: fravalg, undtagelser, og hvor jeres ansvar slutter Slået til fra start, med et fravalg.
• Begrænsning af angrebsflader: grænseflader, porte og fejlsøgningsfunktioner, ingen bruger Det, kopien faktisk svarer på.

Beskyttelse af data og funktioner

• Adgangskontrol i softwaren: autentificering, roller og melding om uautoriseret adgang Også servicekonti og API-nøgler.
• Fortrolighed: kryptering i hvile og under transport, styresystemets funktioner og skift af algoritme Planen for at skifte algoritme.
• Integritet: afviser softwaren ændrede data, kommandoer og konfiguration, og melder den korruption? Fire kontrolpunkter.
• Dataminimering i softwaren: telemetri, fejlrapporter og logfiler Også data uden personoplysninger.
• Sikker sletning og flytning af data: afinstallation, eksport og lukket konto Brugerens data ud og væk.

Robusthed og spor

• Tilgængelighed: væsentlige funktioner ved udfald, og softwaren må ikke genere andre Modstand mod overbelastning og udfald.
• Når noget går galt inde i softwaren: adskillelse mellem dele, så én fejl ikke giver alt Moduler, plugins og lejere holdt fra hinanden.
• Sikkerhedslogning som produktkrav: hvad softwaren skal registrere, og brugerens fravalg Registrering med et fravalg, der virker.

Sådan kommer I i gang

Installer en frisk kopi af produktet, som en kunde ville få den, og gå kravene igennem med risikovurderingen ved siden af. Notér, hvad der er slået til, hvilke porte og grænseflader der svarer, hvilke konti der findes, og hvad softwaren sender hjem. Forskellen mellem det, dokumentationen lover, og det, kopien gør, er listen over det, der skal rettes. De tekniske kontrolpunkter i driften hos en kunde er et andet emne; her er det produktets egenskaber ved levering, der gælder.

Hvad det kræver, og hvad det koster at lade være

Prøven kræver en udvikler eller tester med adgang til et rent testmiljø og nogle dage pr. produkt. Bliver den ikke lavet, er det første gang en kunde, en forsker eller en myndighed ser nærmere på en installation, at afvigelserne bliver fundet, og så er de allerede ude hos brugerne.

Det skal I lade være med

• At lade dokumentationen stå i stedet for prøven · kravet gælder det, der installeres.
• At slå sikkerhedsfunktioner fra for at lette opsætningen · standarden skal være den sikre.
• At betragte logning og sletning som valgfrie · begge står i bilaget.

Det skal auditten kunne vise

• ☐ For hvert krav: hvordan det er opfyldt, eller hvorfor det er fravalgt.
• ☐ Resultatet af en prøve på en ren installation.
• ☐ En liste over åbne grænseflader og konti ved levering.
• ☐ Sårbarhedsstatus på frigivelsesdagen for hver version.

Senest gennemgået: november 2026.

Næste skridt

• Ingen kendte udnyttelige sårbarheder ved frigivelse
• Sikker standardkonfiguration i software

Læs også: Risikovurdering og udviklingsproces · SBOM og komponenter

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT