Introduktion
Dette er IT Minds’ politik for, hvordan vi udvikler sikkert. Den er et praktisk udgangspunkt for udviklere, der bygger løsninger med ansvar, kvalitet og robusthed for øje. Sikkerhed er en naturlig del af arbejdet, og vi forventer, at alle som arbejder med kode tager det alvorligt.
Anvendelsesområde
Politikken gælder for alle faser af softwareudvikling og -drift: fra krav, design og arkitektur over kode og test til deployment, drift og support. Den gælder for interne løsninger, kundetilpassede projekter og eksternt arbejde med leverandører.
Denne politik er et baseline der angiver minimumskravene for, hvordan vi udvikler og leverer sikkert. Kunder kan stille strengere krav, men de kan ikke få os til at komme under denne standard. Hvis en kunde beder om at bryde politikken, skal sagen eskaleres til projektleder, sikkerhed og ledelsen.
Formål
Målet er enkelt:
- undgå ubehagelige overraskelser i produktion,
- sørge for at vi kan stå på mål for vores løsninger over for kunder og auditorer,
- gøre sikkerhed til noget vi bygger ind, ikke noget vi limer på til sidst.
Professionel standard
Vi forventer, at vores udviklere:
- kender deres værktøjer og teknologier,
- behandler sikkerhed som en naturlig del af god kode,
- ikke sender kode i produktion før den er gennemgået og testet.
Denne politik er for folk, der vil lave solide løsninger, ikke for dem der leder efter omskrivning af generiske retningslinjer.
Roller og ansvar
Udviklere ejer kvaliteten af deres egen kode. Det betyder at du:
- skriver med security mind-set,
- undgår at tabe hemmeligheder i repoet,
- svarer på review-spørgsmål og bidrager til bedre arkitektur.
Projektledere og teknikere sørger for, at sikkerhedskrav kommer ind i backloggen og prioriteres. Sikkerhedsteamet hjælper med review, trusselsmodeller og risikovurderinger, men det er ikke deres job alene.
Sikker udviklingslivscyklus
Sikkerhed skal gennemsyre processen. Vi laver trusselsmodeller og arkitekturreview tidligt, og vi evaluerer risici løbende. Tidlig opdagelse er billigere end panik i produktion.
Kode og udviklingspraksis
- Valider input i både frontend og backend.
- Følg princippet om mindst privilegium.
- Hardkodede adgangstaster, API-nøgler og hemmeligheder hører ikke hjemme i koden.
- Brug sikkert design og etablerede patterns fremfor quick-fixes.
Komponenter og afhængigheder skal være opdaterede, understøttede og kendt for deres sikkerhed. Hvis du bruger open source, så ved du også hvem der vedligeholder det.
Dependency management og secrets
Afhængigheder vurderes på kvalitet, sikkerhed og livscyklus. Ubrugte eller ubeskyttede pakker ryger ud.
Secrets skal opbevares i godkendte løsninger og må aldrig hardkodes i repoer, konfiguration eller dokumentation. Tjek altid, at dit build- og deploymentflow ikke lækker variables eller tokens.
Test og kvalitetssikring
Sikkerhedstest er ikke valgfri. Vores teststrategi skal dække både:
- automatiseret statisk analyse,
- dynamiske sikkerhedsscanninger,
- gennemgang af sikkerhedskritiske features.
Der er ikke noget ved at have test, der ikke er relevante for den konkrete risiko. Vi vil se dokumentation for, at OWASP Top 10 og relevante sikkerhedsprincipper er overvejet.
CI/CD og deployment
CI/CD-pipelines er en del af sikkerheden. De skal være sikret med adgangskontrol, separeret miljøer og auditering. Deployment må ikke være en manuel gættekonkurrence.
Produktionsadgang er begrænset til dem, der reelt har brug for det, og alle ændringer skal være sporbare.
Databeskyttelse og dataminimering
Vi bruger helst syntetiske eller anonymiserede data i udvikling og test. Persondata og fortrolige oplysninger skal kun bruges, hvis der er en klar, godkendt grund. Logs må aldrig indeholde følsomme oplysninger uden masking eller pseudonymisering.
Leverandører og eksterne komponenter
Eksterne services og komponenter vurderes kritisk. Hvis en leverandør skal ind i vores pipeline eller løsning, skal de kunne dokumentere deres sikkerhed og overensstemmelse. Vi accepterer ikke sort boks-løsninger uden gennemsigtighed.
Praktisk sund fornuft
Denne politik handler om at tage ansvar og bruge fornuft. Følgende er ikke bare anbefalinger - det er forventet adfærd:
- løser du en bug? Tjek at den ikke introducerer nye sikkerhedsrisici.
- ændrer du systemarkitektur? Revurder dine trusselsmodeller.
- skriver du kode? Sørg for, at du kan forklare den overfor kunde eller auditor.
Vi bygger løsninger, der står distancen, både teknisk og i forhold til kundens tillid.
Revision
Denne politik revideres mindst én gang årligt og ved væsentlige ændringer i teknologi, trusselsbillede eller lovgivning.