DevSecOps Engineer

En DevSecOps engineer sørger for, at sikkerhed sker automatisk, mens softwaren bliver bygget. Rollen sidder mellem udviklerne, driften og sikkerhedsafdelingen. Målet er at finde sårbarheder i kode, afhængigheder og infrastruktur, før de når i produktion.

Det er ikke en rolle, der siger nej bagefter. Det er en rolle, der gør det svært at gøre det forkerte i første forsøg.

Typiske opgaver:

• Bygge sikkerhedsscanninger ind i CI/CD-pipelines: kodeanalyse (SAST), afhængighedsscanning (SCA) og container-scanning
• Bestemme hvornår et build skal stoppes, og hvornår det kun skal give en advarsel
• Sortere i scanningsresultater: vurdere alvor, luge falske positiver ud og prioritere hvad der rettes først
• Sikre infrastruktur som kode, fx Terraform-moduler, Helm-charts og Kubernetes-manifester
• Få hemmeligheder ud af koden: API-nøgler, certifikater og adgangskoder flyttes til en vault
• Lave trusselsmodellering sammen med et udviklingsteam, når en ny funktion designes
• Vedligeholde SBOM (softwarestykliste) og signere builds, så leverandørkæden kan verificeres
• Holde base-images og afhængigheder opdaterede, ofte med automatiske pull requests
• Rykke ud når en kritisk sårbarhed rammer, som det skete med Log4Shell i Log4j

En almindelig arbejdsdag starter tit med nattens scanninger og alarmer. Der ligger måske 40 nye fund. De færreste er reelle. Første time går med at skille støj fra det, der faktisk kan udnyttes.

Derefter kommer typisk en udvikler forbi, fordi pipelinen fejler på en sårbarhed i en pakke, ingen bruger aktivt. Det skal afgøres nu, ikke om en uge. Efter frokost kan der være review af en Terraform-ændring, der åbner en netværksregel lidt for bredt. Sidst på dagen går tiden med at skrive politik-kode, opdatere dokumentation eller sidde med et team, der skal lancere en ny service.

Meget af arbejdet er kommunikation. En DevSecOps engineer har sjældent mandat til at bestemme over udviklingsteams. Man overbeviser i stedet med værktøj, der er hurtigere at bruge end at omgå.

Hvor arbejder man? Softwarehuse og SaaS-virksomheder, banker og fintech, medicinal- og medicoindustrien, teleselskaber, offentlige it-leverandører og konsulenthuse. I Danmark er efterspørgslen størst i København og Aarhus, men rollen er ofte hybrid eller fuldt distribueret.

Hvilken lovgivning dækker denne rolle?
Faget kræver ingen autorisation, og titlen er ikke beskyttet. Men flere EU-regler definerer i praksis opgaverne. EU's NIS2-direktiv, som i Danmark er gennemført med cyber- og informationssikkerhedsloven, stiller krav om håndtering af sårbarheder og sikkerhed i leverandørkæden. EU's Cyber Resilience Act stiller krav til sikker udvikling, sårbarhedshåndtering og SBOM for produkter med digitale elementer. Arbejder man i finanssektoren, gælder desuden EU's DORA-forordning om digital operationel modstandsdygtighed, herunder test og kontrol af it-leverandører. Behandler systemet persondata, sætter databeskyttelsesforordningen (GDPR) krav om indbygget sikkerhed, hvilket Datatilsynet fører tilsyn med.

Der findes ingen dansk uddannelse, der hedder DevSecOps engineer. Stort set alle kommer ind via udvikling eller drift og specialiserer sig senere.

De almindeligste veje:

• Datamatiker på et erhvervsakademi, 2 år og 3 måneder. Den korteste og mest brugte vej ind i faget.
• Professionsbachelor i softwareudvikling, 1½ år oven på datamatiker.
• Diplomingeniør eller bachelor i softwareteknologi, it eller datalogi, typisk 3-3½ år.
• Kandidat i datalogi, softwareteknologi eller cybersikkerhed, 2 år oven på en bachelor. Aalborg Universitet udbyder blandt andet en kandidat i cybersikkerhed i København.
• IT-teknolog eller AP-uddannelse i it-sikkerhed på erhvervsakademi, cirka 2 år.

