Har etableret et løbende sikkerhedsprogram — code scanning, DAST, afhængigheds- og sårbarhedstjek, SBOM‑generering, secret scanning og SHA‑pinnede actions — sammen med 21 skrevne sikkerhedsaudits.

Situation. Sikkerhedsarbejdet inde i applikationen — Content‑Security‑Policy’en, least‑privilege‑databaserollerne, gentjekket af rettigheder — beskytter platformen ved runtime. Intet af det siger noget om det, der bliver sendt afsted: om en dependency samlede en kendt sårbarhed op i tirsdags, om en adgangsoplysning blev committet og rullet tilbage, eller om en third‑party‑action pinnet til et tag stille og roligt er blevet til et andet stykke kode.

Opgave. Supply chain- og kodesikkerhed skulle være løbende og automatiseret, så tilstanden af det var et build‑resultat frem for en holdning.

Handling. Statisk analyse kører gennem CodeQL, dynamisk test mod en kørende instans gennem ZAP, og Go‑dependencies tjekkes med govulncheck. En SBOM genereres ved hvert build med Anchore og Syft, så det, der blev sendt afsted, er kendt frem for rekonstrueret bagefter. Gitleaks scanner historikken for adgangsoplysninger. Hver third‑party GitHub Action er pinnet til en commit‑hash frem for et tag, hvilket er den uglamourøse kontrol, der forhindrer, at et tag bliver flyttet under dig. Dependabot holder øje med 6 økosystemer. Ved siden af automatiseringen ligger 21 skrevne sikkerhedsaudits, heriblandt en threat model og en vurdering op mod OWASP‑testguiden — for scannere finder de klasser af problemer, nogen allerede har beskrevet, og en threat model er der, hvor dem, der er specifikke for netop denne platform, får et navn.

Resultat. En sårbarhed, der bliver offentliggjort upstream, dukker op som et fejlende build frem for som en nyhed. Mængden af fund er den reelle omkostning — en scanner, der rapporterer alt, træner folk i at ignorere den, og at holde signalet brugbart kræver løbende triage frem for en engangsopsætning.