Je kent het vast: wekenlang getest, alles staat op groen, en dan…
Je hebt alles getest. De load test draait perfect: 10.000 gelijktijdige gebruikers, responstijden onder de 100ms, geen geheugenlekken. Je rapporteert trots aan de CTO: "Qua performance zijn we klaar voor Black Friday."
En dan komt de security audit.
47 kwetsbaarheden. 12 kritiek. Waaronder een SQL injection in de checkout flow die al drie maanden in productie staat. Al die mooie performance metrics? Die zijn weinig waard als hackers je database kunnen legen tijdens piekverkeer.
Als performance tester herken je dit waarschijnlijk. Je optimaliseert tot op de milliseconde, maar één beveiligingslek kan je hele infrastructuur platleggen. En het wrange is: die SQL injection had je build al laten falen als je security testing in je CI/CD pipeline had geautomatiseerd. Een fix van vijf minuten tijdens development, in plaats van drie weken crisismanagement achteraf.
In dit artikel nemen we je mee in hoe je security testing naadloos integreert in je CI/CD pipeline, zonder vertraging, zonder extra geblokkeerde builds. Gewoon elke kwetsbaarheid vangen voordat die je performance metrics irrelevant maakt.
Waarom security testing niet kan wachten tot na deployment
Twee jaar geleden crashte een grote Nederlandse webshop tijdens hun belangrijkste verkoopdag. Niet door overbelasting, daar had het performance team zich maandenlang op voorbereid. Een hacker maakte gebruik van een lek in de inlogbeveiliging, zorgde voor massale data-exports, en de databaseservers bezweken onder de onverwachte belasting.
De performance metrics? Die zagen er geweldig uit. Tot het moment dat security het knelpunt werd.
En dit is geen uitzondering. In de praktijk worden de meeste security kwetsbaarheden pas in productie ontdekt, en de detectietijd loopt regelmatig op tot maanden. Dat is een lange periode waarin je zorgvuldig geoptimaliseerde systemen kwetsbaar zijn voor aanvallen die al je performance-tuning teniet kunnen doen.
Weet je wat we vaak tegenkomen? Wanneer teams terugkijken in hun git history, blijkt de kwetsbaarheid al maanden eerder geïntroduceerd. Een simpele SQL query die niet geparametriseerd is. Een vergeten inputvalidatie. Het zijn oplossingen die minuten kosten als je ze direct spot, maar die je infrastructuur kunnen vloeren als je ze mist.
Voor performance testers is dit extra frustrerend. Je meet alles: responstijden, throughput, resourcegebruik. Maar security blijft vaak een blinde vlek tot het te laat is. En dat terwijl juist jij de vaardigheden hebt om security testing te integreren in je CI/CD, zonder dat het ten koste gaat van je performance. Je begrijpt pipelines, automatisering en metrics. Tijd om die expertise ook voor security in te zetten.
Daar komt bij dat security issues in de praktijk steeds vaker direct impact hebben op performance. Een authenticatieservice zonder rate limiting kan je CPU-gebruik door het dak jagen. Een XML-parser zonder entiteitslimiet kan geheugenuitputting veroorzaken. Security testing in je CI/CD vangt deze problemen voordat ze je productiesystemen belasten.
De fundamenten: SAST, DAST en alles daartussen
"Security testing klinkt als weer een tool die mijn builds vertraagt." Herkenbaar? Als performance tester ben je allergisch voor alles wat latency toevoegt. Maar hier komt het goede nieuws: goed opgezette security testing in CI/CD pipelines heeft nauwelijks impact op je buildperformance.
Laten we de beschikbare tools eens bekijken vanuit het oogpunt van performance.
SAST (static application security testing) analyseert broncode zonder dat de applicatie draait. Wat het voor jou interessant maakt: het draait parallel aan je unit tests, niet erna. Bij een fintech in Amsterdam waar we werkten, zetten we SAST scanning op voor hun 50 dagelijkse commits. De impact op buildtijd? Minder dan 30 seconden, door slim gebruik van incrementeel scannen. Alleen gewijzigde bestanden worden geanalyseerd, dus je betaalt niet elke keer voor de hele codebase.
DAST (dynamic application security testing) is waar het echt interessant wordt voor performance testers. DAST simuleert aanvallen op je draaiende applicatie, eigenlijk een soort load testing, maar dan met aanvallen in plaats van gewone gebruikers. We zagen bij een e-commerce platform dat hun loginpagina geen rate limiting had. Tijdens normale load tests viel dit niet op, maar een aanvaller kon met woordenboekaanvallen hun authenticatieservice overbelasten. De fix was rate limiting implementeren, en dat kwam zowel security als performance ten goede.
IAST (interactive application security testing) plaatst sensoren in je applicatie. De overhead is minimaal, we komen meestal onder de 5% in testomgevingen. Maar de inzichten zijn goud waard. IAST kan exact tonen welke codepaden kwetsbaar zijn tijdens specifieke gebruikersflows. Voor jou als performance tester betekent dat: je kunt plekken in je code vinden waar zowel security- als performanceproblemen zitten.
SCA (software composition analysis) is de moeite waard om apart te bekijken. Een groot deel van moderne applicaties bestaat inmiddels uit third-party dependencies. SCA scant die op bekende kwetsbaarheden. Een betalingsprovider ontdekte dat hun JSON-parsingbibliotheek een kwetsbaarheid had die bij specifieke invoer tot tien keer hogere CPU-belasting kon leiden. Beveiligingsprobleem? Ja. Performanceprobleem? Ook.
In onze ervaring is parallellisatie de sleutel. In plaats van security scans als extra stap toe te voegen, draai je ze gelijktijdig met bestaande tests:
test-stage:
parallel:
- unit-tests: 3m 20s
- integration-tests: 5m 10s
- sast-scan: 2m 45s
- dependency-check: 1m 30s
total-time: 5m 10s # Geen extra tijd!
Elke methode geeft je andere inzichten. SAST vindt problemen op codeniveau, DAST ontdekt runtimeproblemen, en SCA houdt je dependencies veilig. De combinatie van deze tools in je CI/CD pipeline geeft je brede dekking zonder dat je deploymentcyclus vertraagt.
Tool selectie: van gratis plugins tot enterprise suites
Als performance tester weet je: de duurste tool is niet altijd de beste. Hetzelfde geldt voor security scanning. Er zijn heel veel enterprise-oplossingen op de markt die beweren alles te doen, maar in de praktijk je pipeline vertragen met onnodige overhead.
Ons advies is bijna altijd: begin pragmatisch. Semgrep (open source) is razensnel voor SAST. Het gebruikt slimme patroonherkenning in plaats van zware statische analyse. Een team met 500.000 regels code scant hun volledige codebase in onder de twee minuten. Vergelijk dat met commerciële tools die vijftien minuten of meer nodig hebben.
Voor DAST is OWASP ZAP nog steeds de beste keuze als je kijkt naar wat je ervoor krijgt. Het draait zonder interface, integreert native met Jenkins en GitLab, en je kunt de scanintensiteit configureren. Een tip uit onze ervaring: gebruik verschillende scanprofielen voor verschillende pipelinefasen:
- Commit-fase: snelle scan (5 minuten) voor de meest kritieke kwetsbaarheden
- Nachtelijke builds: volledige scan (2-3 uur) voor uitgebreide dekking
- Pre-release: diepgaande scan met authenticatietests
Maar let op de valkuilen. Een scale-up koos voor een alles-in-één suite van een grote leverancier. Prijs: €100.000 per jaar. Het probleem? De tool was geoptimaliseerd voor Java en C#, maar begreep hun Node.js microservices amper. En elke scan duurde 45 minuten omdat de tool patronen probeerde te matchen die niet relevant waren voor JavaScript. Duur én traag dus.
De teams die we tegenkomen en het goed doen, kiezen meestal voor specialisatie:
- Snyk voor dependency scanning: supersnel en prettig in gebruik
- Semgrep voor eigen SAST-regels: je kunt patronen schrijven specifiek voor jouw codebase
- Nuclei voor gerichte security tests: template-gebaseerd en extreem snel
Waar je als performance tester op moet letten bij de keuze van security testing tools:
- Scantijd per 1000 regels code: alles boven 10 seconden is te traag
- Geheugengebruik: security tools die 8 GB RAM nodig hebben voor kleine projecten zijn geen optie
- Incrementeel scannen: volledige herscans bij elke commit, dat wil je niet
- Parallelle uitvoering: kan de tool multi-threaded draaien?
Een praktisch selectieproces dat goed werkt: draai elke tool een week op de achtergrond mee. Meet de impact op je pipelineperformance. Als een security tool je builds met meer dan 20% vertraagt, is het de verkeerde tool, ongeacht hoe goed de detectie is.
En vergeet de integratie niet. Een security testing tool die niet goed samenwerkt met je pipeline-orchestrator zorgt voor gedoe. Kijk altijd of er officiële plugins zijn voor Jenkins, GitLab CI, GitHub Actions, of welke tool je ook gebruikt.
Stap-voor-stap integratie in populaire CI/CD platforms
"Security scanning vertraagt onze deployments." Als je dit hoort, weet je dat iemand het verkeerd heeft aangepakt. De kunst is niet om security scans toe te voegen, maar om ze te verweven in je bestaande pipelineflow.
Laten we concreet worden. Je hebt een typische CI/CD pipeline: build → test → deploy. De naïeve aanpak voegt security als extra stap toe: build → test → security → deploy. Resultaat? 15 tot 30 minuten extra per deployment.
De slimme aanpak is anders: security door je hele pipeline heen weven, parallel en incrementeel.
Jenkins pipeline voorbeeld:
pipeline {
agent any
stages {
stage('Parallel Testing') {
parallel {
stage('Unit Tests') {
steps {
sh 'npm test'
}
}
stage('Performance Tests') {
steps {
sh 'npm run test:performance'
}
}
stage('Security Quick Scan') {
steps {
sh '''
# Alleen gewijzigde files scannen
git diff --name-only HEAD~1 | \
grep -E '\\.(js|ts)$' | \
xargs semgrep --config=auto --json
'''
}
}
}
}
stage('Deploy to Staging') {
steps {
sh 'kubectl apply -f k8s/'
}
}
stage('Post-Deploy Security') {
parallel {
stage('DAST Scan') {
steps {
sh 'zap-cli quick-scan https://staging.app.com'
}
}
stage('Load Test with Security') {
steps {
sh '''
# K6 load test met security checks
k6 run --vus 100 --duration 5m \
security-load-test.js
'''
}
}
}
}
}
}
GitLab CI configuratie:
variables:
SECURE_ANALYZERS_PREFIX: "registry.gitlab.com/security-products"
test:
stage: test
parallel:
matrix:
- TEST_SUITE: unit
SCRIPT: npm test
- TEST_SUITE: performance
SCRIPT: npm run test:load
- TEST_SUITE: security-sast
SCRIPT: |
docker run --rm -v "$PWD":/src \
returntocorp/semgrep:latest \
--config=auto --metrics=off
deploy:staging:
stage: deploy
script:
- kubectl apply -f k8s/
environment:
name: staging
security:dast:
stage: verify
needs: ["deploy:staging"]
script:
- |
docker run --rm \
-v $(pwd):/zap/wrk/:rw \
owasp/zap2docker-stable \
zap-baseline.py -t https://$CI_ENVIRONMENT_URL
Het slimme zit hem in het stapsgewijs strenger maken. In onze ervaring werkt dit het beste: in week 1 zijn alle bevindingen puur informatief. In week 2 blokkeert alleen hoge prioriteit een deployment. Vanaf week 4 ook gemiddelde prioriteit. Zo geef je het team tijd om te wennen zonder dat de deploymentsnelheid eronder lijdt.
Een concreet voorbeeld: een betalingsverwerker bracht hun deploymenttijd met 40% omlaag door security testing slim in hun CI/CD te verweven. Hun aanpak was eigenlijk best simpel, verschillende checks op verschillende momenten:
- Pre-commit hooks: basislinting voor duidelijke security issues (minder dan 1 seconde)
- PR checks: SAST op alleen gewijzigde bestanden (minder dan 2 minuten)
- Main branch: volledige SAST + dependency scan (minder dan 5 minuten)
- Post-deploy staging: DAST + security load tests (parallel aan acceptatietests)
De echte winst zit niet alleen in de technische opzet. Het gaat ook om hoe je omgaat met de resultaten: trieer bevindingen op ernst, koppel ze terug naar het team in de taal van performance (impact op responstijd, risico op downtime), en zorg dat fixes onderdeel worden van de reguliere sprintplanning.
De menselijke factor: security champions en cultuurverandering
"Ik ben performance engineer, geen security expert." Klinkt dat bekend? Grappig genoeg hebben performance testers juist de perfecte instelling voor security: je denkt al in randgevallen, knelpunten en faalscenario's. Security testing in CI/CD is gewoon een andere lens op dezelfde problemen.
Het echte probleem is niet kennis, maar prioriteit. Developers krijgen story points voor features, niet voor security fixes. Performance testers worden beoordeeld op responstijden, niet op voorkomen inbreuken. Die scheefgroei in prioriteiten moet je doorbreken, want zolang security "erbij" moet, gebeurt het niet goed.
Wat we bij succesvolle teams zien, is dat ze de rollen combineren. Als performance tester ben je al de persoon die naar de pipeline kijkt, metrics analyseert en knelpunten identificeert. Security is een natuurlijke uitbreiding van die rol. Geen extra pet, maar een bredere blik.
Een fintech in Utrecht deed dit briljant. Hun performance team kreeg elke sprint 20% tijd voor beveiligingstaken. Geen vage training, maar concrete opdrachten:
- Rate limiting implementeren op authenticatie-endpoints
- DAST-resultaten analyseren op performanceimpact
- Security load tests schrijven die DDoS-patronen simuleren
Het resultaat? Security werd geen extra taak maar onderdeel van het dagelijkse werk. De teamlead zei het treffend: "We zijn gestopt met kiezen tussen snel óf veilig. Nu gaan we voor snel én veilig."
Metrics maken daarbij echt het verschil. In plaats van alleen "aantal security issues" te meten, kijk je naar:
- Security overhead: hoeveel performance kost onze beveiliging?
- Detectietijd: hoe snel vinden we security issues?
- Testdekking: welk percentage van onze kritieke paden is getest?
Visualiseer dit naast je performance dashboards. We kennen een team dat Grafana gebruikt met panelen voor responstijd, foutpercentage én securitybevindingen naast elkaar. Security testing wordt zo onderdeel van je dagelijkse CI/CD-werkwijze, niet iets dat je elk kwartaal even doet.
En eerlijk? De grootste winst zit vaak in het anders bekijken van security. Het is geen compliance-checkbox. Het is het voorkomen van de ergste performanceproblemen: niet die waarbij je systeem langzamer wordt, maar die waarbij het helemaal platgaat.
De waarde van preventieve maatregelen is meetbaar: elke kwetsbaarheid die je vóór productie vindt, scheelt gemiddeld tien keer de reparatietijd achteraf, en dat zijn uren die je performance team aan echte verbeteringen kan besteden.
Metrics en continue verbetering: van paniek naar proactief
Als performance tester leef je van metrics. Responstijden, throughput, foutpercentages, data is je kompas. Security testing in je CI/CD pipeline verdient diezelfde datagedreven aanpak, maar veel teams meten de verkeerde dingen.
"Aantal gevonden kwetsbaarheden" is een ijdele metric. Net zoals "aantal uitgevoerde performance tests" niets zegt over je werkelijke performance. Je hebt metrics nodig waar je iets mee kunt.
Mean time to remediation (MTTR) is daarbij je belangrijkste metric. Een e-commerce platform mat dit consequent en ontdekte een opvallend patroon: kritieke issues werden binnen 4 uur gefixt, maar gemiddelde issues bleven gemiddeld 21 dagen open. Waarom? Developers zagen die als "niet urgent."
De oplossing was briljant in zijn eenvoud. Ze stelden een beveiligings-SLO op, een service level objective specifiek voor security:
- Kritiek: fix binnen 4 uur
- Hoog: fix binnen 24 uur
- Gemiddeld: fix binnen 72 uur
- Laag: fix binnen de sprint
Maar de echte slimme zet? Ze koppelden security metrics aan performanceimpact:
- Deze SQL injection kan honderd keer hogere querytijd veroorzaken
- Deze XXE-kwetsbaarheid kan geheugenuitputting triggeren
- Deze authenticatieomzeiling kan leiden tot resourceuitputting
Plotseling waren security issues geen abstracte risico's meer, maar concrete performancebedreigingen. Dat maakt het gesprek met developers een stuk makkelijker.
Beveiligingsschuld is een andere krachtige metric. Net zoals je technische schuld bijhoudt, kun je beveiligingsschuld tracken. Een team dat we kennen visualiseerde dit als potentiële downtime: hoeveel uur uitval kunnen deze kwetsbaarheden theoretisch veroorzaken? Dat vertaalt beveiligingsschuld naar bedrijfsimpact, en dát snapt iedereen.
Security volwassenheidsladder voor performance teams
Om te zien waar je staat en waar je naartoe kunt groeien, helpt een eenvoudig volwassenheidsmodel:
| Niveau | Aanpak | Hersteltijd | Dekking |
|---|---|---|---|
| 1: Reactief | Security scans na grote releases | 2-4 weken | 20% |
| 2: Gepland | Wekelijkse security scans | 3-5 dagen | 60% |
| 3: Geïntegreerd | Security volledig in CI/CD | 24-48 uur | 90% |
| 4: Proactief | Security-first development | Minder dan 4 uur | 100% incl. dependencies |
| 5: Voorspellend | Kwetsbaarheidsdetectie op basis van machine learning | Preventie | Incl. third-party services |
De meeste teams die we tegenkomen zitten op niveau 1 of 2. En dat is prima als startpunt. Een SaaS-platform dat we begeleidden bereikte niveau 4 binnen 18 maanden. Hun aanpak was eigenlijk simpel: ze behandelden security metrics als performance metrics. Dashboards toonden securitybevindingen naast responstijden. Sprintreviews bespraken securityverbeteringen naast performancewinsten. Het werd geen aparte discipline maar gewoon onderdeel van goed vakmanschap.
Wat ook goed werkt: security metrics gebruiken als vroegtijdig waarschuwingssysteem voor performanceproblemen. Een piek in mislukte inlogpogingen? Check of je authenticatieservice niet overbelast raakt. Meer SQL injection-pogingen? Mogelijk staat je database onder druk. Die correlatie tussen security-events en performancedegradatie is verrassend sterk.
Van bijzaak naar automatische poortwachter
Security testing in je CI/CD pipeline voelt misschien als overhead. Nóg een tool, nóg een proces, nóg iets om te monitoren. Maar als performance tester weet je: de duurste performanceproblemen zijn die je niet ziet aankomen.
Een SQL injection die je database overbelast. Een XML-bom die je geheugen uitput. Een authenticatieomzeiling die een DDoS-aanval mogelijk maakt. Dit zijn geen losse security issues, het zijn de ergste performanceproblemen die er bestaan, en ze komen via beveiligingslekken binnen.
De verschuiving is eigenlijk simpel: stop met denken aan security testing als extra werk in je CI/CD. Zie het als een uitbreiding van je performance testing toolkit. Je test al voor randgevallen, faalscenario's en onverwachte belasting. Security testing voegt daar alleen nieuwe scenario's aan toe.
Begin praktisch. Deze week nog:
- Installeer Semgrep in je development environment
- Schrijf één security-gerichte load test, bijvoorbeeld: wat gebeurt er bij 1000 mislukte inlogpogingen per minuut?
- Voeg OWASP ZAP toe aan je stagingpipeline, zonder dat het builds blokkeert
Geen grote verandering of maanden planning, gewoon drie concrete stappen die je beveiliging verbeteren zonder je delivery te vertragen.
Want uiteindelijk is een veilig systeem een performant systeem. Je kunt niet het ene hebben zonder het andere. En als performance tester heb je de unieke positie om beide te waarborgen. Door security testing te integreren in je CI/CD pipeline voorkom je niet alleen beveiligingslekken, maar ook de performancedegradatie die daaruit voortkomt.
De vraag is niet óf security testing je CI/CD pipeline zal vertragen. De vraag is: hoeveel performanceproblemen kun je voorkomen door security serieus te nemen?
Wil je eens sparren over hoe je security en performance kunt combineren in je pipeline? We denken graag met je mee.
Wil je onderdeel worden van een team dat security testing net zo serieus neemt als performance? Bij YTP helpen we bedrijven hun pipelines bulletproof te maken.
