Check how much of what you ship is imported versus written by your team. If imported code dominates, tilt effort toward dependency scanning and update discipline. If your own logic dominates, tilt toward static analysis, review and dynamic testing. Most apps need both, but the weighting should differ.
A quick ratio check
You do not need exact numbers. Answer three questions.
- Roughly how many lines live in your repositories, excluding vendored code?
- How many packages does the lockfile list, including transitive ones?
- How much of the app's behaviour comes from a framework or hosted service versus your own rules?
A web app with a few thousand lines of your code and several hundred packages is dependency-heavy. A trading engine with a hundred packages and a large proprietary core is custom-heavy. Write your guess down. The point is a direction, not a decimal.
OWASP's component analysis page notes that organisations take responsibility for code they did not write when they use open source. That responsibility grows with the share of imported code.
The tilt table
| Profile | Spend most effort on | Keep a baseline of |
|---|---|---|
| Dependency-heavy | Dependency scanning, update cadence, reachability to rank findings | Static analysis on your own modules, tests for access rules |
| Balanced | Equal split, with ownership per method | Dynamic scan of staging |
| Custom-heavy | Static analysis, code review, dynamic testing, fuzzing of parsers | Dependency scanning on every change |
Notice that nobody gets zero. Dependency-heavy apps still contain your authentication code, and custom-heavy ones still import a logging library.
What "tilting" looks like in practice
For a dependency-heavy app:
- Set a target for how old a critical fix may stay unmerged.
- Automate update pull requests, with tests to catch breakage.
- Use reachability to separate flaws your code can trigger from the rest.
- Review new dependencies before adding them. Fewer packages means a smaller surface.
For a custom-heavy app:
- Run static analysis on pull requests and tune rules so developers keep reading them.
- Review code touching authentication, payments and data export by hand.
- Fuzz parsers and decoders.
- Run authenticated dynamic scans against a realistic staging copy.
When the ratio changes
Ratios drift. A prototype built on a framework grows custom logic. A custom system adopts a big library and quietly becomes dependency-heavy. Revisit the ratio when architecture changes, not on a fixed calendar.
Where Safeguard fits
For dependency-heavy apps, Safeguard provides SBOM and dependency scanning, reachability analysis to rank findings, autonomous remediation with fix PRs (off by default, every category on Manual), and gates. Custom code testing comes from other tools. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the number of direct dependencies to the full inventory to get a feel for your ratio.
Quick check
Can a small app be both dependency-heavy and risky?
Yes. A few lines of authentication glue over a vulnerable library is still high risk. The ratio guides effort, not importance.
How often should I re-check the ratio?
When architecture changes or a major dependency is added or removed. A fixed yearly check also works.
Sources
Last reviewed: 19 October 2026.
