Three security tools, three reports, one decision
SAST, DAST and SCA each see one layer. An agent in GitLab CI reads all three per build and returns one report: what blocks the release, and why.
TESTABLE QUESTIONS / REPRODUCIBLE EVIDENCE
I measure production software with evidence you can reproduce
I set conditions and thresholds first. I test hypotheses, compare alternative explanations and state what the evidence does not prove.
How I verify a measurement →THE PROTOCOL
- 01QuestionWhich decision should change?
- 02HypothesisWhat could disprove it?
- 03TestConditions and limits before results
- 04VerificationRepeatability, alternatives and limits
SERVICES / MEASURES
Measured outcomes from client work
01Custom data scraping and analysisReliable data from sources that offer no API.2,393PRODUCTS CHECKEDExternal audit of a real catalogue02Application load and stress testingKnow the load at which it gives way, and how.3GET/sSUSTAINED 10 MINUTESp95 1.102 s on an isolated VPS03Fractional DevSecOps: a security analysis of your softwareA security engineer a few days a month, without hiring one.3ANALYSIS LAYERSSource code, running application, components04Front-end performance and measured Core Web VitalsA green lab score and a slow site for real users coexist comfortably.33%LOWER TTFBFrom 954 to 636 ms at the origin, on desktop
A HYPOTHESIS DISPROVED BY LOGS
Full case report →Hypothesis: the import code caused the HTTP 500 errors. Four logs from different layers instead showed that the host was killing PHP processes.
101 HTTP 500 errors106 successful calls
THE SCIENTIFIC METHOD IN PRACTICE
The threshold is set before seeing the result
For the load test, I fixed the traffic, conditions and failure criteria before running it. The result only means something alongside the protocol that produced it.
LOAD TEST PROTOCOL01/04
- 01Question: which resource saturates first?
- 02Control: isolated origin, no CDN, fixed arrival rate
- 03Thresholds: p95 under 3 s, errors under 1%, zero dropped iterations
- 04Limits: no checkout, no test on the current server
I work on software that is already running, when there is a question the current monitoring does not answer. I frame it so a test can disprove the first explanation. Before measuring, I set the environment, sample and threshold; afterwards, I check whether the data support an alternative reading.
For one nightly import, the initial explanation was a code defect. Four logs from different layers disproved it: the host was killing PHP processes. For a load test, I instead set the latency and error limits in advance; at 6 requests per second, latency crossed the threshold. Different problems, same method.
I hand over the numbers with the protocol, commands to repeat it and an explicit list of what was not measured. If a number does not convince you, you can run it again yourself.
What I work on
Performance and Core Web Vitals, measured in your users’ browsers and not only in the lab. Load testing, with written authorisation before the first request. Fractional DevSecOps: a security analysis of your software with SAST, DAST and SBOM, pipeline checks proven to fail when they should, a few days a month. Data extraction and analysis from sources that offer no API.
Where I come from
Thirty years between customers and engineering teams, most recently as CTO of a B2B software vendor and as co-founder of Dfence, a continuous vulnerability assessment service running on about 100 appliances at customer sites. I have owned the consequences: slow checkouts, imports that break, security findings that surface at the wrong moment. Today I bring that judgement to one problem at a time.
Blog
All articles →START WITH THE EVIDENCE
A useful measurement changes a decision.
Tell me which question your current monitoring cannot answer.