Ledelsen skal sikre, at sikkerhed er en del af softwareudviklingen fra de første krav til løbende vedligeholdelse. Det gælder, uanset om koden skrives internt eller købes hos en leverandør. Konkret betyder det at stille krav om risikovurdering før udvikling, kontrol af tredjepartskomponenter, test før release og en klar proces for at håndtere sårbarheder, efter produktet er taget i brug.
Hvorfor ledelsen har et ansvar
Cyber Resilience Act (CRA) stiller krav til producenter af produkter med digitale elementer. En producent skal udføre en risikovurdering for cybersikkerhed, der tages i betragtning under planlægning, design, udvikling, produktion, levering og vedligeholdelse. Det betyder, at sikkerhed ikke er noget, udviklerne selv beslutter — ledelsen skal sikre rammerne. Er virksomheden omfattet af NIS2, kan der også komme krav derfra — læs mere om afgrænsningen i guiden om NIS2.
NIST’s Secure Software Development Framework (SSDF) er en anerkendt ramme, der kan bruges både internt og i dialog med leverandører. Ved at følge disse praksisser bør softwareproducenter reducere antallet af sårbarheder i det færdige produkt. Rammen kan også bruges af indkøbere, når de formulerer krav til leverandører.
Tjekliste: Krav til eget udviklingsteam
Brug listen, når I vurderer jeres nuværende praksis eller formulerer krav til et nyt projekt:
- Risikovurdering før udvikling. Før den første linje kode skrives, skal der ligge en vurdering af, hvilke trusler produktet kan møde, og hvilke sikkerhedskrav der følger af det.
- Sikkerhedskrav i specifikationen. Funktionelle krav er ikke nok. Specifikationen skal indeholde krav til autentificering, kryptering, logning og adgangsstyring.
- Overblik over tredjepartskomponenter. Moderne software bygger på open source-biblioteker og tredjepartsmoduler. CRA kræver, at producenten udviser omhu, så tredjepartskomponenter ikke kompromitterer produktets sikkerhed. I praksis betyder det en opdateret liste over komponenter og versioner — ofte kaldet en Software Bill of Materials (SBOM).
- Sikkerhedstest før release. Koden skal testes for kendte sårbarheder, før den frigives. Det kan være automatiserede scanninger, kodegennemgang eller penetrationstest afhængigt af produktets risikoprofil.
- Procedure for sårbarhedshåndtering. Når en sårbarhed opdages efter release, skal der være en proces for at vurdere alvoren, udvikle en rettelse og rulle den ud til brugerne.
- Sikkerhedsopdateringer i hele supportperioden. Produktet skal kunne modtage sikkerhedsopdateringer. Efter CRA skal fabrikanten fastlægge en supportperiode, hvor sårbarheder håndteres effektivt, og slutdatoen skal angives tydeligt ved købet.
Tjekliste: Krav til softwareleverandører
Køber I software eller får udviklet løsninger hos en ekstern leverandør, skal kontrakten dække sikkerhed. Digitaliseringsstyrelsens opslagsværk om sikkerhedskrav bygger på ISO 27001 anneks A og CIS-kontroller, og kravene skal udvælges på baggrund af risikovurderinger. Brug nedenstående som udgangspunkt for dialogen:
- Dokumenteret udviklingsproces. Bed leverandøren beskrive, hvordan sikkerhed indgår i deres udviklingsforløb. En leverandør, der ikke kan svare, er et risikotegn.
- Krav til test og kvalitetssikring. Aftal, at leverandøren udfører sikkerhedstest før levering og dokumenterer resultaterne.
- Overblik over tredjepartskomponenter. Kræv en liste over biblioteker og komponenter, produktet bruger. Det giver jer mulighed for at reagere, hvis en komponent viser sig at have en sårbarhed.
- Sårbarhedshåndtering og opdateringer. Kontrakten skal beskrive, hvordan leverandøren håndterer sårbarheder, hvor hurtigt rettelser leveres, og hvordan I får besked.
- Supportperiode. Afklar, hvor længe leverandøren leverer sikkerhedsopdateringer. Når supporten ophører, skal I have en plan for at migrere eller afvikle produktet.
- Ret til audit eller dokumentation. For kritiske systemer kan det være relevant at kræve ret til at få indsigt i leverandørens sikkerhedspraksis eller modtage dokumentation fra en uafhængig revision.
Eksempel: Krav til en webshop-leverandør
Eksemplet er sitets eget, og tallene er fiktive.
En mellemstor virksomhed skal have udviklet en ny webshop og vælger en ekstern leverandør. Ledelsen formulerer følgende krav i kontrakten:
- Leverandøren skal levere en liste over alle open source-komponenter og deres versioner ved levering.
- Leverandøren skal udføre automatiseret sårbarhedsscanning af koden inden lancering og dele rapporten med kunden.
- Ved kritiske sårbarheder (med høj CVSS-score) forpligter leverandøren sig til at levere en rettelse inden for fem arbejdsdage.
- Leverandøren leverer sikkerhedsopdateringer i tre år efter lancering. Herefter genforhandles aftalen.
- Kunden modtager kvartalsvise rapporter om opdateringer og eventuelle sårbarheder.
Kravene giver virksomheden et grundlag for at holde leverandøren ansvarlig og følge op på sikkerheden løbende. Tallene i eksemplet er fiktive; hvad der er rimeligt, afhænger af systemet og aftalen.
Hvad guiden ikke dækker
Guiden handler om de krav, ledelsen skal stille, ikke om hvordan udviklere teknisk implementerer dem. Der er ingen kodeeksempler eller detaljerede tekniske standarder her. CRA stiller også krav til overensstemmelsesvurdering og rapportering af aktivt udnyttede sårbarheder — det er beskrevet i guiden om CRA.
Har I brug for at formulere mere detaljerede sikkerhedskrav, kan en rådgiver med erfaring i informationssikkerhed eller CRA-compliance hjælpe med at tilpasse kravene til jeres konkrete situation. Ved valg af rådgiver bør I spørge til deres erfaring med lignende virksomheder, om de kender de relevante standarder (som SSDF og ISO 27001), og hvordan de dokumenterer deres arbejde.
Næste skridt
Brug sikkerheds- og compliancetjekket til at se, om I har styr på de grundlæggende punkter — herunder leverandørstyring og beredskab. Skal I i gang med en ISO 27001-certificering, hvor leverandørkrav indgår som en del af styringssystemet, kan I læse mere i guiden om ISO 27001.
