How do you manage C and C++ dependencies securely?

C and C++ projects pull code through several routes: system packages, vendored source, a package manager such as Conan or vcpkg, and CMake downloads. Secure management means pinning every route to an exact version or hash, recording what you ship in an SBOM, and having a way to find and patch vulnerable libraries.

Why is C and C++ dependency management different?

There is no single registry that every project uses. A project may copy a library into a third_party folder, link whatever the build machine has installed, or fetch an archive at configure time. Each route can drift quietly. A vendored copy stops getting fixes. A system library differs between your laptop and your build server.

CISA's Product Security Bad Practices guidance asks software makers to maintain an SBOM in a machine readable format covering first and third party dependencies, and to have a process for managing the incorporation of open source software. For C and C++ that guidance is hard to meet unless dependency sources are explicit.

How do lockfiles work in Conan?

The Conan 2 documentation describes lockfiles as a mechanism to achieve reproducible dependencies even when new versions or revisions of those dependencies are created. You generate a lockfile after resolving the graph and commit it, and later builds resolve to exactly the same versions and revisions. Without one, a version range can pick up a new release the day it is published.

How does vcpkg pin versions?

The vcpkg versioning documentation describes three tools. A builtin-baseline in the manifest sets a global version floor for the built-in registry. A version constraint on a dependency requires a minimum. And an override forces vcpkg to ignore other constraints and use the version you name, which the docs say is useful for pinning exact versions and resolving conflicts. The docs also state that if a manifest has no builtin-baseline and no registries, vcpkg ignores versioning information entirely. That default is the one to avoid.

What about CMake downloads?

The CMake FetchContent documentation shows downloads declared by git tag or by archive URL with a URL_HASH. It advises that where contents are fetched from a server you do not control, you should use a hash for verification. A git tag can be moved by whoever owns the repository, so pin a full commit identifier, and add a comment noting the release it corresponds to.

Constructed example

A small embedded firmware team vendors a compression library as a folder copy made two years ago. A security advisory lands for the upstream project, but nobody connects it to the copy because no manifest lists it. The team moves the library into vcpkg with an override pinned to the fixed version, commits the manifest, and generates an SBOM on each release. The next advisory is matched to a name and a version in minutes.

What to do

1. List every route dependencies enter: package manager, vendored folders, CMake downloads, system packages, container base images.
2. Move vendored code into a manager where practical. Where it must stay vendored, record its upstream, version and patch notes in a manifest.
3. Commit a Conan lockfile or a vcpkg manifest with a builtin-baseline. Use overrides sparingly and write down why.
4. Pin CMake downloads with a commit hash or URL_HASH.
5. Build in a clean container so system libraries are the ones you chose.
6. Generate an SBOM for every release and keep it with the artifact.
7. Check the SBOM against vulnerability data regularly. Safeguard supports SBOM generation and dependency scanning, and its reachability analysis can help you decide which advisories matter first.
8. Budget time to bump pins. A pin you never update is a slow vulnerability.

Quick check

Sources

• Conan 2 documentation: Lockfiles
• vcpkg documentation: Versioning
• CMake documentation: FetchContent
• CISA: Product Security Bad Practices

Last reviewed: 18 October 2026.