DevSecOps: beveiliging naar links verschuiven in pipelines

Beveiliging naar voren halen betekent dat je beveiligingsactiviteiten eerder in de levenscyclus van softwareontwikkeling integreert — in de IDE van de ontwikkelaar, tijdens codebeoordeling en in de CI/CD-pijplijn — in plaats van beveiliging pas als laatste controle vóór de implementatie te testen. Traditionele beveiligingsbeoordelingen vonden aan het einde van de ontwikkelcyclus plaats, waardoor oplossingen duur en tijdrovend werden. Een kwetsbaarheid tijdens de ontwikkeling vinden, kost ongeveer 100 keer minder om te verhelpen dan wanneer je deze na een inbreuk in productie ontdekt.

DevSecOps breidt het DevOps-model uit door beveiliging gedurende de hele SDLC als een gedeelde verantwoordelijkheid van ontwikkel-, operations- en beveiligingsteams te integreren. Het doel is om beveiligingstests te automatiseren, zodat ze in elke fase worden uitgevoerd zonder de oplevering te vertragen. Beveiliging wordt zo een doorlopend kenmerk van de pijplijn in plaats van een eenmalig controlepunt. In volwassen DevSecOps-programma's krijgen ontwikkelaars binnen enkele seconden nadat ze code hebben geschreven feedback over beveiliging, in plaats van weken na een handmatige beoordeling.

SAST (statische beveiligingstests van toepassingen) analyseert broncode, bytecode of binaire code zonder de toepassing uit te voeren. SAST-tools zoeken naar patronen die op kwetsbaarheden wijzen: SQL-samenvoeging, niet-geschoonde uitvoer, gebruik van verboden functies, hardgecodeerde inloggegevens en onveilig gebruik van cryptografie. SAST wordt bij elke commit in de CI-pijplijn uitgevoerd, zodat problemen worden gevonden voordat ze QA of productie bereiken. Populaire tools zijn onder andere Semgrep, SonarQube, Checkmarx en Veracode.

DAST (dynamische beveiligingstests van toepassingen) test een draaiende toepassing door schadelijke ladingen te verzenden en reacties te observeren — als simulatie van het gedrag van een echte aanvaller. In tegenstelling tot SAST vindt DAST kwetsbaarheden die alleen tijdens runtime optreden: fouten in authenticatie, problemen met sessiebeheer, fouten in bedrijfslogica en injectiekwetsbaarheden in complexe gegevensstromen. Populaire DAST-tools zijn onder andere OWASP ZAP (gratis), Burp Suite Enterprise en Acunetix. DAST wordt in de pijplijn uitgevoerd tegen een testomgeving.

Containerimages worden opgebouwd vanuit basisimages die besturingssysteempakketten, taalruntimes en afhankelijkheden van toepassingen bevatten — allemaal mogelijke bronnen van bekende kwetsbaarheden. Tools voor het scannen van containerimages analyseren imagelagen en identificeren kwetsbare pakketten. Trivy (gratis en snel), Grype (Anchore) en Clair worden veel gebruikt. Scans worden uitgevoerd als onderdeel van de pijplijn voor het opbouwen van de image. Zo wordt voorkomen dat images met kritieke CVE's naar productieregisters worden gepromoveerd.

IaC-beveiligingsscans analyseren Terraform, CloudFormation, Kubernetes-manifesten en Helm-charts op onveilige configuraties voordat ze worden toegepast. Tools zoals Checkov en tfsec controleren op overtredingen zoals S3-buckets zonder versleuteling aan de serverzijde, beveiligingsgroepen die al het inkomende verkeer toestaan, IAM-rollen met jokertekenmachtigingen en Kubernetes-pods die als root draaien. IaC-scans voorkomen onveilige cloudconfiguraties voordat die een omgeving bereiken.

Tools voor het scannen van geheimen controleren broncode en commits op per ongeluk opgenomen inloggegevens. Tools zoals truffleHog, GitLeaks en detect-secrets scannen de Git-geschiedenis en nieuwe commits op patronen die overeenkomen met API-sleutels, verbindingsreeksen, privésleutels en JWT-tokens. Als pre-commit-hook voorkomt het scannen van geheimen dat commits met inloggegevens worden uitgevoerd. Als CI-controle scant het bij elke push alle bestanden in de opslagplaats en mislukt het bouwen als er geheimen worden gevonden.

Dreigingsmodellering is een gestructureerd proces om beveiligingsvereisten en ontwerpfouten te identificeren voordat er code wordt geschreven. Het STRIDE-model (Spoofing, Manipatie, Ontkenning, Informatieverstrekking, Denial-of-Service en Privilege-escalatie) helpt teams om systematisch dreigingen tegen het gegevensstroomdiagram van een systeem in kaart te brengen. Sessies voor dreigingsmodellering vinden plaats tijdens het ontwerp en leveren een geprioriteerde lijst met dreigingen op. Die lijst bepaalt de beveiligingsvereisten en helpt bij het kiezen van regels voor SAST en DAST.

DevSecOps-pijplijnen implementeren beveiligingscontroles als blokkerende controles (de build mislukt en implementatie wordt voorkomen) of als adviserende controles (bevindingen worden gerapporteerd, maar implementatie mag doorgaan). Bevindingen met een kritieke of hoge ernst uit SAST, containerscans en detectie van geheimen blokkeren doorgaans. Bevindingen met een gemiddelde of lage ernst leiden tot meldingen of tickets zonder te blokkeren. Deze balans voorkomt dat beveiliging elke oplevering stillegt en zorgt er tegelijk voor dat echt gevaarlijke situaties niet automatisch in productie terechtkomen.

DevSecOps-programma's moeten met duidelijke metingen worden geëvalueerd. Belangrijke metingen zijn onder andere: de gemiddelde tijd tot herstel (MTTR) van bevindingen met een hoge ernst, de kwetsbaarheidsdichtheid (bevindingen per 1.000 coderegels in de loop van de tijd), het ontsnappingspercentage (het percentage kwetsbaarheden dat na productie wordt gevonden tegenover vóór productie) en het slagingspercentage van beveiligingscontroles in de pijplijn. Door deze metingen in de loop van de tijd te volgen, toon je de effectiviteit van het programma aan en kun je investeringsbeslissingen voor aanvullende tools of trainingen onderbouwen.

Het moeilijkste onderdeel van DevSecOps is cultureel, niet technisch. Beveiliging moet de verantwoordelijkheid van elke ontwikkelaar worden, niet alleen die van het beveiligingsteam. Hiervoor zijn het volgende nodig: beveiligingstraining voor ontwikkelaars (bewustwording van veilig programmeren), beveiligingsambassadeurs die in ontwikkelteams zijn opgenomen, evaluaties zonder schuldtoewijzing wanneer kwetsbaarheden productie bereiken (gericht op procesverbetering, niet op bestraffing) en steun van leidinggevenden om in te leveren op opleversnelheid wanneer een echt beveiligingsrisico dat vereist. Technologie zonder een cultuurverandering leidt tot scantools die ontwikkelaars leren negeren.

In deze les heb je geleerd dat DevSecOps SAST, DAST, het scannen van geheimen, het scannen van containers en IaC-scans integreert als geautomatiseerde controles in de pijplijn, dat het blokkeren van bevindingen met een hoge ernst voorkomt dat gevaarlijke situaties productie bereiken en dat het naar voren halen van beveiliging de herstelkosten sterk verlaagt doordat kwetsbaarheden tijdens de ontwikkeling worden gevonden in plaats van na de implementatie. Hierna bekijken we fysieke beveiligingsmaatregelen voor gebouwen en datacenters.