Yes. Language packages often carry native code that a manifest scan does not list. Cargo's documentation names building a bundled C library as a typical build script job, and NuGet packages can include a native folder of assets. The vulnerable library may be inside a package you only know by a higher level name.
Why this matters for hygiene
You scan your dependency list and see a Rust crate or a .NET package. An advisory lands for a C library that nobody on your team knowingly uses. Your scanner shows nothing, because the C library is not a declared dependency. It is inside something else.
This is a gap in inventory, not a failure of locking. A perfectly locked install can still ship a native library you have not heard of.
Where native code shows up
| Ecosystem | How native code can arrive | Documented detail |
|---|---|---|
| Cargo | Build script compiles or finds a C library | The Cargo reference lists building a bundled C library and finding a C library on the host |
| NuGet | Package ships a native assets folder | Native is one of the asset types NuGet controls |
| npm | Install scripts may compile native code | Lifecycle scripts run on install |
The Cargo build script docs also describe finding a C library on the host system. In that case, the native code comes from the machine, not the package, so two builds on two machines can differ. That matters for reproducibility as well as for inventory.
What your inventory misses
A declared dependency list shows names and versions of packages. It does not usually show:
- A C library statically linked by a build script.
- A copy of a library vendored inside a package's source tree.
- A system library found at build time on the host.
Whether an SBOM carries this information depends on what your generator can detect. The point is to know the limits of what it sees.
Steps to improve visibility
- Scan the built artifact, not only the manifest. A container image or binary shows what actually shipped.
- List build dependencies separately. Note which packages have build scripts or native assets.
- Pin the build environment. If a build script uses a host library, record the base image digest or toolchain.
- Ask maintainers. A package's documentation or changelog may say which native libraries it bundles.
- Track advisories for the native library by name. Add an entry for it in your inventory by hand when you learn it is there.
A realistic stance
You will not find every bundled library. Aim for a process that catches the ones that matter: widely used libraries that appear in advisories. When one does, search your artifacts, not only your manifests.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Does a lockfile list bundled native libraries?
Not generally. It lists packages. A native library compiled by a build script or shipped in a package's assets may not appear as its own entry.
Why scan the built artifact?
It shows what actually shipped, including things the manifest does not name.
Sources
Last reviewed: 19 October 2026.
