Sikkerhed i produktet og i udviklingsprocessen
Sikkerhed i et softwareprodukt afgøres i det daglige: hvordan kode bliver gennemgået, hvilke biblioteker der hentes ind, hvor nøgler ligger, og hvad der sker, når en sårbarhed bliver kendt. Det hører til de tekniske rutiner, og derfor er det et emne for den, der leder produktet. Den brede sikkerhedsledelse af virksomheden, med risikovurdering og rapportering, er en anden opgave og beskrevet under CISO as a Service. Siden her samler artiklerne om det, der skal være i orden i selve produktet, og om Cyber Resilience Act (CRA), på dansk forordningen om cyberrobusthed.
Det, der går igen
Tre spørgsmål afslører det meste. Ved I, hvad produktet består af, også de dele, I ikke selv har skrevet? Opdager I en sårbarhed, før kunderne gør? Og ved I, hvem der gør hvad, hvis den bliver udnyttet en lørdag? Svarene skal bygges ind i de rutiner, teamet allerede har. En sikkerhedsplan, der ligger uden for det almindelige arbejde, bliver sjældent fulgt.
Sikkerhed i de daglige rutiner
- Sikker softwareudvikling i et lille team Sikkerhed bygget ind i de rutiner, teamet allerede har.
- Tredjepartsbiblioteker, SBOM og byggepipeline Hvad produktet består af, og hvordan I opdager sårbare komponenter i tide.
- Nøgler og adgangskoder i koden og pipelinen Hvor nøgler typisk ligger, hvordan de flyttes ud, og hvad der sker ved udskiftning.
- Persondata i produktet: sletning, logning og testdata Databeskyttelse gennem design set fra udviklerne, med sletning pr. kunde og produktionsdata i test.
- Før kunden kræver en pentest af produktet Det tekniske forarbejde i produktet og teamet, før en test bestilles.
Cyber Resilience Act
- Cyber Resilience Act: hvad betyder den for jeres produkt? Hvilke produkter forordningen rammer, og hvad den kræver i udvikling og sårbarhedshåndtering.
- Er vores webapp omfattet af Cyber Resilience Act? Afgørelsen i tre spørgsmål, og det svar, kunden skal have.
- 24 timer til ENISA: hvem i softwarehuset gør hvad? Fordelingen af roller, når en sårbarhed skal indberettes, og nogen er på ferie.
- Supportperiode: hvor længe lover I at rette sårbarheder? Grundlaget for perioden, og hvad den kræver af ældre versioner og planen for produktet.
- Hvornår er en opdatering en væsentlig ændring? Hvorfor spørgsmålet afgør, om et ældre produkt kommer under kravene.
- CE-mærke på software: selvvurdering eller bemyndiget organ? De tre kategorier af produkter, og hvorfor kernefunktionen afgør, hvilken I hører til.
Hvor står I med CRA?
Forordningen gælder allerede i én del. Siden 11/9 2026 har en fabrikant pligt til at indberette sårbarheder, der aktivt udnyttes, og alvorlige hændelser, som påvirker produktets sikkerhed. Den tidlige varsling skal ske inden for 24 timer efter kendskab. Det sker via ENISA’s indberetningsplatform. Hovedforpligtelserne gælder fra 11/12 2027.
Om jeres produkt er omfattet, afhænger af, hvad der kører hos brugeren. Det er Kommissionens opfattelse i dens vejledning, at en webapplikation, der udelukkende bruges i browseren, som udgangspunkt falder uden for begrebet produkt med digitale elementer. Det gælder dog ikke, hvis den er med til at få et andet omfattet produkt til at fungere. Installerer I en klient eller en app, er klienten et produkt, og den fjerndatabehandling, den er afhængig af, er en del af det. Vejledningen er ikke bindende, og den endelige afgørelse ligger hos domstolene.
I Danmark er der sendt et udkast til en supplerende lov i høring. Ifølge høringsudkastet foreslås Styrelsen for Samfundssikkerhed som markedsovervågningsmyndighed. Det er kun et forslag. Siden her er ikke juridisk rådgivning, og konkrete spørgsmål er et spørgsmål til advokat. Datoerne for de øvrige regler står samlet i Regler for softwarevirksomheder.
Det skal I lade være med
- At antage, at reglerne ikke rammer jer, fordi produktet er en webapp · en app eller en klient kan ændre svaret.
- At vente med underretningsplanen til første gang, den skal bruges · 24 timer er kort tid i et lille team.
- At lægge rigtige kundedata i testmiljøet · det er ofte dér, de er mindst beskyttede.
- At lade én person eje alle nøgler · så har I også én person, der kan være væk.
Det skal I kræve af den eksterne
- ☐ Sikkerhed som en del af teamets rutiner, skrevet så udviklerne kan bruge det.
- ☐ Et overblik over produktets komponenter og hvem der følger med i dem.
- ☐ Plan for underretning, med navne og stedfortrædere.
- ☐ Henvisning til kilden, når der siges noget om regler.
Kilder
- Kommissionen: vejledning om Cyber Resilience Act af 27/7 2026, ikke bindende
- Kommissionen: Cyber Resilience Act, datoer
- Kommissionen: underretning efter CRA
- Høringsportalen: udkast til lov om supplerende bestemmelser til forordningen om cyberrobusthed
Senest gennemgået: november 2026.
Næste skridt
Læs også: Artikler om CTO as a Service · Når kunderne stiller krav til produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
Mangler I en CTO?
Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.
