Open-Source Software Audit: Dependencies, Licences, Vulnerabilities and Maintenance Risk
How to audit open-source software: dependency inventory and SBOMs, licence review, known vulnerabilities, maintenance status and a remediation plan.
How do you audit open-source software?
Inventory every open-source component, including indirect dependencies, ideally as a software bill of materials; review licences and flag obligations for legal review; scan for known vulnerabilities; assess maintenance status; then prioritise fixes by how each component is used. Make vulnerability scanning continuous and repeat licence and maintenance reviews periodically. An audit identifies issues; it is not a legal opinion on licensing.
This guide is for engineering leads, CTOs and businesses preparing for due diligence or enterprise customer reviews. Software supply chain failures are third in the OWASP Top 10:2025 for web applications; see API security best practices and AI supply chain security.
Step 1: Inventory and SBOM
Generate a full dependency list from lockfiles and build tooling, including indirect dependencies, container base images and front-end bundles. Produce an SBOM in a standard format such as SPDX (SPDX). ASD's ACSC co-sealed the September 2025 joint guidance 'A shared vision of SBOM for cybersecurity', which describes an SBOM as a formal, machine-readable record of software components (ASD).
Step 2: Licence review
| Licence family | Typical consideration | Action |
|---|---|---|
| Permissive (MIT, BSD, Apache 2.0) | Attribution and notice requirements; Apache includes patent terms | Keep notices; record |
| Weak copyleft (LGPL, MPL) | Obligations on modified files or linking, depending on licence | Flag for review in distributed software |
| Strong copyleft (GPL, AGPL) | Obligations can extend to your code when distributing, or for AGPL when offering over a network | Legal review before use |
| No licence or unclear | No clear permission to use | Replace or obtain permission |
Worth noting
This is a general orientation, not legal advice. Licence obligations depend on how software is used and distributed; have a lawyer review flagged components.
Step 3: Vulnerabilities and maintenance status
- Scan dependencies against vulnerability databases such as OSV (OSV) in CI.
- Prioritise by exploitability and whether the vulnerable code path is reachable in your application.
- Check maintenance: recent releases, responsiveness to security issues, number of maintainers.
- Flag abandoned or single-maintainer packages in critical paths.
- Watch for suspicious ownership changes or typosquatted package names.
Step 4: Remediation plan
Group findings: urgent vulnerable components to upgrade or patch, licence issues for legal review, risky abandoned packages to replace, and outdated components to schedule. Upgrade in small steps with tests; see automated regression testing. Remove unused dependencies, which reduces risk for free. Add policies to CI: block known critical vulnerabilities and disallowed licences, and require review for new dependencies.
Keeping it continuous
- Automated dependency updates with tests, reviewed by people.
- Vulnerability scanning on every build and on a schedule for deployed versions.
- SBOM generated per release and stored.
- Periodic licence and maintenance review.
- A process for responding when a widely used component has a critical vulnerability.
Common mistakes
- Auditing direct dependencies only.
- Treating every vulnerability alert as equal.
- Assuming open source means no obligations.
- No SBOM, so finding affected systems takes days.
- Auditing once before a deal and never again.
Related guides
For related guides, see architecture review, secure web application development, penetration testing and AI-generated code security.
Conclusion
An open-source audit gives you a clear picture of what your software is made of and where the risks are. Inventory everything, review licences with legal input, scan continuously for vulnerabilities, watch maintenance health, and turn findings into a prioritised plan and CI policies. For continuous controls in your build pipeline, see software supply chain security.
Need a clear view of your dependencies?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure, maintainable web applications. We can help inventory, upgrade and maintain dependencies; licence questions should go to your lawyer.
Common questions.
An inventory of every open-source component your software uses, including indirect dependencies; the licences of those components; known vulnerabilities; the maintenance status of each project; and a plan to fix the risks found. It often produces a software bill of materials, which is a machine-readable list of components.