After a library vulnerability is fixed, programs that link it dynamically pick up the fix when the shared library file is updated and the program restarts. Programs that link it statically contain their own copy of the old code and stay vulnerable until you rebuild and redeploy them.
What the two terms mean
| Linking | Where the library code lives | Fix arrives by |
|---|---|---|
| Dynamic | In a separate shared library file loaded at run time | Updating that file, then restarting the process |
| Static | Copied into your executable at build time | Rebuilding your executable |
The same advisory therefore has a different response plan depending on how each product was built. A shared library fix can reach many programs at once. A static copy is invisible to the operating system's package list, because the code is inside your binary.
Why this matters to patching
Operating system updates fix what the system tracks. If your service is statically linked, an update to the system library may change nothing about your service. The reverse is also true: if you ship a container with your own copy of a library, the host's updates do not touch it.
Questions to ask for each advisory:
- Does our binary load the library at run time, or contain it?
- If it loads it, is the library file in our image or on the host?
- If it contains it, which build produced that binary, and when?
How to tell
For an executable you trust, list the shared libraries it needs. A library that appears in the list is dynamic. A library you know you use that is missing from the list may be statically linked, or compiled in. See how to list shared libraries safely for the commands and a warning about untrusted files.
Your build system is a second source. In a CMake project, a library requested as static is built into the executable. Your lockfile or SBOM should say which version went into each build, so you can search for the affected version.
Trade-offs, plainly
- Dynamic linking: one fix point, smaller binaries, but your behaviour depends on whatever library version is present at run time.
- Static linking: predictable behaviour and easy shipping, but every fix needs a rebuild of every product that embeds it.
Neither is more secure by itself. The risk is not knowing which one you have. A team that statically links needs a fast rebuild pipeline and an inventory by build. A team that links dynamically needs control of what is installed on each target.
Steps for your next advisory
- Find every product that includes the affected library, from the SBOM.
- Mark each as static or dynamic.
- For dynamic ones, update the library and restart processes that still hold the old one in memory.
- For static ones, bump the pinned version, rebuild, test and redeploy.
- Record the fixed build identifiers as evidence.
Quick check
Does restarting matter after a shared library update?
Yes. A running process keeps the old code loaded until it restarts.
Can the operating system update a static copy?
No. The code is inside your executable, so you need to rebuild it.
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.
Last reviewed: 19 October 2026.
