Har kørt et løbende sikkerhedsscanningsprogram

Situation. Sikkerhedsarbejdet inde i applikationen — Content‑Security‑Policy’en, least‑privilege‑databaserollerne, den gentagne kontrol af rettigheder — beskytter platformen under kørsel. Intet af det siger noget om det, der bliver leveret: om en afhængighed fik en kendt sårbarhed i tirsdags, om en adgangsoplysning blev committet og rullet tilbage, eller om en action fra en tredjepart, der er låst til et tag, i det stille er blevet til et andet stykke kode.

Opgave. Sikkerheden i forsyningskæden og koden skulle være løbende og automatiseret, så status var et buildresultat og ikke en holdning.

Handling. Statisk analyse kører gennem CodeQL, dynamisk test mod en kørende instans gennem ZAP, og Go‑afhængigheder tjekkes med govulncheck. En SBOM genereres ved hvert build med Anchore og Syft, så man ved, hvad der blev leveret, i stedet for at skulle rekonstruere det bagefter. Gitleaks gennemsøger historikken efter adgangsoplysninger. Hver GitHub Action fra en tredjepart er låst til en commit‑hash og ikke til et tag, hvilket er den uglamourøse kontrol, der forhindrer, at et tag bliver flyttet bag ens ryg. Dependabot holder øje med 6 økosystemer. Ved siden af automatiseringen ligger 21 skriftlige sikkerhedsgennemgange, heriblandt en trusselsmodel og en vurdering op mod OWASP‑testguiden — for scannere finder de typer problemer, som nogen allerede har beskrevet, og det er i en trusselsmodel, at de problemer, der er særlige for netop denne platform, får et navn.

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