A scan run once a year finds what changed in the other 364 days
Security Testing
A security scan run once before a big launch tells you almost nothing about the dozens of small changes that ship in the months after it. This practice treats security testing the way any other quality gate gets treated: wired into the pipeline and run on every relevant change. That catches a new vulnerability close to the commit that introduced it, rather than months later in an annual review.
How a security gate gets wired into an existing pipeline
SAST, DAST and dependency scanning running continuously, not once a year.
90 secSample frame · video pending01Before wiring the gate
SAST and DAST catch different things at different times
Most mature pipelines eventually run both, and the order they get added in matters more than picking a permanent favourite. Four questions settle where to start.
Do you need to catch issues before or after deployment?
SAST scans source code before anything runs, catching issues early. DAST tests a running application, catching what only appears at runtime.
What is your current dependency risk?
A codebase with many third-party dependencies benefits heavily from automated dependency scanning alongside SAST, since most real vulnerabilities arrive through them.
How mature is your current pipeline?
A pipeline with no scanning at all benefits most from SAST first, since it is faster to wire in and gives immediate, actionable findings.
What does your compliance obligation actually require?
Some compliance frameworks specifically expect both static and dynamic evidence, which settles the question regardless of engineering preference.
| SAST | DAST | |
|---|---|---|
| Runs against | Source code, pre-deployment | A running application |
| Catches | Code-level flaws early | Runtime and configuration issues |
| Speed | Fast, fits every commit | Slower, fits staging or nightly runs |
| Best fit | Continuous pipeline gate | Pre-release runtime verification |
02Agreed before scanning starts
The ledger that keeps a scanning claim honest
Security testing fails quietly when scanning runs once, gets a clean report, and then nobody looks again until the next incident. This ledger sets out what you bring, what we scan and test, what comes back, and what stays under your ownership.
- Your side
You bring
- The current CI/CD pipeline and its existing quality gates
- The tech stack and dependency ecosystem in use
- Any prior scan results or known vulnerabilities already on record
- Our side
We build
- SAST and dependency scanning wired into the build step
- DAST scanning wired into a staging or pre-production step
- Severity thresholds set for what actually blocks a release
- Your side
You receive
- A working pipeline gate that flags new vulnerabilities automatically
- A baseline report of existing findings, triaged by severity
- A documented threshold policy the team can adjust going forward
Never leaves you
- The pipeline and the decision to adjust its gates
- The remediation timeline for findings below the blocking threshold
- The codebase and its dependency choices
Where the line sitsWe wire the gate and set the thresholds; you decide what severity actually blocks a release. A gate too strict gets bypassed, one too loose gets ignored.
03From scan to a running gate
Four stages, each closing on a live control
A vulnerability that lingers unnoticed usually traces back to one of these stages never getting wired in properly. This system closes each stage as a control that keeps running afterward.
Scan and triage by real severity
SAST, DAST and dependency scanning run against the current system, and findings get triaged by actual exploitability, not just a raw severity score from the tool.
Findings triaged, not just listedWire thresholds into the pipeline
Severity thresholds get set and wired into the pipeline directly, so a build carrying a genuinely dangerous vulnerability gets blocked automatically.
The gate that blocks the risky buildAdd exploit-style test cases to the suite
Test cases modelled on common attack patterns join the regular suite, checked on the same cadence as any other functional or regression test.
Attacker behaviour, tested routinelyMaintain the gate as the system changes
New dependencies, endpoints and features get folded into scanning scope as they ship, so coverage does not quietly fall behind the system it protects.
Coverage that keeps up with the codebase
04What actually moves the number
Four drivers, sized from the codebase
Security testing is priced against the codebase and pipeline in front of it, because these four factors change effort well beyond lines of code alone.
Size and complexity of the codebase
A small service with few dependencies scans faster than a large, sprawling codebase with a long dependency tree to check.
Current pipeline maturity
Wiring scanning into a pipeline with no existing gates costs less than reconciling scanning against a heavily customised, legacy pipeline.
Depth of exploit-style test coverage wanted
A baseline set of common attack-pattern tests costs less than coverage tailored to your system's specific, unusual attack surface.
Remediation backlog size
A clean or lightly used codebase costs less to triage than one carrying years of unaddressed scan findings.
05Evidence and proof
Vulnerabilities caught close to the commit that introduced them.
Security testing proof here is a finding caught by a running gate, not an annual report. These records carry that bar while written approvals are secured.
Explore case studiesA pipeline gate that caught a critical dependency vulnerability before release.
Vela Ledger had never wired dependency scanning into its pipeline. Within the first month of the new gate, a critical vulnerability in a third-party library got caught before a release shipped.
- Critical vulnerability caught pre-release
- 1
- Time from scan setup to first catch
- Under a month
A findings backlog of over two hundred items triaged down to twelve that mattered.
Nexa Foundry had accumulated scan findings for years with no triage process. Severity and exploitability review cut the backlog to the twelve genuinely urgent items.
- Findings in original backlog
- Over 200
- Findings triaged as genuinely urgent
- 12
Our old process was one scan a year and a scramble. Now it just runs, quietly, on every build.
Sample · pending client approval
06Read this first
When continuous scanning is not the right ask
Wiring in a continuous scanning gate when what a stakeholder actually wants is a discrete adversarial report solves the wrong problem. The exits are marked plainly.
You need a discrete, adversarial engagement with its own report
A time-boxed, scenario-driven attack simulation against a fixed target is a separate discipline that lives under the cybersecurity practice, not here.
- Functional Testing
The real gap is functional correctness, not exploitability
When the concern is whether a feature behaves correctly rather than whether it can be attacked, functional testing is the more direct fit.
- QA Consulting
You need the whole pipeline's quality gates redesigned
When security is one of several gates needing a rethink together, QA consulting can design the full set rather than security alone.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Pipeline gate setup | Scanning has never been wired into CI/CD | The severity thresholds and blocking policy | Scanning setup and pipeline integration |
| Backlog remediation | A scan already produced unaddressed findings | Remediation pace and compliance deadlines | Triage, fixes and verification |
| Ongoing coverage | The pipeline needs continuous security testing | Release cadence and risk appetite | Scanning, triage and exploit-style test cases |
07Straight answers
Asked before a pipeline security gate gets wired in.
01What's included in a security testing engagement?
Security testing wires SAST and DAST scanning into the CI/CD pipeline, adds vulnerability scanning as a routine quality gate, and folds ethical-hacking-style test cases into the regular suite. It runs continuously, not as a single scheduled event.
02How is this different from penetration testing?
Security testing here is continuous and pipeline-integrated, catching issues close to the change that introduced them. Penetration testing is a separate, discrete, time-boxed engagement with its own report, under a different practice.
03What is the difference between SAST and DAST?
SAST scans source code before deployment, catching issues early and fast. DAST tests a running application, catching runtime and configuration issues SAST cannot see.
04Do you fix the vulnerabilities you find, or only report them?
Both are available. Triage and prioritisation are standard, and fixing the highest-severity findings can run as part of the same engagement.
05Can this run without disrupting our existing pipeline?
Yes, scanning gets wired in as an additional step with thresholds tuned to your risk appetite, rather than replacing anything already in place.
06What does security testing cost?
Cost scales with codebase size, current pipeline maturity and any existing findings backlog needing triage. A clean, small codebase costs far less than a large one with years of unaddressed findings.
07Do you write test cases that try to exploit our own system?
Yes, ethical-hacking-style test cases modelled on common attack patterns get added to the regular suite and maintained as the system changes.
08How quickly can scanning start once we scope the work?
Basic SAST and dependency scanning can often start within a couple of weeks. DAST and deeper exploit-style coverage take a little longer to tune properly.