DevSecOps: flytting av sikkerhet til venstre i pipelinene

Å flytte sikkerheten til venstre betyr å integrere sikkerhetsaktiviteter tidligere i livssyklusen for programvareutvikling – i utviklerens IDE, i kodegjennomganger og i CI/CD-pipelinen – i stedet for å teste sikkerheten som en siste kontroll før utrulling. Tradisjonelle sikkerhetsgjennomganger fant sted på slutten av utviklingssyklusen, noe som gjorde rettinger kostbare og tidkrevende. Det koster omtrent 100 ganger mindre å rette en sårbarhet under utviklingen enn å oppdage den i produksjon etter et sikkerhetsbrudd.

DevSecOps utvider DevOps-modellen ved å integrere sikkerhet som et felles ansvar på tvers av utviklings-, drifts- og sikkerhetsteam gjennom hele SDLC-en. Målet er å automatisere sikkerhetstesting slik at den kjøres i alle faser uten å forsinke leveransen. Sikkerhet blir en kontinuerlig egenskap ved pipelinen i stedet for et engangskontrollpunkt. I modne DevSecOps-programmer får utviklere tilbakemelding om sikkerhet i løpet av sekunder etter at de har skrevet kode, ikke uker etter en manuell gjennomgang.

SAST (Static Application Security Testing) analyserer kildekode, bytekode eller binærkode uten å kjøre applikasjonen. SAST-verktøy søker etter mønstre som tyder på sårbarheter: SQL-sammenkobling, utdata som ikke er renset, bruk av forbudte funksjoner, hardkodet påloggingsinformasjon og usikker bruk av kryptografi. SAST kjøres i CI-pipelinen ved hver commit og oppdager problemer før de når QA eller produksjon. Populære verktøy omfatter Semgrep, SonarQube, Checkmarx og Veracode.

DAST (Dynamic Application Security Testing) tester en applikasjon som kjører, ved å sende ondsinnede nyttelaster og observere svarene — som en simulering av en reell angripers atferd. I motsetning til SAST finner DAST sårbarheter som bare oppstår under kjøring: svakheter i autentisering, problemer med økthåndtering, feil i forretningslogikken og injeksjonssårbarheter i komplekse dataflyter. Populære DAST-verktøy omfatter OWASP ZAP (gratis), Burp Suite Enterprise og Acunetix. DAST kjøres mot et staging-miljø i pipelinen.

Containeravbilder bygges fra basisavbilder som inneholder operativsystempakker, språkkjøremiljøer og applikasjonsavhengigheter — alle potensielle kilder til kjente sårbarheter. Verktøy for skanning av containeravbilder analyserer avbildningslagene og identifiserer sårbare pakker. Trivy (gratis og rask), Grype (Anchore) og Clair er mye brukt. Skanninger kjøres som en del av pipelinen for bygging av avbildet og hindrer at avbilder med kritiske CVE-er promoteres til produksjonsregistre.

IaC-sikkerhetsskanning analyserer Terraform, CloudFormation, Kubernetes-manifester og Helm-diagrammer for feilkonfigurasjoner før de tas i bruk. Verktøy som Checkov og tfsec ser etter brudd som: S3-bøtter uten kryptering på serversiden, sikkerhetsgrupper som tillater all innkommende trafikk, IAM-roller med jokertegntillatelser og Kubernetes-pods som kjører som root. IaC-skanning hindrer feilkonfigurasjoner i skyen før de når noe miljø.

Verktøy for skanning etter hemmeligheter undersøker kildekode og commiter etter påloggingsinformasjon som er tatt med ved et uhell. Verktøy som truffleHog, GitLeaks og detect-secrets skanner git-historikk og nye commiter etter mønstre som samsvarer med API-nøkler, tilkoblingsstrenger, private nøkler og JWT-tokener. Som en pre-commit-hook blokkerer skanning etter hemmeligheter commiter som inneholder påloggingsinformasjon. Som en CI-port skanner den alle filer i repositoriet ved hver push og feiler bygget hvis det oppdages hemmeligheter.

Trusselmodellering er en strukturert prosess for å identifisere sikkerhetskrav og designfeil før koden skrives. STRIDE-modellen (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) hjelper team med å kartlegge trusler mot et systems dataflytdiagram på en systematisk måte. Trusselmodelleringsøkter gjennomføres under designfasen og resulterer i en prioritert liste over trusler som danner grunnlag for sikkerhetskrav og valg av regler for SAST/DAST.

DevSecOps-piper implementerer sikkerhetskontroller enten som blokkerende porter (bygget feiler og utrulling hindres) eller som rådgivende kontroller (funn rapporteres, men utrullingen kan fortsette). Funn med kritisk eller høy alvorlighetsgrad fra SAST, containerskanning og deteksjon av hemmeligheter blokkerer vanligvis. Funn med middels eller lav alvorlighetsgrad genererer varsler eller saker uten å blokkere. Denne balansen hindrer sikkerhet i å stanse all levering, samtidig som den sørger for at virkelig farlige forhold ikke automatisk når produksjon.

DevSecOps-programmer bør måles ved hjelp av tydelige måltall. Viktige måltall omfatter: Mean Time to Remediate (MTTR) for funn med høy alvorlighetsgrad, sårbarhetstetthet (funn per 1 000 kodelinjer over tid), lekkasjerate (andelen sårbarheter som oppdages etter produksjonssetting sammenlignet med før produksjonssetting) og bestått-rate for sikkerhetsporter i pipelinen. Ved å følge utviklingen i disse måltallene over tid kan man vise hvor effektivt programmet er, og styre beslutninger om investeringer i flere verktøy eller mer opplæring.

Den vanskeligste delen av DevSecOps er kulturell, ikke teknisk. Sikkerhet må bli alle utvikleres ansvar, ikke bare sikkerhetsteamets. Dette krever: sikkerhetsopplæring for utviklere (bevissthet om sikker koding), sikkerhetsforkjempere som er integrert i utviklingsteamene, skyldfrie ettergranskinger når sårbarheter når produksjon (fokus på prosessforbedring, ikke straff) og støtte fra ledelsen til å akseptere avveininger mot leveringshastigheten når reell sikkerhetsrisiko krever det. Teknologi uten en kulturendring fører til skanneverktøy som utviklerne lærer seg å ignorere.

I denne leksjonen har De lært at DevSecOps integrerer SAST, DAST, skanning etter hemmeligheter, containerskanning og IaC-skanning som automatiserte porter i pipelinen, at blokkering av funn med høy alvorlighetsgrad hindrer farlige forhold i å nå produksjon, og at det å flytte sikkerheten til et tidligere stadium reduserer kostnadene ved feilretting betydelig ved å oppdage sårbarheter under utviklingen i stedet for etter utrulling. Deretter skal vi se nærmere på fysiske sikkerhetskontroller for anlegg og datasentre.