# DevOps Pipeline Security in 2026: SAST, DAST, Supply Chain en Interviewvragen

> Complete gids voor het beveiligen van CI/CD pipelines in 2026. Behandelt SAST, DAST, SCA, SBOM, SLSA provenance en praktische interviewvragen voor DevSecOps-functies.

- Published: 2026-09-15
- Updated: 2026-09-15
- Author: Anthony Fillion-Maillet
- Tags: devops, security, cicd, devsecops, sast, dast
- Reading time: 9 min

---

DevOps pipeline security vereist het inbedden van beveiligingscontroles in elke fase van de CI/CD-workflow, van pre-commit hooks tot productiemonitoring. Het [Datadog State of DevSecOps Report 2026](https://www.datadoghq.com/state-of-devsecops/) onthult dat 87% van de organisaties services draait met minstens één bekende exploiteerbare kwetsbaarheid, terwijl aanvallen op de software supply chain de wereldeconomie nu jaarlijks meer dan 80 miljard dollar kosten.

> **De prioriteitsvolgorde voor security tooling**
>
> Begin met secrets detection (hoogste impact, laagste false-positive rate), voeg dan SCA toe voor bekende CVE's, SAST met tuning, IaC-scanning en tot slot DAST. Elk tool moet zijn waarde bewijzen voordat het volgende wordt toegevoegd.

## SAST: Statische Analyse die Kwetsbaarheden Vangt Vóór de Merge

Static Application Security Testing (SAST) analyseert broncode zonder deze uit te voeren. De tool parst de codebase, bouwt een abstracte syntaxisboom en matcht patronen met bekende kwetsbaarheidshandtekeningen. Het draaien van SAST op elke pull request vangt SQL-injection, XSS en hardcoded credentials voordat code de main branch bereikt.

Semgrep is in 2026 de de facto open-source SAST-tool geworden. In tegenstelling tot regex-gebaseerde scanners begrijpt Semgrep codestructuur en ondersteunt het custom regels in YAML.

```yaml
# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif
```

De flag `--config=auto` laadt community-regels die overeenkomen met de gedetecteerde talen. SARIF-output integreert met het GitHub Security-tabblad voor het tracken van bevindingen over tijd.

## DAST: Runtime Testing die Vindt wat Statische Analyse Mist

Dynamic Application Security Testing (DAST) valt een draaiende applicatie aan om kwetsbaarheden te vinden die zich alleen tijdens runtime manifesteren. Gebroken authenticatie, autorisatiefouten en business logic bugs vereisen daadwerkelijke HTTP-requests om te detecteren. SAST kan niet vinden dat een admin-endpoint geen correcte toegangscontrole heeft, maar DAST zal proberen er zonder credentials bij te komen en de blootstelling melden.

[OWASP ZAP](https://www.zaproxy.org/) blijft de meest gebruikte open-source DAST-tool. ZAP 3.0, begin 2026 uitgebracht, voegde native ondersteuning voor GraphQL- en gRPC-scanning toe.

```yaml
# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html
```

DAST draait na deployment omdat het een live target nodig heeft. De staging-omgeving dient als testoppervlak en houdt productie geïsoleerd van scanverkeer.

> **DAST in Productie**
>
> Het uitvoeren van actieve DAST-scans tegen productie riskeert het triggeren van rate limits, het corrumperen van data of het alerteren van security monitoring. Gebruik een staging-omgeving die de productieconfiguratie spiegelt.

## SCA: Dependency Scanning voor Bekende Kwetsbaarheden

Software Composition Analysis (SCA) scant dependencies tegen kwetsbaarheidsdatabases zoals de [National Vulnerability Database](https://nvd.nist.gov/) en GitHub Advisory Database. Een enkele kwetsbare transitieve dependency kan de gehele applicatie blootstellen. Het Datadog-rapport van 2026 vond dat 42% van de services afhankelijk is van bibliotheken die niet langer actief worden onderhouden.

Trivy scant containers, filesystems en git-repositories op kwetsbaarheden in één binary. Het genereert SBOM-output in CycloneDX- en SPDX-formaten.

```yaml
# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Dagelijks om 6:00

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'
```

De geplande dagelijkse scan vangt nieuw bekendgemaakte CVE's ook zonder codewijzigingen. Filtering op CRITICAL en HIGH severity voorkomt alert-moeheid door bevindingen met laag risico.

## Supply Chain Security: SBOM en SLSA Provenance

De [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), met rapportageverplichtingen die in september 2026 van kracht worden, verplicht Software Bill of Materials (SBOM) generatie voor producten die in de EU worden verkocht. Een SBOM lijst elke component in de software, inclusief directe dependencies, transitieve dependencies en hun versies.

[SLSA](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) vult SBOM aan door te verifiëren hoe software is gebouwd. SBOM beantwoordt "welke componenten zitten in deze software?" terwijl SLSA beantwoordt "kan het build-proces worden vertrouwd?"

```yaml
# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}
```

Sigstore's Cosign tekent artefacten met keyless signing ondersteund door de Fulcio certificate authority. De handtekening bindt het artefact aan de CI-workflow die het heeft geproduceerd, waardoor verificatie mogelijk is dat de image uit een vertrouwde pipeline komt.

## Secrets Detection: De Eerste Verdedigingslinie

Hardcoded secrets blijven de meest voorkomende security-bevinding in codebases. AWS-toegangssleutels, database-wachtwoorden en API-tokens die naar version control worden gecommit, hebben inbreuken van elke omvang veroorzaakt. Secrets detection draait pre-commit om credentials te blokkeren voordat ze de repository binnenkomen.

[Gitleaks](https://github.com/gitleaks/gitleaks) detecteert secrets met regex-patronen en entropie-analyse. Een pre-commit hook voorkomt dat secrets ooit worden gecommit.

```yaml
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']
```

```yaml
# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

De optie `fetch-depth: 0` kloont de volledige historie, waardoor Gitleaks alle commits in de PR kan scannen, niet alleen de laatste.

## DevSecOps Interviewvragen: Wat Recruiters Vragen

DevSecOps-interviews beoordelen zowel beveiligingskennis als praktische CI/CD-ervaring. De onderstaande vragen verschijnen regelmatig in interviews van 2026 voor senior DevOps- en platform engineering-functies. Meer vragen over pipeline-beveiliging zijn te vinden in de [CI/CD Pipeline Security interviewmodule](/technologies/devops/interview-questions/cicd-pipeline-security).

### "Hoe zou je shift-left security implementeren in een bestaande pipeline?"

Shift-left security verplaatst testen eerder in de ontwikkelcyclus. De praktische implementatie omvat het toevoegen van pre-commit hooks voor secrets detection, SAST-scans op pull requests en SCA-controles in de build-fase. De sleutel is incrementele adoptie: begin met secrets detection omdat het de laagste false-positive rate en het hoogste signaal heeft, voeg dan SCA toe voor bekende CVE's, tune dan SAST-regels om ruis te verminderen voordat het als blokkerende check wordt ingeschakeld.

### "Leg het verschil uit tussen SAST en DAST. Wanneer zou je elk gebruiken?"

SAST analyseert broncode zonder uitvoering. Het vindt SQL-injection, XSS en onveilige cryptografie door pattern matching tegen de codestructuur. SAST draait vroeg, op elke PR, omdat het alleen de code nodig heeft.

DAST valt een draaiende applicatie aan. Het vindt authenticatie-bypasses, gebroken toegangscontrole en injection-kwetsbaarheden die zich alleen tijdens runtime manifesteren. DAST draait na deployment tegen een staging-omgeving.

De twee vullen elkaar aan. SAST vangt codeerfouten vóór de merge; DAST verifieert dat de gedeployede applicatie zich veilig gedraagt. Een volwassen pipeline draait beide.

### "Wat is een SBOM en waarom is het vereist?"

Een Software Bill of Materials lijst elke component in de software, inclusief directe en transitieve dependencies met exacte versies. Regelgevende vereisten zoals de EU Cyber Resilience Act verplichten SBOM-generatie voor producten die vanaf september 2026 de EU-markt betreden.

Praktisch gezien maakt SBOM snelle incident response mogelijk. Wanneer een nieuwe CVE uitkomt, kan het security team de SBOM-database bevragen om elke service te identificeren die de kwetsbare component draait, in plaats van alle repositories handmatig te scannen.

### "Hoe voorkom je alert-moeheid in security tooling?"

Alert-moeheid treedt op wanneer ontwikkelaars security-bevindingen negeren omdat de signaal-ruisverhouding te laag is. Preventie vereist het tunen van elke tool voordat blokkerende gates worden ingeschakeld. Voor SAST worden regels uitgeschakeld die false positives produceren in de codebase en geleidelijk ingeschakeld na opschoning. Voor SCA ligt de focus op CRITICAL en HIGH severity-bevindingen met bekende exploits. Voor DAST worden baseline-scans geconfigureerd om false positives uit te sluiten van toekomstige runs.

De te tracken metric is time-to-fix voor echte kwetsbaarheden. Als dat nummer stijgt, negeren ontwikkelaars alerts.

> **Interviewvoorbereiding**
>
> Deze vragen testen praktische ervaring. Bereid voorbeelden voor uit echte pipelines, inclusief specifieke tools, configuratiebeslissingen en metrics voor en na implementatie.

## Container en Runtime Security

Container image scanning vangt kwetsbaarheden vóór deployment. Runtime security monitort containers in productie op afwijkend gedrag. De combinatie adresseert zowel bekende kwetsbaarheden (CVE's in base images) als onbekende dreigingen (gecompromitteerde containers, cryptominers).

Trivy scant images als onderdeel van de build-pipeline. [Falco](https://falco.org/) monitort runtime-gedrag met eBPF.

```yaml
# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true
```

De flag `ignore-unfixed: true` slaat kwetsbaarheden over zonder beschikbare patches. Dit voorkomt het blokkeren van deployments voor CVE's die momenteel niet kunnen worden verholpen.

Voor runtime security detecteren Falco-regels verdachte activiteit in draaiende containers. De [Container Supply Chain Security module](/technologies/devops/interview-questions/container-supply-chain) behandelt image signing en admission control in detail.

## IaC Security: Scanning van Terraform en Kubernetes Manifests

Infrastructure as Code introduceert beveiligingsrisico's op de configuratielaag. Te permissieve IAM-policies, publiek toegankelijke S3-buckets en onversleutelde databases resulteren uit onveilige defaults in IaC-templates.

[Checkov](https://www.checkov.io/) scant Terraform, CloudFormation, Kubernetes, Helm en Dockerfiles op misconfiguraties.

```yaml
# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif
```

Het pad-filter zorgt ervoor dat IaC-scans alleen draaien wanneer infrastructuurbestanden veranderen, wat CI-tijd vermindert voor applicatie-only wijzigingen.

## De Complete DevSecOps Pipeline voor 2026

Een productie-klare DevSecOps pipeline in 2026 integreert deze tools in elke fase:

- **Pre-commit**: Gitleaks (secrets), optioneel lokaal SAST
- **Pull request**: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
- **Build**: Container image scanning, SBOM-generatie
- **Pre-deploy**: Image signing met Cosign, admission control met Kyverno
- **Post-deploy**: DAST met ZAP tegen staging
- **Runtime**: Falco voor container monitoring, cloud security posture management

De gratis stack (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) dekt elke categorie. Commerciële tools voegen centrale dashboards, policy management en verminderde tuning-inspanning toe, maar de beveiligingsdekking is bereikbaar zonder licentiekosten.

Organisaties die zich voorbereiden op DevSecOps-functies moeten oefenen met het bouwen van deze pipelines in persoonlijke projecten. De [Cloud Identity and Secrets Management module](/technologies/devops/interview-questions/cloud-identity-secrets) behandelt de secrets management-kant van de vergelijking.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/nl/blog/devops/devops-pipeline-security-sast-dast-2026