Adgangskravet til datamatiker er en gymnasial eksamen med matematik B, eller en relevant erhvervsuddannelse suppleret med matematik B. Kravene fremgår af Uddannelses- og Forskningsministeriets adgangsbekendtgørelse og opdateres på Adgangskortet.

Vejen efter uddannelsen er lige så vigtig. De fleste arbejder 3-5 år som udvikler, platform engineer, sysadmin eller cloud-drift, før de kaldes DevSecOps engineer. Man skal have kodet noget, der gik i produktion, og have haft ansvar for noget, der gik ned. Uden den erfaring bliver sikkerhedsrådene teoretiske.

Alternative veje ind:

• Fra udvikling: en backend-udvikler, der tager sikkerhedsopgaverne i teamet, glider ofte naturligt over.
• Fra drift: sysadmins og netværksfolk har allerede forståelsen for infrastruktur og adgangsstyring.
• Fra support eller SOC: analytikere fra et security operations center kan flytte mod udviklingssiden.
• Selvlært: der er reelt ansatte uden videregående uddannelse. Det kræver til gengæld et synligt GitHub-arbejde, hjemmelab og gerne bug bounty-fund.
• Faglært datatekniker med programmeringsspeciale, og derefter erfaring i et driftsteam.

Certificeringer er ikke et krav, men de bruges som filter i rekruttering. Relevante er Certified Kubernetes Security Specialist (CKS) fra Linux Foundation, AWS Certified Security – Specialty, Microsoft AZ-500 og SC-100, GIAC GCSA fra SANS Institute, samt OSCP fra OffSec for den offensive del. CISSP fra ISC2 kræver fem års erfaring og peger mere mod arkitekt- og lederroller.

Karriereveje videre er typisk security architect, cloud security engineer, platform engineer med sikkerhedsansvar, head of application security eller sikkerhedsrådgiver i et konsulenthus. Nogle går mod CISO-sporet, hvor teknikken fylder mindre og risikostyring, revision og NIS2-dokumentation fylder mere.

En DevSecOps engineer arbejder næsten altid i andres værktøjskæde. Man ejer sjældent koden, men man ejer det, der kører rundt om den.

Pipelines og versionsstyring: Git, GitHub Actions, GitLab CI, Azure DevOps, Jenkins og Argo CD.

Kodeanalyse (SAST): SonarQube, Semgrep og CodeQL. Bruges til at finde fejl direkte i kildekoden.

Afhængigheder og leverandørkæde (SCA): Dependabot, Renovate, Snyk og OWASP Dependency-Check. SBOM laves med Syft i formaterne CycloneDX eller SPDX, og builds signeres med Sigstore og cosign.

Containere og Kubernetes: Docker, Kubernetes, Helm, Trivy og Grype til image-scanning, Kyverno eller OPA Gatekeeper til politik-kode, og Falco til runtime-overvågning.

Infrastruktur som kode: Terraform, Bicep, Ansible og Pulumi. Scannes med Checkov, tfsec eller Terrascan før udrulning.

Hemmeligheder: HashiCorp Vault, Azure Key Vault og AWS Secrets Manager. Gitleaks og TruffleHog bruges til at finde nøgler, der allerede er havnet i et repository.

Test af kørende systemer (DAST): OWASP ZAP og Burp Suite.

Overvågning og logning: Prometheus, Grafana, Elastic, Wazuh og Microsoft Defender for Cloud.

Sprog: Python og Bash til automatisering, Go til værktøjer, plus rigtig meget YAML. Man behøver ikke være stærk i alle sprog i huset, men man skal kunne læse dem.

Rammeværk man bruger dagligt: OWASP Top 10, OWASP ASVS og SAMM, CIS Benchmarks til hærdning, NIST SSDF for sikker udvikling og MITRE ATT&CK til at beskrive angrebsteknikker. CVSS-scoren bruges til at prioritere sårbarheder, men den bør altid vurderes op mod, hvor systemet faktisk står.