När jag arbetar med SAST och DAST försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. SAST och DAST ser olika delar av applikationsrisken: SAST analyserar kod eller representationer av kod medan DAST testar en körande tjänst från utsidan.
SAST och DAST i praktiken
Första byggstenen: SAST kan hitta dataflöden och osäkra API-anrop tidigt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: DAST kan se runtime-konfiguration, headers och faktiskt exponerade endpoints. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Båda metoderna kan ge false positives och behöver triage. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Kombinationen blir starkare när fynd kan kopplas till samma route eller kodägare. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Kör SAST nära pull request för snabb feedback.
- Kör DAST mot staging med realistisk konfiguration.
- Normalisera fynd och länka dem till komponent.
- Verifiera högprioriterade fynd manuellt.
- Skapa regressionstest när ett återkommande mönster har hittats.
För SAST och DAST håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
En osäker SQL-sträng kan synas i SAST innan applikationen körs. En felkonfigurerad cookie eller CSP syns däremot tydligare i DAST. Jag använder dem därför för olika frågor, inte som konkurrerande scanners.
Fallgropar jag försöker undvika
- Att blockera alla builds på otrierade scannerresultat.
- Att köra DAST mot fel miljö och tro att produktion är testad.
- Att anta att SAST ser autentiserings- och reverse-proxy-konfiguration som bara finns i runtime.
Kontrollpunkter
För SAST och DAST vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Ett verifierat fynd kan reproduceras.
- Fixen fångas i test eller rule suppression med motivering.
- Samma sårbarhetsklass minskar över tid.
Ett negativt test hör också till SAST och DAST: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
SAST och DAST – två olika frågor om samma applikation handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.