Fractional DevSecOps: a security analysis of your software
A security engineer a few days a month, without hiring one.
What you get
- 01One report per build with a risk index, from SAST, DAST and SCA read together
- 02CI pipeline with blocking checks and a written reason next to each threshold
- 03SBOM on every build and documented proof that each check fails when it should
The moment this page becomes useful is usually one of three. A larger customer has sent you a security questionnaire. A tender asks you to show how you control the software you deliver. Or NIS2 has reached you along the supply chain. In all three cases you do not need consulting that produces documents: you need to show that the checks exist, run on every build and block.
Most companies that build software do not have a security engineer and do not need a full-time one. They need someone who looks at their code, their dependencies and their running application with the right tools, says what matters, and leaves checks that keep working afterwards. That is what I offer, a few days a month, in three phases.
Phase 1, analysis
I analyse the software you already have on three layers. The source code with SAST (SonarQube). The running application with DAST (OWASP ZAP), which attacks it from outside the way an attacker would. Every library and component with an SBOM in CycloneDX format held in Dependency-Track (SCA). An agent I built reads the three results side by side and I review its conclusions. You receive one report: an overall risk index, the findings that matter, the ones that can wait, and why.
Phase 2, into the pipeline
The same checks move into your CI/CD, GitLab CI, GitHub Actions or whatever you use, with blocking thresholds written in the repository and the reason next to each one. Before trusting them, each check is made to fail on purpose. A green check sends the same signal when everything is fine and when it is broken: on one project an observer was attached to a DOM node that did not exist, watched nothing and stayed green. The only way to tell the difference is to provoke the failure.
Phase 3, follow-up
A few days a month: reading the reports with your team, deciding what to fix first, being ready when a critical vulnerability is published. With an up-to-date SBOM, “are we affected?” becomes a query instead of an inventory hunt.
Where it comes from
With Dfence I ran a continuous vulnerability assessment service on about 100 appliances at customer sites. As CTO of a B2B software vendor I built the GitLab pipeline stage that reads SAST, DAST and SCA together. On an e-commerce store of about 2,400 products I brought a stack frozen for months up to date one component at a time, with an automated suite grown from 36 to 58 tests and a rollback that was actually rehearsed.
What I do not do
No 24/7 security operations centre, no forensic incident response, no manual penetration testing. Scanners find known classes of weakness: they do not replace a penetration test on critical systems, and a false negative in a tool stays a false negative after the agent.