Säker SDLC samt SAST- och DAST-verktyg

Secure Software Development Lifecycle (SSDLC) integrerar säkerhetsaktiviteter i alla faser av programvaruutvecklingen — från krav genom design, kodning, testning, driftsättning och underhåll. Den traditionella SDLC-modellen behandlar säkerhet som en kontroll i slutskedet, vilket är dyrt och ineffektivt. Grundtanken med en säker SDLC är att hitta och åtgärda sårbarheter så tidigt som möjligt, eftersom fel som upptäcks under designfasen kostar betydligt mindre att åtgärda än fel som upptäcks i produktion.

Shift left innebär att säkerhetsarbetet flyttas tidigare i utvecklingens tidslinje, i stället för att läggas till i slutet. I praktiken innebär det att säkerhetskrav inkluderas i användarberättelser, att hotmodellering genomförs under designfasen, att kodgranskning och SAST utförs under utvecklingen samt att DAST körs före lansering. Team som arbetar enligt shift left upptäcker sårbarheter när de är billigast att åtgärda — under utvecklingen, inte i produktion.

Hotmodellering identifierar och dokumenterar systematiskt säkerhetshot under designfasen. Modellen STRIDE kategoriserar hot i: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service och Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) är en riskcentrerad metod som simulerar angripares mål. Hotmodeller resulterar i prioriterade motåtgärder innan en enda kodrad har skrivits.

SAST (white-box-testning) analyserar källkod, bytekod eller binärer utan att köra applikationen och söker efter kodmönster som förknippas med kända sårbarheter. SAST-verktyg kan snabbt skanna hela kodbasen och rapportera problem som hårdkodade autentiseringsuppgifter, målpunkter för SQL-injektion och osäker deserialisering. De körs i IDE:n eller CI-pipelinen och rapporterar resultat med fil- och radnummer, vilket gör åtgärdandet enkelt.

En viktig begränsning hos SAST är tendensen att generera falska positiva resultat — kod flaggas som sårbar trots att den faktiskt är säker. Denna varningströtthet gör att utvecklare avfärdar resultat utan att undersöka dem. SAST-verktyg kan inte heller upptäcka problem i körningskonfigurationen, autentiseringsbrister som beror på körningsbeteende eller sårbarheter i anrop till tredjeparts-API:er. SAST är mest effektivt när det kombineras med utvecklarutbildning, så att resultaten prioriteras och bedöms korrekt.

DAST (black-box-testning) testar en applikation som körs genom att skicka attackpayloader till dess HTTP-slutpunkter och analysera svaren efter tecken på sårbarheter. DAST kräver inte åtkomst till källkoden — applikationen testas på samma sätt som en angripare skulle göra. Metoden är särskilt effektiv för att hitta problem under körning, till exempel kringgående av autentisering, XSS som reflekteras i svar och felkonfiguration av servern. DAST-verktyg omfattar OWASP ZAP, Burp Suite och Netsparker.

SAST och DAST kompletterar varandra i stället för att konkurrera. SAST hittar problem på kodnivå tidigt och integreras med IDE:n, men har ingen insyn i beteendet under körning. DAST hittar sårbarheter under körning och kräver ingen källkod, men kan inte skanna kodvägar som inte aktiveras av de automatiserade sonderingarna. Genom att använda båda — SAST i CI-pipelinen och DAST mot en stagingmiljö — maximeras täckningen av sårbarheter i hela SDLC:n.

IAST kombinerar aspekter av både SAST och DAST genom att instrumentera applikationen under körning. En IAST-agent körs inuti applikationen (på servern) och observerar kodkörningen när testtrafik passerar genom den. Den kan koppla spårad användarinmatning genom kodvägar till känsliga målpunkter och därmed hitta sårbarheter med färre falska positiva resultat än ren SAST. IAST är särskilt effektivt i Java- och .NET-applikationer och integreras naturligt i funktionella testkörningar.

Software Composition Analysis (SCA) identifierar bibliotek med öppen källkod och tredjepartsberoenden i en applikation och kontrollerar dem mot sårbarhetsdatabaser (NVD, OSV). Eftersom moderna applikationer kan hämta hundratals beroenden — många transitiva — är SCA-verktyg som OWASP Dependency-Check, Snyk och Renovate nödvändiga för att upptäcka kända CVE:er innan angripare utnyttjar dem i leveranskedjan.

Genom att integrera säkerhetsverktyg i CI/CD-pipelines säkerställs att ingen kod når produktion utan att först passera säkerhetskontroller. En typisk DevSecOps-pipeline kör: SAST vid varje commit, SCA när beroenden ändras, skanning av containeravbildningar före push till registret, IaC-skanning för Terraform/CloudFormation samt DAST mot en stagingdistribution. Underkända säkerhetskontroller stoppar bygget och upprätthåller en kultur där säkerhet är standard.

Automatiserade verktyg kan inte ersätta mänsklig kodgranskning med fokus på säkerhetslogik. Kollegial granskning bör verifiera att autentiserings- och auktoriseringskontroller finns på rätt platser, att felhanteringen inte läcker känslig information, att kryptografiska funktioner använder godkända algoritmer och parametrar samt att affärslogiken inte kan kringgås. Security champions i utvecklingsteam — utvecklare med säkerhetsutbildning — överbryggar gapet mellan säkerhetsteamet och utvecklingen.

I den här lektionen har följande behandlats: en säker SDLC integrerar säkerhet i alla utvecklingsfaser i stället för att lägga till den i slutet, SAST analyserar kod utan körning medan DAST testar applikationer som körs och SCA identifierar sårbara beroenden med öppen källkod, medan säkerhetskontroller i CI/CD-pipelines automatiskt verkställer resultaten. Härnäst behandlas katalogtjänster med LDAP och Active Directory.