Application Security Specialist

En application security specialist arbejder med sikkerheden i selve applikationen. Ikke firewalls og netværk, men koden, API'erne, bibliotekerne og den pipeline, der bygger og udruller det hele.

Rollen kaldes ofte AppSec. Den ligger tættere på udviklerne end på it-driften, og de fleste sidder fysisk sammen med udviklingsteamene.

Typiske opgaver:

• Gennemgå kode for sikkerhedsfejl: manglende validering, forkert adgangskontrol, hardkodede hemmeligheder.
• Lave trusselsmodellering på en ny funktion, før den bygges. Hvad kan misbruges, og hvad koster det os?
• Sætte scanninger op i CI/CD-kæden: SAST på koden, SCA på tredjepartspakker, DAST mod det kørende miljø.
• Rydde op i scanningsresultater. En stor del af arbejdet er at sortere falske positiver fra det, der faktisk skal rettes.
• Håndtere sårbarheder i afhængigheder, når en pakke pludselig har en kendt CVE.
• Køre eller bestille penetrationstest og følge op på rapporten sammen med teamet.
• Rette sikkerhedskrav ind i user stories, så de kommer i backloggen i stedet for at hænge i luften.
• Undervise udviklerne. Kodegennemgang med to udviklere lærer mere fra sig end et kursus.
• Deltage i hændelser, når noget er blevet udnyttet, og finde ud af hvordan.

En almindelig arbejdsdag er mest samarbejde. Formiddag med et team, der skal have gennemgået en ny betalingsintegration. Efter frokost oprydning i sårbarhedslisten og prioritering af, hvad der skal med i næste sprint. Sidst på dagen en pull request, hvor du kommenterer på, hvordan tokens håndteres.

Det svære er ikke at finde fejlene. Det er at få dem rettet. Udviklerne har travlt, produktchefen vil have funktioner, og din liste konkurrerer med alt andet. Du skal kunne forklare risikoen konkret nok til, at den bliver prioriteret, uden at blive den, der altid siger nej.

Mange steder er rollen bygget op omkring security champions. Det er udviklere i hvert team, der har sikkerhed som en ekstra kasket. Du lærer dem op og bruger dem som forlængede arme, fordi du ikke kan sidde i alle teams.

OWASP fylder meget i det daglige sprog. OWASP Top 10 bruges til at kategorisere fejl, og ASVS, altså Application Security Verification Standard, bruges som kravliste til, hvad en applikation skal leve op til.

Brancher der efterspørger faget: banker og fintech, hvor kravene er hårdest, softwarehuse og SaaS-virksomheder, medico og sundhedsteknologi, spil- og betalingsvirksomheder, de større konsulenthuse, og offentlige organisationer med egen udvikling som Skatteforvaltningen, ATP og regionerne.

Der er sjældent vagt i rollen. Til gengæld kan en alvorlig sårbarhed i en meget brugt pakke vende hele ugen på hovedet.

Hvilken lovgivning dækker denne rolle?
EU's NIS2-direktiv, som i Danmark gennemføres med NIS2-loven under Center for Cybersikkerhed, stiller krav om sikkerhed i leverandørkæden og om håndtering af sårbarheder i sektorer som energi, transport, sundhed og digital infrastruktur. Finansielle virksomheder er omfattet af EU's DORA-forordning, der kræver sikkerhedstest af kritiske systemer, herunder trusselsbaseret penetrationstest. EU's Cyber Resilience Act stiller krav til producenter af produkter med digitale elementer om sikker udvikling, en softwarestykliste og håndtering af sårbarheder i produktets levetid. Behandler applikationen personoplysninger, kræver databeskyttelsesforordningen (GDPR) desuden indbygget databeskyttelse og passende sikkerhed, hvilket Datatilsynet fører tilsyn med. Selve rollen kræver ingen autorisation, og certificeringer er efterspurgte, men ikke lovpligtige.

Der er ingen autorisation, og der findes ingen dansk uddannelse, der hedder application security. Alle kommer ind via en anden vej og specialiserer sig undervejs.

Typiske uddannelsesbaggrunde:

• Datamatiker, erhvervsakademiuddannelse på 2½ år inklusive praktik. Meget almindelig start.
• Professionsbachelor i softwareudvikling eller webudvikling, 1½ år oven på datamatiker.
• Professionsbachelor i it-sikkerhed, 3½ år. Udbydes blandt andet af Erhvervsakademi Aarhus, KEA og Zealand.
• Diplomingeniør eller civilingeniør i softwareteknologi, cybersikkerhed eller datateknik. DTU, Aalborg Universitet og Syddansk Universitet har cybersikkerhedsspor.
• Cand.scient. i datalogi med sikkerhedsfag.

