Hvis du tror, at CRA og “secure-by-design” kun er noget for store enterprise-organisationer med compliance-afdelinger, så er du i farezonen: de nye krav rammer ofte først de teams, der leverer hurtigt, genbruger open source og integrerer mange tredjepartskomponenter.
I denne artikel får du et praktisk overblik over, hvad CRA betyder for mindre software- og produktteams, hvorfor det betaler sig at starte tidligt, og hvordan du kan gøre secure-by-design håndgribeligt uden at drukne i proces. Du får også konkrete takeaways, typiske faldgruber og realistiske måder at estimere indsats og omkostninger på.
Du behøver ikke være jurist for at komme i gang. Pointen er at bygge et minimum af sikkerhed og sporbarhed ind i dit produkt- og udviklingsflow, så du undgår panik-ombygninger, forsinkede releases og uventede kundekrav senere.
Hvad er CRA, og hvorfor betyder det noget for små teams?
CRA (Cyber Resilience Act) er en EU-forordning, der stiller krav til cybersikkerhed for digitale produkter og software, der bringes på markedet. Kort sagt: den lægger op til, at produkter skal være sikrere som standard, at sårbarheder håndteres systematisk, og at man kan dokumentere, hvad man har gjort.
For mindre teams betyder det især to ting: 1) sikkerhed bliver en del af “definition of done”, og 2) dokumentation og sporbarhed bliver en konkurrenceparameter, fordi kunder og partnere vil kræve den.
Mini-konklusion: CRA er ikke bare compliance; det er en ny baseline for, hvad “professionel software” forventes at kunne bevise om sin sikkerhed.
Hvorfor det er dyrere at vente: læringen fra virkelige produktforløb
Jeg har set samme mønster gentage sig i mindre teams: man prioriterer features og time-to-market, og sikkerhed bliver noget, man “tager senere”. Problemet er, at “senere” ofte betyder, at arkitekturen allerede er låst, integrationsfladen er vokset, og kundekravene er blevet skarpere.
Teknisk gæld med renter
Hvis du først tilføjer sikkerhed, når produktet har 20 integrationer, tre dataflows og en håndfuld microservices, så ender du med at “lime sikkerhed på”. Det giver typisk flere lag: ekstra gateways, ad hoc rate limiting, og hotfixes på auth, der aldrig helt passer ind. Resultatet er højere kompleksitet og flere fejl.
Den skjulte omkostning: tabt momentum
Det dyreste er ofte ikke udviklertimerne, men tabt momentum: releases bliver forsinket, QA bliver overbelastet, og teamet mister fokus. En enkelt kritisk sårbarhed i en kernekomponent kan tvinge jer til at stoppe alt andet i 1–2 uger, hvis I mangler overblik over dependencies og build-kæde.
Mini-konklusion: At starte tidligt handler ikke om perfektion, men om at undgå, at sikkerhed bliver en akut krise, der vælter jeres roadmap.
Secure-by-design i praksis: hvad det faktisk betyder for et lille team
Secure-by-design lyder stort, men i praksis handler det om at træffe bevidste standardvalg tidligt: hvordan I autentificerer, hvordan I logger, hvordan I håndterer secrets, og hvordan I patcher. For et mindre team er målet at etablere et “sikkert default-system”, så man ikke skal genopfinde sikkerhed for hver feature.
Fire principper, der giver mest effekt for mindst indsats
- Minimér angrebsfladen: færre åbne endpoints, færre privilegier, færre “midlertidige” admin-views.
- Byg med sikre defaults: secure cookies, korrekt CORS, stram CSP hvor muligt, og “deny by default” i adgange.
- Gør sårbarheder håndterbare: versionsstyr dependencies, fast patch-rytme og kendte owner-roller.
- Log og spor kritiske hændelser: login-forsøg, privilegieændringer, nøgle-API-kald og fejl i auth-flow.
Det er ikke nødvendigt at implementere alt på én gang. Men uden disse grundprincipper bliver sikkerhed hurtigt fragmenteret og svær at dokumentere.
Mini-konklusion: Secure-by-design er i høj grad “produktdisciplin”: faste standarder, få undtagelser og tydelig sporbarhed.
Hvad CRA typisk kræver i hverdagen: dokumentation, processer og beviser
Mange mindre teams bliver overraskede over, at “sikkerhed” ikke kun er kode. CRA-lignende krav (og kundernes forventninger i samme retning) skubber jer mod at kunne fremvise beviser: hvad gør I, når der findes en sårbarhed, hvilke komponenter bruger I, og hvordan ruller I patches ud?
De mest praktiske artefakter at have styr på
- SBOM (Software Bill of Materials): en liste over softwarekomponenter og versioner, så I kan reagere hurtigt ved CVE’er.
- Sårbarhedshåndtering: en enkel proces for triage, prioritering og rettelse (inkl. “hvem ejer hvad”).
- Secure development practices: kodestandarder, review-krav og baseline security-tests i CI.
- Incident-beredskab: hvem gør hvad, hvis I får en rapport om en kritisk fejl.
- Release- og patchpolitik: hvordan og hvor hurtigt kan I opdatere kunder.
Du kan starte med “lightweight” versioner: et repository med skabeloner, en enkel runbook og CI-automation, der genererer SBOM og kører scanning.
Mini-konklusion: Hvis I kan skabe en lille mængde dokumentation, der altid er opdateret via automation, er I allerede foran mange større organisationer.
Sådan kommer du i gang tidligt uden at bremse roadmap’et
Den mest realistiske tilgang for mindre teams er at indføre sikkerhed som små, kontinuerlige ændringer. Når jeg hjælper teams i gang, starter vi næsten altid med at skabe overblik og reducere “ukendte ukendte”. Det handler om at gøre sikkerhed til en del af leverancen, ikke en separat fase.
En god, praktisk indgang til krav og forventninger for netop udviklere og produktteams kan være CRA for softwareteams, fordi det typisk oversætter regulativ-sprog til konkrete aktiviteter i udviklingsflowet.
En 30-dages plan, der kan gennemføres af 2–6 personer
- Uge 1: Lav en enkel trusselsmodellering for 1–2 centrale user journeys (fx login + betaling eller dataeksport).
- Uge 1: Slå dependency scanning til i CI og få et baseline-billede af kendte sårbarheder.
- Uge 2: Indfør minimumskrav til secrets (ingen secrets i repo, rotation, og miljøadskillelse).
- Uge 2: Definér patch-SLA’er (fx kritisk: 72 timer, høj: 14 dage) og gør det synligt i backlog.
- Uge 3: Generér SBOM automatisk på build og gem artefakter pr. release.
- Uge 4: Skriv en 1-sides incident runbook og test den med et tabletop-scenarie.
Det er bevidst små skridt. Effekten kommer af, at I bygger en vane og et system, ikke et engangsprojekt.
Mini-konklusion: “Tidligt” betyder ikke “tungt”; det betyder, at I får sikkerhed ind i jeres standardarbejde, mens produktet stadig er formbart.
Hvad koster det? Realistiske estimater for mindre teams
Omkostningen afhænger af modenhed, stack og hvor meget I allerede har automatiseret. Men som tommelfingerregel kan et lille team ofte komme langt med 5–15% ekstra indsats i en periode, hvis man fokuserer på automation og standarder fremfor manuel kontrol.
Her er et realistisk billede af, hvor tid typisk går hen:
- Opsætning af CI-sikkerhedstjek (SAST, dependency scanning, SBOM): 0,5–3 dage afhængigt af pipeline og tooling.
- Stramning af auth, sessions og adgangskontrol: 2–10 dage afhængigt af nuværende design.
- Logging, audit events og alerting: 1–5 dage (mere hvis observability er umoden).
- Proces og skabeloner (triage, runbook, policy): 0,5–2 dage, hvis I holder det simpelt.
Det, der typisk bliver dyrt, er ikke værktøjer, men uforudsete refactors: hvis I fx har blandet interne servicekonti, bruger-roller og admin-adgang sammen, kan oprydning være et større arbejde.
Mini-konklusion: Den bedste investering er ikke flere møder, men automatiseret dokumentation og tidlige arkitekturvalg, der reducerer refactors.
Typiske fejl og faldgruber (og hvordan du undgår dem)
Mindre teams laver ofte de samme fejl, fordi de optimerer for hastighed. Det er forståeligt, men det kan gøres smartere uden at gøre alt tungt.
Faldgrube 1: “Vi fixer det, når vi får en kunde, der spørger”
Problemet er, at kundespørgsmålet ofte kommer, når I er midt i en vigtig leverance. Løsningen er at have et minimum af svar klar: SBOM, patchpolitik og en enkel sårbarhedsproces.
Faldgrube 2: For meget compliance-teater, for lidt sikkerhed
Det kan være fristende at skrive lange dokumenter. Men hvis de ikke er koblet til jeres CI/CD, bliver de forældede. Prioritér i stedet “levende” beviser: automatiske rapporter, release-artefakter og versioneret dokumentation.
Faldgrube 3: Uklar ejer af tredjepartskomponenter
Open source og SaaS-komponenter er fantastiske, men de kræver ejerskab. Udpeg en owner pr. kritisk dependency-klynge (fx auth-biblioteker eller PDF-generatorer), så patching ikke bliver “nogens problem”.
Mini-konklusion: Den største risiko i små teams er ikke ond vilje, men manglende ejerskab og manglende systematik.
Bedste praksis: en letvægts “secure-by-design” tjekliste til hver release
Når I har de første byggesten på plads, er næste skridt at gøre sikkerhed til en gentagelig rutine. Jeg anbefaler en kort tjekliste, der kan gennemgås på 5–10 minutter i forbindelse med release-kandidaten.
- Er der nye dependencies, og er SBOM opdateret automatisk?
- Har CI fundet nye kritiske sårbarheder, og er de triageret?
- Er der ændringer i adgangskontrol, roller eller privilegier, som kræver ekstra review?
- Er relevante audit events logget (auth, rettighedsændringer, dataeksport)?
- Er secrets håndteret korrekt (ingen hardcoding, korrekt miljø, rotation ved behov)?
- Er patch- og rollback-plan klar, hvis release skaber sikkerhedsproblemer?
Hvis I konsekvent kan svare “ja” til disse punkter, har I et stærkt fundament, der både hjælper mod CRA-krav og reducerer sandsynligheden for driftshændelser.
Mini-konklusion: En lille, fast release-rutine slår store, sjældne sikkerhedsprojekter — især når teamet er lille.
Hvad du kan gøre allerede i denne sprint
Hvis du kun tager én ting med, så lad det være dette: gør sikkerhed målbar og gentagelig. Det er sådan, små teams vinder over krav, der ellers virker designet til store organisationer.
- Tilføj dependency scanning og fail på kritiske findings (men start med “warn” i 1–2 uger, så I kan rydde op).
- Lav en enkel trusselsmodel på én vigtig user journey og omsæt den til 3 konkrete backlog-items.
- Definér en patchpolitik og gør den synlig (fx i README eller engineering handbook).
- Vælg 5 audit events, I altid logger, og sørg for at de kan findes igen.
- Aftal ejerskab: hvem tager imod sårbarhedsrapporter, og hvem beslutter prioritet?
Mini-konklusion: Når I kan vise, at I har styr på overblik, patching og ansvar, er I langt bedre stillet — både over for CRA og over for de sikkerhedskrav, der allerede kommer fra kunder og partnere.
