Loading blog posts...
Terug naar Blog
Also in
Uw beveiligingsscan heeft zojuist 847 kwetsbaarheden gemarkeerd verspreid over 12 microservices. Het ontwikkelteam loopt al achter op de sprint. Klinkt bekend? DevSecOps helpt door problemen op te vangen terwijl ze nog goedkoop en snel op te lossen zijn: minuten, geen dagen. De tools en praktijken hieronder weerspiegelen wat teams nu daadwerkelijk gebruiken om beveiliging in de ontwikkelcyclus te verweven. Elke categorie correspondeert met een punt in de pipeline waar kwetsbaarheden doorgaans binnensluipen.
Static Application Security Testing (SAST)
SAST-tools controleren broncode zonder deze uit te voeren, zodat u kwetsbaarheden kunt ontdekken voordat de eerste build zelfs maar klaar is.
Semgrep
yaml#.semgrep.yml - Custom rule for SQL injection rules: - id: sql-injection-format-string patterns: - pattern: | cursor.execute(f".. {$VAR}..") message: "Possible SQL injection via f-string" languages: [python] severity: ERROR
Deze regel vangt iets op wat veel generieke scanners missen: SQL-injectie via Python f-strings. De $VAR metavariabele matcht elke geïnterpoleerde waarde en markeert code waar gebruikersinvoer in ruwe SQL terecht zou kunnen komen. Teams die dit in CI draaien vangen deze problemen meestal binnen minuten na een commit op, in plaats van ze weken later tijdens een penetratietest te ontdekken.
Semgrep's echte kracht ligt in aangepaste regels. De standaard regelsets dekken de gebruikelijke verdachten, maar elke codebase heeft zijn eigen "speciale" patronen. Een fintech-team zou regels kunnen schrijven rond hun authenticatiestromen. Een zorgplatform zou HIPAA-gedreven regels voor gegevensverwerking kunnen afdwingen.
Semgrep in één oogopslag
Wat het is: Lichtgewicht statische analyse-engine die aangepaste regels ondersteunt voor 30+ talen
Prijzen: Gratis (OSS) / Team €37/bijdrager/mnd / Enterprise op maat
Het beste voor: Teams die snelle, aanpasbare SAST in CI willen
| Sterke punten | Beperkingen |
|---|---|
| Scantijden onder de seconde voor de meeste repo's | Minder kant-en-klare regels dan commerciële tools |
| Schrijf regels in 10 minuten, niet dagen | Geen dataflow-analyse in gratis versie |
| Draait lokaal zonder code extern te versturen | Pro-functies vereisen betaalde abonnementen |
Conclusie: Een sterke keuze als u strakke controle wilt over wat gemarkeerd wordt en snelle feedback belangrijk vindt.
SonarQube
SonarQube gaat de andere kant op: diepere analyse plus kwaliteitspoorten die merges kunnen blokkeren.
yaml# sonar-project.properties sonar.projectKey=myapp sonar.sources=src sonar.exclusions=**/test/**,**/vendor/** sonar.qualitygate.wait=true
De sonar.qualitygate.wait=true instelling is belangrijk. Zonder deze draait de scan wel, maar de pipeline blijft doorlopen ongeacht wat er gevonden wordt. Met deze instelling aan blokkeert een gefaalde kwaliteitspoort de build. De meeste teams beginnen met deze uit terwijl ze een baseline opbouwen, en zetten hem dan aan zodra de initiële achterstand onder controle is.
SonarQube is vooral nuttig als u compliance-vriendelijke rapportage nodig heeft. De historische tracking toont beveiligingsschuld-trends over tijd, wat meestal goed valt bij SOC 2 of ISO 27001 audits.
Software Composition Analysis (SCA)
Datadog's 2025 State of DevSecOps onderzoek toonde aan dat 86% van commerciële codebases open source kwetsbaarheden bevat. SCA-tools brengen riskante afhankelijkheden aan het licht voordat aanvallers dat doen.
Snyk
bash## Scan and auto-fix vulnerable dependencies snyk test --all-projects snyk fix --all-projects
snyk fix probeert automatisch te herstellen door pakketten te upgraden naar gepatchte versies waar mogelijk. Dit werkt meestal goed voor directe afhankelijkheden, maar transitieve afhankelijkheden kunnen lastig worden. Als het kwetsbare pakket drie niveaus diep zit, moet u mogelijk een tussenliggende afhankelijkheid bijwerken, en daar kunnen breaking changes opduiken.
Snyk's containerscanning is ook het bekijken waard:
bash# Scan container image for vulnerabilities snyk container test myregistry/myapp:latest --file=Dockerfile
Het toevoegen van --file=Dockerfile geeft hersteladvies gekoppeld aan uw base image. Bijvoorbeeld, overstappen van node:18 naar node:18-slim kan tientallen kwetsbaarheden wegvagen simpelweg omdat het slim image minder pakketten meelevert.
Snyk in één oogopslag
Wat het is: Ontwikkelaar-eerst beveiligingsplatform voor code, afhankelijkheden, containers en IaC
Prijzen: Gratis (beperkt) / Team €48/ontwikkelaar/mnd / Enterprise op maat
Het beste voor: Teams die uniforme kwetsbaarheidsmanagement willen met IDE-integratie
| Sterke punten | Beperkingen |
|---|---|
| Fix PR's automatisch gegenereerd | Gratis versie beperkt scans aanzienlijk |
| Sterke container- en IaC-scanning | Kan lawaaierig zijn zonder afstemming |
| Uitstekende IDE-plugins voor realtime feedback | Premium functies achter enterprise-versie |
Conclusie: Een van de soepelste ontwikkelaarservaringen in SCA, maar kosten kunnen snel oplopen naarmate het team groeit.
Dependabot en Renovate
Als afhankelijkheids-updates het hoofddoel zijn en een commerciële tool niet in het plan staat, dekken Dependabot en Renovate veel terrein.
yaml#.github/dependabot.yml version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" groups: production-dependencies: patterns: - "*" exclude-patterns: - "eslint*" - "@types/*"
Het groeperen van gerelateerde updates vermindert PR-lawaai aanzienlijk. Zonder groepering kan een typisch Node.js project 20+ PR's per week uitspugen. Met groepering daalt dat vaak naar 2-3 beheersbare updates.
Renovate geeft meer controle voor complexe monorepo's:
json{ "extends": ["config:base"], "packageRules": [ { "matchPackagePatterns": ["^@aws-sdk/"], "groupName": "AWS SDK", "automerge": true } ] }
Auto-mergen van AWS SDK updates kan agressief aanvoelen, maar deze pakketten houden zich meestal vrij strikt aan semantic versioning. In de meeste gevallen is het breukrisico laag, en de opbrengst van actueel blijven is reëel.
Secrets Detection
Gelekte inloggegevens zijn nog steeds een van de snelste paden van "klein probleem" naar "volledige inbreuk." Het doel is secrets op te vangen voordat ze ooit in de repo belanden.
Gitleaks
yaml#.gitleaks.toml [extend] useDefault = true [[rules]] id = "custom-api-key" description = "Company API Key" regex = '''MYCOMPANY_[A-Z0-9]{32}''' secretGroup = 0 [allowlist] paths = [ '''\.env\.example''', '''docs/''' ]
De allowlist helpt valse positieven uit docs en voorbeeldbestanden onder controle te houden. Zonder deze eindigen teams meestal met alert-moeheid en beginnen resultaten te negeren, wat de hele setup zinloos maakt.
Gitleaks als pre-commit hook draaien vangt secrets op voordat ze de git-geschiedenis ingaan:
bash#.pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks
Zodra een secret in de geschiedenis zit, betekent opruimen geschiedenis herschrijven of de inloggegevens roteren. Pre-commit checks besparen u beide.
TruffleHog
TruffleHog gaat een stap verder door te controleren of ontdekte inloggegevens daadwerkelijk werken:
bash## Scan with verification trufflehog git https://github.com/org/repo --only-verified
--only-verified filtert verlopen of ongeldige inloggegevens eruit, wat lawaai flink vermindert. Een scan zou 50 "mogelijke" secrets kunnen vinden, maar slechts 3 die nog geldig zijn. Die 3 zouden onmiddellijk geroteerd moeten worden.
Warning
Verificatie betekent dat TruffleHog probeert ontdekte inloggegevens te gebruiken tegen hun respectievelijke services. Draai dit alleen op repositories die u bezit, en zorg dat uw beveiligingsteam van de activiteit weet.
CI/CD Pipeline Security
Uw pipeline is een productiesysteem op zich. OWASP's CI/CD Security Cheat Sheet legt uit hoe aanvallers zwakke pipeline-configuraties misbruiken om kwaadaardige code te injecteren of inloggegevens te stelen.
GitHub Actions Hardening
yamlname: Secure Build on: [push] permissions: contents: read packages: write jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: persist-credentials: false - name: Build run: npm ci --ignore-scripts env: NODE_ENV: production
Er zijn hier een paar bewuste beveiligingskeuzes. Het permissions blok beperkt wat de workflow kan aanraken, volgens het principe van minimale privileges. persist-credentials: false voorkomt dat de checkout-actie inloggegevens achterlaat voor latere stappen om te misbruiken. En npm ci --ignore-scripts blokkeert post-install scripts, die kwaadaardige pakketten soms gebruiken om gegevens te exfiltreren of backdoors te plaatsen.
Datadog's onderzoek toonde aan dat 58% van organisaties die AWS en GitHub Actions gebruiken nog steeds vertrouwden op langlevende IAM-inloggegevens. OIDC-federatie elimineert die risicoklasse:
yamljobs: deploy: runs-on: ubuntu-latest permissions: id-token: write contents: read steps: - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam:123456789:role/GitHubActionsRole aws-region: us-east-1
Met OIDC liggen er geen statische inloggegevens rond om te lekken. De workflow krijgt kortlevende inloggegevens gekoppeld aan die run. Zelfs als ze gestolen worden, verlopen ze doorgaans binnen een uur.
GitLab CI Security
yaml#.gitlab-ci.yml include: - template: Security/SAST.gitlab-ci.yml - template: Security/Dependency-Scanning.gitlab-ci.yml - template: Security/Container-Scanning.gitlab-ci.yml variables: SAST_EXCLUDED_ANALYZERS: "eslint" DS_EXCLUDED_PATHS: "vendor/, node_modules/" stages: - test - security - deploy security-gate: stage: security script: - | if [ "$CI_COMMIT_BRANCH" == "main" ]; then exit $(cat gl-sast-report.json | jq '.vulnerabilities | map(select(.severity == "Critical")) | length') fi allow_failure: false
Deze beveiligingspoort telt kritieke kwetsbaarheden en sluit af met dat aantal als exit code. Nul kritieke bevindingen betekent exit code 0 (succes). Elke kritieke bevinding laat de pipeline falen. Het patroon dat goed werkt is: maak main strikt, houd feature branches flexibeler.
Container Security
Container images zijn deployment-artefacten: applicatiecode plus de runtime-omgeving. Kwetsbaarheden in beide delen creëren echte blootstelling.
Trivy
bash## Comprehensive container scan trivy image --severity HIGH,CRITICAL \ --ignore-unfixed \ --format sarif \ --output trivy-results.sarif \ myregistry/myapp:latest
--ignore-unfixed filtert problemen zonder beschikbare patch eruit. Dat houdt rapporten gefocust op wat uw team nu daadwerkelijk kan oplossen. Anders wordt de output snel lawaaierig.
Trivy scant ook Infrastructure as Code:
bash# Scan Terraform for misconfigurations trivy config --severity HIGH,CRITICAL./terraform/
Eén tool gebruiken voor containers, bestandssystemen en IaC vermindert context-switching. Uw team ziet resultaten in een consistent formaat ongeacht wat er gescand wordt.
Minimale Base Images
Datadog's onderzoek toonde aan dat container images onder 100 MB gemiddeld 3 hoge en kritieke kwetsbaarheden hadden, terwijl images boven 500 MB er gemiddeld 20 hadden. Kleinere images betekenen meestal een kleiner aanvalsoppervlak.
dockerfile## Multi-stage build for minimal production image FROM node:20-alpine AS builder WORKDIR /app COPY package*.json./ RUN npm ci --only=production FROM gcr.io/distroless/nodejs20-debian12 COPY /app/node_modules /app/node_modules COPY. /app WORKDIR /app CMD ["server.js"]
Het distroless base image bevat alleen de Node.js runtime. Geen shell, geen package manager, geen extra utilities die het leven van een aanvaller makkelijker maken. Als iemand in de container belandt, is er heel weinig om mee te werken.
Tip
Distroless images kunnen debugging moeilijker maken omdat er geen shell in de container zit. Houd een debug-variant met shell voor ontwikkeling, maar ship de distroless versie naar productie.
Infrastructure as Code Security
IaC-scanning vangt misconfiguraties op voordat ze echte cloudomgevingen raken. Een publieke S3-bucket in Terraform repareren is veel goedkoper dan hem repareren nadat hij al in productie staat.
Checkov
bash# Scan Terraform with custom policy checkov -d./terraform/ \ --framework terraform \ --check CKV_AWS_19,CKV_AWS_20,CKV_AWS_21 \ --soft-fail-on CKV_AWS_144
--check draait alleen de beleidsregels waar u om geeft, wat handig is als u een gerichte scan wilt. --soft-fail-on laat bepaalde bevindingen waarschuwen zonder de pipeline te laten falen, wat nuttig is tijdens migraties waar een tijdelijke uitzondering verwacht wordt.
Aangepaste beleidsregels dekken organisatie-specifieke vereisten:
python## custom_policy.py from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck from checkov.common.models.enums import CheckResult, CheckCategories class RequireEncryptionTag(BaseResourceCheck): def __init__(self): name = "Ensure all S3 buckets have encryption classification tag" id = "CUSTOM_AWS_1" supported_resources = ['aws_s3_bucket'] categories = [CheckCategories.ENCRYPTION] super.__init__(name=name, id=id, categories=categories, supported_resources=supported_resources) def scan_resource_conf(self, conf): tags = conf.get('tags', [{}]) if 'data_classification' in tags: return CheckResult.PASSED return CheckResult.FAILED check = RequireEncryptionTag
Deze beleidsregel dwingt een tagging-standaard af: elke S3-bucket moet zijn gegevensclassificatie declareren. Die classificatie voedt vervolgens encryptiebeslissingen en compliance-rapportage.
Runtime Security en DAST
Statische analyse vangt op wat zichtbaar is in code. Dynamische analyse vindt problemen die alleen opduiken zodra de app draait.
OWASP ZAP
yaml# ZAP automation framework config env: contexts: - name: "MyApp" urls: - "https://staging.myapp.com" includePaths: - "https://staging.myapp.com/api/.*" excludePaths: - "https://staging.myapp.com/api/health" authentication: method: "script" parameters: script: "auth-script.js" jobs: - type: spider parameters: maxDuration: 5 - type: activeScan parameters: policy: "API-Scan" - type: report parameters: template: "sarif-json" reportFile: "zap-report.sarif"
Het automation framework draait ZAP in CI zonder handmatige stappen. De spider ontdekt endpoints, dan test de actieve scan ze op kwetsbaarheden. Dit op staging richten (niet productie) vermijdt het risico dat scanverkeer echte gebruikers beïnvloedt.
Wat vaak gemist wordt: authenticatie is waar ZAP-setups meestal mislukken. Als auth niet correct geconfigureerd is, raakt de scanner alleen publieke endpoints en ziet nooit de riskantste stromen achter login.
Nuclei
Nuclei is geweldig voor het testen van specifieke, bekende kwetsbaarheden:
bash## Scan for specific CVEs nuclei -u https://staging.myapp.com \ -t cves/ \ -t exposures/ \ -severity high,critical \ -rate-limit 50
Omdat het template-gebaseerd is, kunt u snel testen op nieuw bekendgemaakte CVE's, vaak binnen uren na publicatie. De community onderhoudt duizenden templates die alles dekken van blootgestelde admin-panelen tot specifieke productkwetsbaarheden.
Software Bill of Materials (SBOM)
SBOM's lijsten elk component in uw software op, wat respons veel sneller maakt wanneer iets nieuws breekt. Toen Log4Shell toesloeg, konden organisaties met SBOM's getroffen systemen binnen uren identificeren. Zonder SBOM's spendeerden veel teams weken aan zoeken.
Syft en Grype
bash# Generate SBOM syft myregistry/myapp:latest -o spdx-json > sbom.json # Scan SBOM for vulnerabilities grype sbom:sbom.json --fail-on high
SBOM-generatie scheiden van kwetsbaarheidsscanning is praktisch. Genereer de SBOM eenmaal tijdens de build, bewaar hem als artefact, scan hem dan later opnieuw als nieuwe CVE's gepubliceerd worden. U heeft geen toegang tot het originele image nodig om te controleren of het getroffen is.
yaml## GitHub Action for SBOM workflow - name: Generate SBOM uses: anchore/sbom-action@v0 with: image: ${{ env.IMAGE }} artifact-name: sbom.spdx.json - name: Scan SBOM uses: anchore/scan-action@v3 with: sbom: sbom.spdx.json fail-build: true severity-cutoff: high
SBOM's als build-artefacten bewaren creëert ook een schone audittrail. Wanneer een kwetsbaarheid opduikt, kunt u oudere SBOM's scannen om te zien welke gedeployde versies getroffen zijn, zonder iets te herbouwen.
AI Code Security
GitLab's 2025 survey toonde aan dat 97% van organisaties AI gebruikt of van plan is te gebruiken in hun ontwikkelworkflow. Maar IBM's onderzoek onthulde dat 63% AI-governance-beleid mist, en 97% van organisaties die AI-gerelateerde beveiligingsincidenten ervaren hadden ontoereikende toegangscontroles.
AI-Gegenereerde Code Reviewen
AI-assistenten produceren vaak code die "werkt" maar stilletjes beveiligingsproblemen inbakt:
python# AI-generated code (problematic) def get_user(user_id): query = f"SELECT * FROM users WHERE id = {user_id}" return db.execute(query) # Secure version def get_user(user_id: int): query = "SELECT * FROM users WHERE id =?" return db.execute(query, (user_id,))
De AI-gegenereerde versie gebruikt string-interpolatie, wat SQL-injectierisico creëert. De veiligere versie gebruikt geparametriseerde queries. AI-tools produceren vaak het eerste patroon omdat het veel voorkomt in trainingsdata, inclusief tutorials en posts die beknoptheid boven beveiliging verkiezen.
Important
Behandel AI-gegenereerde code zoals u code van een junior ontwikkelaar zou behandelen: het kan correct functioneren, maar kan beveiligingsdetails missen die ervaren engineers automatisch opvangen.
AI Tool Governance
Organisaties hebben beleid nodig voor:
| Beleidsgebied | Aanbevolen controle |
|---|---|
| Goedgekeurde tools | Whitelist specifieke AI-assistenten |
| Code review | Vereist menselijke review van alle AI-gegenereerde code |
| Gegevensverwerking | Blokkeer gevoelige code uit AI-prompts |
| Trainingsdata | Voorkom dat propriëtaire code trainingsmodellen voedt |
Sommige teams gebruiken proxy-tools die AI-prompts filteren om gevoelige patronen te verwijderen voordat ze externe services bereiken. Anderen beperken AI-gebruik tot goedgekeurde, zelf-gehoste modellen zodat data binnen de organisatie-infrastructuur blijft.
Contextuele Kwetsbaarheid Prioritering
Ruwe kwetsbaarheidsaantallen begraven teams. Datadog's onderzoek toonde aan dat zodra runtime-context toegepast wordt, slechts 18% van kritieke CVSS-kwetsbaarheden nog steeds kritiek leken.
Een Prioriteringsframework Bouwen
yaml## Example prioritization criteria priority_matrix: critical: - cisa_kev: true - epss_score: ">0.9" - internet_exposed: true - production: true high: - cisa_kev: true - epss_score: ">0.5" - production: true medium: - epss_score: ">0.1" - production: true low: - default: true
CISA's Known Exploited Vulnerabilities (KEV) catalogus volgt kwetsbaarheden die actief uitgebuit worden. Als iets in KEV staat, gebruiken aanvallers het al, dus het is urgent zelfs als CVSS er niet angstaanjagend uitziet.
EPSS (Exploit Prediction Scoring System) schat de kans dat een kwetsbaarheid binnen 30 dagen uitgebuit wordt. Een kritiek CVSS-probleem met 0,1% EPSS is meestal minder urgent dan een hoog CVSS-probleem met 90% EPSS.
Meng die signalen met deployment-context (productie vs. staging, internet-facing vs. intern), en u krijgt een uitvoerbare wachtrij in plaats van een overweldigende lijst.
Begin hier
Begin hier (uw eerste stap)
Voeg Gitleaks vandaag nog toe als pre-commit hook aan één repository. Het kost vijf minuten en blokkeert credential-lekken voordat ze een opruimproject worden.
Snelle winsten (directe impact)
- Schakel Dependabot of Renovate in op uw meest kritieke repository met wekelijkse gegroepeerde updates
- Draai Trivy tegen uw productie-container images en repareer alle kritieke bevindingen waarvoor patches beschikbaar zijn
Diepgaand (voor wie meer wil)
- Implementeer OIDC-federatie voor uw CI/CD-pipelines om langlevende inloggegevens kwijt te raken
- Bouw een contextueel prioriteringsframework dat CVSS, EPSS, KEV-status en deployment-context combineert
Nuttige Bronnen
- NIST Secure Software Development Framework - Gezaghebbend framework voor veilige ontwikkelpraktijken
- OWASP DevSecOps Guideline - Praktische begeleiding voor pipeline-beveiligingscontroles
- OWASP CI/CD Security Cheat Sheet - Specifieke controles voor pipeline-hardening
- Datadog State of DevSecOps 2025 - Data-gedreven inzichten over kwetsbaarheid-prioritering en veelvoorkomende hiaten
- OWASP Top 10:2025 - Huidige webapplicatie-beveiligingsrisico's inclusief supply chain-fouten
Belangrijkste Inzichten
DevSecOps werkt het beste wanneer beveiliging aanvoelt als onzichtbare infrastructuur, niet als een laatste-minuut checkpoint. De bovenstaande tools passen in bestaande workflows, zodat problemen opgevangen worden terwijl context nog vers is en fixes nog goedkoop zijn.
Overstappen van reactieve scanning naar proactieve beveiligingsengineering vraagt echte investering: tools, proces en cultuur. Teams die CI/CD als productie behandelen, kwetsbaarheden prioriteren met context (niet alleen ruwe ernst), en duidelijke zichtbaarheid in de software supply chain houden, presteren meestal beter dan teams die vertrouwen op periodieke beoordelingen.
Begin met één tool in één pipeline. Volg hoeveel late-stage bevindingen verdwijnen. Breid dan uit.
Als uw organisatie hulp nodig heeft bij het sequencen van de uitrol of het kiezen van tools die bij uw omgeving passen, biedt Joulyan IT DevSecOps-beoordelingen die huidige staat naar doelarchitectuur in kaart brengen met concrete volgende stappen.