Adgangskravene følger uddannelsen. Ifølge UddannelsesGuiden kræver datamatiker en gymnasial eksamen eller en relevant erhvervsuddannelse med matematik på mindst B-niveau. Ingeniøruddannelserne kræver typisk matematik A og fysik B.

Den mest almindelige vej ind er som udvikler først.
Du koder i nogle år, får interesse for sikkerhed, tager sikkerhedsopgaverne i teamet og bliver security champion. Derfra bliver det hele stillingen. Den vej er stærk, fordi troværdighed over for udviklere kommer af selv at have skrevet og vedligeholdt kode.

Andre veje ind:

• Fra penetrationstest eller red team, hvis du hellere vil forebygge end angribe.
• Fra DevOps, hvor pipeline, containere og hemmelighedshåndtering allerede er dit område.
• Fra en GRC- eller compliance-rolle, hvis du samtidig kan læse kode. Ellers bliver det svært at blive taget alvorligt i teamet.
• Fra it-support eller drift via hjemmelæring og hjemmelab. Det tager længere tid, men det sker.

Certificeringer der reelt tæller i Danmark:

• OSCP fra Offensive Security. Praktisk og respekteret, men mest offensiv.
• OSWE fra Offensive Security, som er den, der ligger tættest på applikationssikkerhed og kodegennemgang.
• Burp Suite Certified Practitioner fra PortSwigger. Konkret og prisbillig.
• CISSP fra ISC2, hvis du bevæger dig mod bredere sikkerhedsansvar. Kræver dokumenteret erfaring.
• CSSLP fra ISC2, specifikt rettet mod sikker softwareudvikling.
• GWAPT fra GIAC, hvis arbejdsgiveren betaler. Kurserne er dyre.

Gratis træning betyder mere end folk tror. PortSwigger Web Security Academy, OWASP Juice Shop og platforme som Hack The Box og TryHackMe er dét, folk faktisk har brugt, når man spørger dem.

Der går typisk to til fire år fra første udviklerjob til at kunne stå selvstændigt med AppSec-ansvar. Kodeforståelsen kan ikke springes over.

Karriereveje videre:

• Til AppSec lead eller product security manager med ansvar for et program på tværs af teams.
• Til security architect, hvor design og arkitektur fylder mere end kode.
• Til penetrationstester eller red teamer, hvis det offensive trækker.
• Til DevSecOps-specialist med fokus på pipeline, containere og cloud.
• Til CISO-sporet eller til en GRC-rolle med NIS2 og DORA.
• Til konsulent hos et sikkerhedshus, hvor du ser mange forskellige kodebaser.
• Til bug bounty på fuld tid eller som en betydelig sidegevinst.

Kodeanalyse:

• SAST-værktøjer, der scanner kildekoden: Semgrep, SonarQube, Snyk Code, Checkmarx eller Fortify.
• SCA-værktøjer, der finder kendte sårbarheder i tredjepartspakker: Snyk, Dependabot, OWASP Dependency-Check, Renovate.
• SBOM, altså softwarestykliste, i formaterne CycloneDX eller SPDX. Bliver et fast krav med EU's Cyber Resilience Act.
• Secret scanning, fx Gitleaks eller TruffleHog, mod nøgler der er endt i repoet.

Test af den kørende applikation:

• Burp Suite Professional. Det centrale værktøj til webtest og manuel undersøgelse af API'er.
• OWASP ZAP som gratis alternativ og til automatiseret DAST i pipelinen.
• Postman eller lignende til at pille ved API-kald og autorisationslogik.
• Nuclei til hurtige tjek mod kendte mønstre.

Pipeline og platform:

• GitHub Actions, GitLab CI, Azure DevOps eller Jenkins, hvor scanningerne skal ind uden at stoppe teamet.
• Container- og image-scanning med Trivy eller Grype.
• Politik som kode med OPA eller lignende, når krav skal håndhæves automatisk.
• Hemmelighedshåndtering i HashiCorp Vault, Azure Key Vault eller AWS Secrets Manager.
• Cloudsikkerhed i Azure, AWS eller GCP, især identiteter og rettigheder.

Metode og dokumentation:

• OWASP Top 10, ASVS og Cheat Sheet Series som fælles referencer.
• Trusselsmodellering med STRIDE, ofte i OWASP Threat Dragon eller bare på et whiteboard.
• CVSS til at score alvorligheden og CVE-databasen til kendte sårbarheder.
• Jira til at få fund ind i teamets backlog. Det er dér, en rettelse reelt bliver til noget.

Dertil kommer kodeforståelse i de sprog, huset bruger: typisk C#, Java, Python, JavaScript eller Go. Du behøver ikke være ekspert i alle, men du skal kunne læse dem og skrive et lille script selv.