Use ldd on binaries you built or trust, and use objdump with the private headers flag for anything untrusted. The ldd manual warns that some versions may run the program, which can execute arbitrary code. objdump only reads the file and shows the NEEDED entries, which are the direct dependencies.
Why this question comes up
When an advisory lands for a native library, the first job is working out which of your binaries use it. For C and C++ products there may be no lockfile entry for a library that is linked at build time or bundled, so the binary itself is the evidence.
The two commands
# Trusted binary you built yourself
ldd ./myservice
# Untrusted or unknown binary
objdump -p ./unknown | grep NEEDED
The ldd manual page says it lists the shared libraries a program needs, where each is found, and the address where it is loaded. It does this by running the dynamic linker with a trace variable set.
It then gives the warning that matters: never use ldd on an untrusted executable, because that may result in execution of arbitrary code. For untrusted files it suggests objdump with the p flag, filtered for NEEDED.
What each approach shows
| Command | Shows | Risk |
|---|---|---|
| ldd | The full resolved tree and where each library was found | Some versions may run the program or its interpreter |
| objdump p with grep NEEDED | Direct dependencies only, by name | Reads the file, does not run it |
The objdump route shows direct dependencies only, not the full tree. To follow transitive dependencies safely, repeat it on each library file it names, or work inside an isolated container.
Turning output into an inventory
- Run the safe command for each binary in your release.
- Record the library names. These are file names such as a name plus a major version, not full versions.
- Find the real version by asking the package manager that installed the file, or by reading the library's own version string.
- Add each library to your SBOM with the version and where it came from.
- Repeat on every release, since a base image update can change the answer.
Limits
This approach finds dynamic dependencies only. Libraries linked statically do not appear in NEEDED entries at all. Pair it with build records, as described in who must rebuild after a library fix.
Also remember that a library file name does not carry a patch level. A distribution may have fixed a flaw without changing the visible version, so check the package record, not only the file name.
Quick check
Is ldd safe on a binary from the internet?
No. The manual says never to use it on an untrusted executable. Use objdump with grep for NEEDED instead.
Does objdump show every library?
It shows direct dependencies. Repeat on each library to walk the tree, and note that static copies do not appear.
Safeguard's SBOM and dependency scanning can build an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Sources
Last reviewed: 19 October 2026.
