Sikker SDLC samt SAST- og DAST-værktøjer

Trusselsmodellering identificerer og dokumenterer systematisk sikkerhedstrusler under designfasen. Modellen STRIDE kategoriserer trusler i: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service og Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) er en risikocentreret metode, der simulerer angriberes mål. Trusselsmodeller resulterer i prioriterede modforanstaltninger, før en eneste kodelinje er skrevet.

SAST (white-box-test) analyserer kildekode, bytekode eller binære filer uden at køre applikationen og søger efter kodemønstre, der forbindes med kendte sårbarheder. SAST-værktøjer kan hurtigt scanne hele kodebasen og rapportere problemer som hardkodede legitimationsoplysninger, steder, der kan føre til SQL-injektion, og usikker deserialisering. De kører i IDE'en eller CI-pipelinen og rapporterer fund med fil- og linjenumre, så de er enkle at afhjælpe.

En vigtig begrænsning ved SAST er tendensen til at producere falske positiver — kode markeres som sårbar, selv om den faktisk er sikker. Denne alarmtræthed får udviklere til at afvise fund uden at undersøge dem. SAST-værktøjer kan heller ikke opdage problemer i runtime-konfigurationen, godkendelsesfejl, der afhænger af adfærd under kørsel, eller sårbarheder i kald til tredjeparts-API'er. SAST er mest effektivt, når det kombineres med træning af udviklerne, så fundene triageres korrekt.

DAST (black-box-test) tester en kørende applikation ved at sende angrebspayloads til dens HTTP-slutpunkter og analysere svarene for tegn på sårbarheder. DAST kræver ikke adgang til kildekoden — applikationen testes, som en angriber ville teste den. Det er særligt effektivt til at finde problemer under kørsel som omgåelse af godkendelse, XSS, der afspejles i svar, og forkert konfiguration af serveren. DAST-værktøjer omfatter OWASP ZAP, Burp Suite og Netsparker.

SAST og DAST supplerer hinanden i stedet for at konkurrere. SAST finder problemer på kodeniveau tidligt og integreres med IDE'en, men har ingen indsigt i adfærd under kørsel. DAST finder sårbarheder under kørsel og kræver ingen kildekode, men kan ikke scanne kodestier, som ikke udløses af de automatiserede sonder. Ved at bruge begge dele — SAST i CI-pipelinen og DAST mod et testmiljø — maksimeres dækningen af sårbarheder på tværs af SDLC'en.

IAST kombinerer aspekter af både SAST og DAST ved at instrumentere applikationen under kørsel. En IAST-agent kører inde i applikationen (på serveren) og observerer kodeudførelsen, mens testtrafikken bevæger sig igennem den. Den kan følge kompromitterede brugerinput gennem kodestier til følsomme sink-punkter og dermed finde sårbarheder med færre falske positiver end ren SAST. IAST er særligt effektivt i Java- og .NET-applikationer og integreres naturligt i funktionelle testkørsler.

Software Composition Analysis (SCA) identificerer open source-biblioteker og tredjepartsafhængigheder i en applikation og kontrollerer dem mod sårbarhedsdatabaser (NVD, OSV). Moderne applikationer kan trække hundredvis af afhængigheder ind — mange transitivt — så SCA-værktøjer som OWASP Dependency-Check, Snyk og Renovate er afgørende for at opdage kendte CVE'er, før angribere udnytter dem i din forsyningskæde.

Integration af sikkerhedsværktøjer i CI/CD-pipelines sikrer, at ingen kode når produktionen uden at bestå sikkerhedskontroller. En typisk DevSecOps-pipeline kører: SAST ved hver commit, SCA ved ændringer i afhængigheder, scanning af containerafbildninger før de sendes til et register, IaC-scanning for Terraform/CloudFormation og DAST mod en implementering i et testmiljø. Mislykkede sikkerhedskontroller blokerer buildet og håndhæver en kultur, hvor sikkerhed er standardindstillingen.

Automatiserede værktøjer kan ikke erstatte menneskelig kodegennemgang med fokus på sikkerhedslogik. En fagfællebedømmelse bør kontrollere, at godkendelses- og autorisationskontroller er placeret korrekt, at fejlhåndtering ikke lækker følsomme oplysninger, at kryptografiske funktioner bruger godkendte algoritmer og parametre, og at forretningslogikken ikke kan omgås. Sikkerhedsambassadører i udviklingsteams — udviklere med sikkerhedstræning — bygger bro mellem sikkerhedsteamet og udviklingen.

I denne lektion har du lært, at den sikre SDLC integrerer sikkerhed i alle udviklingsfaser i stedet for at føje den til sidst, at SAST analyserer kode uden at køre den, mens DAST tester kørende applikationer, og at SCA identificerer sårbare open source-afhængigheder, mens CI/CD-sikkerhedskontroller automatisk håndhæver fund. Næste emne er katalogtjenester med LDAP og Active Directory.