Audit the Open-Source Packages Your Business Uses
Matthew Leo · Published October 9, 2026 · Guides
Most business software contains open-source code, including packages that developers never selected directly. A library can bring in dozens of transitive dependencies, and a vulnerable component is hard to patch if nobody knows which application contains it.
A practical audit should answer four questions: what is running, where it came from, what it can reach and who owns the next decision. A scanner can help build that picture, but its score is not the decision.
Start with the software you actually run
List production applications, internal tools, build pipelines, containers, desktop utilities and internet-facing services. Include systems operated by contractors and software-as-a-service products when the supplier can provide component information. Name an owner for each system before collecting package data; an unowned list will age immediately.
For every repository, preserve manifest and lock files. Manifests describe requested packages, while lock files record the versions actually resolved. Container images and compiled applications may include components that do not appear in the main repository, so inspect build artifacts too.
GitHub's dependency graph can identify direct and transitive packages in supported ecosystems and export an SPDX-compatible software bill of materials. Other source hosts and build tools can produce CycloneDX or SPDX files. The format matters less than repeatability: regenerate the inventory for every release and retain the result with that release.
Make the SBOM useful, not ceremonial
The Canadian Centre for Cyber Security describes a software bill of materials as a nested inventory that helps organizations understand their supply chain and respond to disclosed vulnerabilities. Joint 2026 guidance says an SBOM should cover open-source, proprietary, AI and software-as-a-service components.
At minimum, capture the component name, supplier or project, exact version, unique identifier, dependency relationship and the product or release where it appears. Record the tool and time that produced the inventory. If two tools disagree, investigate rather than merging their outputs into a false sense of precision.
An SBOM is a snapshot, not a security verdict. It will not tell you whether a vulnerable function is reachable, whether a package was replaced during the build or whether a maintainer account has been compromised.
Prioritize exposure before raw severity
Join the inventory to current vulnerability advisories, then rank findings using the environment around them:
- Reachability: does the application call the affected function?
- Exposure: can an internet user, ordinary employee or untrusted file reach it?
- Privilege: what data, secrets or systems can the process access?
- Exploit evidence: is reliable exploitation known, or is the issue theoretical in this deployment?
- Recovery: can the component be patched, disabled or isolated quickly?
A critical package inside a disabled test feature may be less urgent than a medium-severity flaw exposed to every customer. Document that reasoning. “Not affected” should include evidence, a reviewer and an expiry date in case the application changes.
Check project health and provenance
OpenSSF Scorecard can flag signals such as branch protection, signed releases, maintained status and risky build practices. Treat those results as prompts for review. A quiet project is not automatically unsafe, and a high score does not prove that a release is clean.
For important dependencies, verify the official repository and package publisher, licence, release history, security policy and maintainer activity. Look for unexplained ownership changes, deleted releases, moved tags and packages whose names resemble a trusted project. Prefer pinned, reviewed versions and protect the credentials that can change build files.
Licence obligations belong in the same inventory. Some packages require attribution or source-sharing when distributed. The Cyber Centre specifically advises organizations to understand licensing and jurisdictional restrictions, not just technical vulnerabilities.
Turn findings into controlled updates
- Create a small pull request that changes one dependency family at a time.
- Review release notes and breaking changes; do not assume the newest major version is a drop-in fix.
- Run unit, integration and security tests in an isolated environment.
- Compare the rebuilt SBOM with the previous release so unexpected additions are visible.
- Deploy gradually, monitor errors and keep a tested rollback path.
- Close the finding only after confirming the production version.
Automatic update tools can open pull requests and surface known vulnerabilities. They should not merge security-sensitive changes without tests and review. Mapletechie's guide to two compromised GitHub Actions shows why a familiar package name or version tag is not enough; teams must also know which code ran and what credentials it could reach.
Set a cadence that matches change
Generate an inventory on every production build, monitor advisories continuously and review project health at least quarterly for critical dependencies. Reassess immediately after a maintainer change, repository transfer, signing-key incident or unexpected release.
The audit is complete only when each high-risk item has an owner, decision, deadline and evidence. The goal is not a perfect list of every package. It is the ability to answer quickly when a component becomes dangerous.
Sources
- Canadian Centre for Cyber Security: open-source security considerations
- Canadian and international guidance: minimum SBOM elements
- CISA: SBOM resources and implementation guidance
- OpenSSF Scorecard: check definitions and limitations
- GitHub: dependency graph and SBOM export
Tags: open source, SBOM, software supply chain, cybersecurity, Canada