A security testing pyramid arranges checks by cost and speed. The wide base holds fast automated checks that run on every change. The middle holds slower scans on a schedule. The narrow top holds expensive human-led testing a few times a year. Run the base constantly and the top rarely.
The idea in plain words
Software teams already use a pyramid for functional tests: many quick unit tests, fewer integration tests, a few slow end-to-end tests. Security testing benefits from the same shape. Fast checks give quick feedback and catch most routine mistakes. Slow and costly checks are saved for questions only they can answer.
The layers
| Layer | Runs | Examples | Feedback time |
|---|---|---|---|
| Base | Every commit or pull request | Dependency scanning, linters, unit tests for access rules, quick static checks | Minutes |
| Middle | Nightly or weekly | Dynamic scan of staging, longer static scans, fuzz runs, container image scans | Hours |
| Top | Quarterly or yearly | Independent penetration test, manual code review of sensitive paths, threat modelling workshops | Days to weeks |
OWASP notes that static analysis can be run repeatedly, as with nightly builds or continuous integration, and that dynamic scanners probe a running app from outside. That naturally places static checks lower on the pyramid and dynamic scanning higher, since it needs an environment and more time.
How to build yours
- List your current checks and mark how long each takes and how often it runs.
- Move quick checks down. If a two-minute check runs nightly, put it in the pull request.
- Move slow checks up. If a forty-minute scan blocks every merge, move it to nightly and keep a fast subset in the pull request.
- Fill the base first. A thin base with a thick top is the common anti-pattern: expensive annual tests finding things a free scan would have caught.
- Reserve the top for what automation cannot judge: business logic, chained attacks, new architecture.
Why the shape works
Fast feedback is acted on. A developer sees a failing check minutes after writing the change and fixes it while it is fresh. A report that arrives a month later competes with everything else. Cheap checks also make exceptions cheap, so teams are willing to enforce them.
Warning signs
- Top-layer findings that a base-layer check could have found. Add that check to the base.
- Base checks so noisy that people ignore them. Tune them.
- No layer owns a risk, such as parser crashes. Add a check.
Where Safeguard fits
Safeguard lives mainly in the base and middle layers for dependencies: SBOM and dependency scanning on each change, gates on pull requests, and continuous monitoring afterwards. It does not replace static, dynamic or manual tests. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Where do penetration tests belong?
At the top: a few times a year, focused on what automation cannot judge, such as chained logic flaws.
What goes in the base layer first?
Dependency scanning and tests for your access rules. They are quick, cheap and catch common problems early.
Sources
Last reviewed: 19 October 2026.
