At 5 engineers, run dependency scanning and a few tests on your riskiest rules. At 25, add static analysis on pull requests and a dynamic scan of staging. At 100, add triage ownership, tiered baselines, fuzzing for parsers and independent testing. Headcount changes who owns results more than which methods exist.
Why team size matters
Tools do not get harder with size. Ownership does. A five-person team can review every finding in a coffee break. A hundred-person organisation has services nobody remembers writing. The testing mix should follow the number of people who need to act on results.
The sizing table
| Engineers | Run | Owner | Cadence |
|---|---|---|---|
| About 5 | Dependency scanning, lockfiles committed, tests for access rules | Whoever merges code | Every pull request |
| About 25 | Add static analysis on pull requests, dynamic scan of staging, a written severity policy | One named security champion | PR checks plus weekly staging scan |
| About 100 | Add risk tiers, fuzzing for parsers, authenticated dynamic scans, independent testing for top tier apps | A small security team plus champions per group | PR checks, nightly scans, yearly external test |
These are starting points, not rules. A five-person team handling payment data should behave like a larger one for that app.
What to add at each step
From 5 to 25. Reviews stop being informal. Introduce a rule for what blocks a merge, and keep it narrow at first. OWASP notes that static analysis can be run repeatedly, such as with nightly builds or continuous integration, which suits a growing team that cannot review every change by eye.
From 25 to 100. Findings pile up faster than people can read them. Add deduplication, ownership by repository, and age targets by severity. This is also when tiering apps by risk starts to pay for itself.
Signs you outgrew your current stack
- Findings sit unassigned for weeks.
- Different teams use different scanners and nobody can compare results.
- A customer security review asks for evidence you cannot produce quickly.
- A bug in your own code reached production that no tool flagged.
Any one of these means the next step is due.
What not to do
- Do not buy for the team you hope to be in two years. Unused tools breed ignored alerts.
- Do not add a method without a named owner for its results.
- Do not measure success by number of scans. Measure how fast serious findings are fixed.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis, policies and gates work at every row of this table, and its compliance evidence automation helps once customers start asking for proof. Static, dynamic and fuzz testing remain separate tools in your stack. Try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped and assigned, which is the part that gets harder as teams grow.
Quick check
Should a five-person startup run static analysis?
It can, but dependency scanning gives more value for less triage time. Add static analysis when the team writes enough custom logic to justify it.
When does a team need a dedicated security hire?
When findings go unowned despite having tools, or customer reviews consume engineering time regularly.
Sources
Last reviewed: 19 October 2026.
