Yes. Twelve-factor says an app should declare all dependencies completely and exactly in a manifest and isolate them at runtime. A complete manifest is the input every software composition scanner and SBOM generator needs, so incomplete declarations become blind spots in your vulnerability data.
What the rule says
The methodology states that a twelve-factor app never relies on the implicit existence of system-wide packages. It declares every dependency in a manifest, and uses an isolation tool at runtime so nothing leaks in from the surrounding system. It adds that declaration and isolation must be used together, and that the same specification applies to production and development. It also says the app should not assume system tools such as curl or ImageMagick exist, and that a needed tool should be vendored into the app.
Why this matters to security
A scanner can only match what it can see. Typical blind spots look like this.
| Gap | Effect on scanning |
|---|---|
| Package installed by hand in the image but not in the manifest | Never appears in the dependency graph |
| System library the app calls through a shell command | Missed by language level scanners, found only by image scanning |
| Version ranges with no lockfile | The scanner sees a range, not what was installed |
| Vendored copy of a library with its metadata removed | Looks like first party code |
| Dev only packages mixed with runtime ones | Noise, or the opposite when they are dropped silently |
If the manifest and a lockfile are complete, a build produces the same set of packages every time. Then a finding today is a finding about what is running, not a guess. See committing lockfiles by ecosystem for per language advice.
Isolation is a security feature too
Isolation limits what the app can pick up by accident. If a build can only see what the manifest declares, an unexpected package on the build host cannot silently change behavior. It also supports the reproducibility that makes provenance checks possible.
Shelling out to system tools deserves special mention. A call to a binary that happens to exist on today's host may behave differently, or not exist, tomorrow. From a security view, each such binary is an unversioned dependency you are not tracking. Vendor it, or move it into a declared package.
Steps to get there
- Pick one manifest and lockfile per application and commit both.
- Build from the lockfile with the frozen install flag for your tool.
- Avoid installing packages in the Dockerfile outside the manifest, or record them too.
- Generate an SBOM from the build, not from a guess about the source.
- List system tools your code shells out to and decide whether to vendor or replace them.
- Scan the finished image as well as the manifest, since the image includes operating system packages.
- Re-scan on a schedule, because new advisories arrive after you ship.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and see how direct and transitive packages are listed, then ask what would be missing if a package were not declared.
Quick check
Is a lockfile part of explicit declaration?
In practice yes. A manifest with ranges says what you allow, and the lockfile records what was resolved, which is what scanners and SBOMs need.
Why scan the image if I scan the manifest?
The image also contains operating system packages and files that are not in the language manifest, so each scan sees something the other cannot.
Do dev dependencies matter for security?
They can, because build tools run on your machines and in CI. Treat them as a separate risk from runtime packages, not as irrelevant.
Where Safeguard fits
Safeguard scans dependencies and builds SBOMs, and its reachability analysis helps you separate vulnerable packages your code actually calls from those it does not. You can try a free scan at gold.safeguard.sh/scan. The SCA dependency inventory demo shows what a complete manifest produces.
Sources
Last reviewed: 19 October 2026.
