Sikker udvikling og test
| Felt | Værdi |
|---|---|
| Kontrolområde | NIS2 art. 21, stk. 2, litra e (sikker udvikling og vedligeholdelse, håndtering af sårbarheder) og litra f (vurdering af foranstaltningernes effektivitet) |
| Version | 1.0 |
| Senest opdateret | 2026-09-28 |
Denne side beskriver, hvordan kode gennemgås og testes for sårbarheder, før og efter den er i produktion. Den supplerer afvigelserne, som forklarer, hvad vi bevidst ikke gør.
Kode-review
- Alle ændringer går gennem en pull request. Ingen ændringer udrulles uden om det.
- Kun en reviewer kan flette. Hovedgrenen er beskyttet med branch protection, og der er MFA på GitHub.
- Automatiske tests kører ved hver ændring: enheds-, integrations- og end-to-end-test, statisk analyse (
ruff) og typecheck (tyogtsc). - Produktion opdateres kun via CI/CD efter review og tests. Ingen medarbejdere logger ind på produktionsservere eller databasen i den daglige drift.
- Afhængigheder foreslås opdateret automatisk af Dependabot, og operativsystem og containerbilleder opdateres dagligt med sikkerhedsrettelser.
Adverserielle agenter
Ud over review og tests bruger vi adverserielle AI-agenter, der angriber vores egen kode og platform på samme måde, som en angriber ville. En adverseriel agent får til opgave at finde en sårbarhed og at bevise den, i stedet for at bekræfte, at koden ser rigtig ud. Fund, der ikke kan påvises, forkastes, så resultatet ikke er fyldt med støj.
| Hvad testes | Hvornår | Hvordan |
|---|---|---|
| Koden | Ved hver pull request | Agenter gennemgår ændringen for sårbarheder, fx injektion, SSRF ved udgående kald, hemmeligheder i logs eller svar, huller i adgangskontrol, path traversal og usikker deserialisering, og efterprøver deres egne fund. |
| Staging-miljøet | Hver uge | Agenter angriber den kørende platform i et testmiljø uden kundedata. |
Testene følger de klassiske sårbarhedskategorier, som OWASP Top 10 beskriver.
Hvad det ikke er
Adverserielle agenter er ikke en uafhængig penetrationstest. De giver hyppig og bred dækning, men de erstatter ikke en menneskelig, uafhængig tester, der ikke kender vores kode. Derfor har vi begge dele på planen.
Uafhængig penetrationstest
En uafhængig penetrationstest af platformen og API'erne er planlagt til at være gennemført inden vores ISAE 3000 type 1-erklæring, dvs. senest 12 måneder efter kontraktunderskrivelse. Testen er ikke gennemført i dag.
Rapporten indgår i kontrolgrundlaget for ISAE 3000-erklæringen. Kunder kan ved skriftlig anmodning få resuméet under fortrolighed, jf. DORA-erklæringen.
Kunder kan desuden gennemføre egne, afgrænsede penetrationstests af AgentBase i deres kontekst. Vi medvirker uden ekstra omkostninger og aftaler omfang og tidsrum på forhånd.
Hvad der er implementeret, og hvad der er planlagt
| Kontrol | Status |
|---|---|
| Pull request-review og branch protection | Implementeret |
| Automatiske tests, statisk analyse og typecheck ved hver ændring | Implementeret |
| Automatisk opdatering af afhængigheder og dagligt opdaterede servere | Implementeret |
| Adverserielle agenter mod koden ved hver pull request | Implementeret |
| Adverserielle agenter mod staging hver uge | Implementeret |
| Uafhængig penetrationstest | Planlagt inden ISAE 3000 type 1 |
| ISAE 3000 type 1-erklæring | Planlagt senest 12 måneder efter kontraktunderskrivelse |
Genvurdering
Siden gennemgås mindst én gang om året og hver gang testmetoden ændres.