Dependency Audit and SBOM

The One Code's Govern and Optimize modules provide two overlapping but distinct tools for understanding software dependencies: the SBOM generator (Software Bill of Materials) for compliance and inventory purposes, and the Dependency Audit within the Optimize module for actionable technical debt remediation.

Software Bill of Materials (SBOM)

An SBOM is a complete, machine-readable inventory of every software component in a repository — direct dependencies and all their transitive dependencies — including version, license, and known vulnerabilities.

Why SBOMs Matter for MSPs

SBOMs are increasingly required by:

• Government contracts — Executive Order 14028 (US) requires SBOMs for software sold to federal agencies
• SOC 2 audits — Evidence of dependency tracking and vulnerability management
• ISO 27001 — Control A.12.6.1 (Technical vulnerability management) requires knowing what software is running
• Client security requirements — Enterprise clients often require SBOMs as part of vendor assessments

For MSPs, being able to generate an SBOM for any client application in minutes is a differentiator.

Generating an SBOM

1. Navigate to SBOM from the left sidebar, or to the repository detail page
2. Click Generate SBOM for the desired repository
3. The One Code fetches dependency manifests from GitHub (package.json, requirements.txt, pom.xml, go.mod, etc.) and generates the SBOM
4. Results appear within 30–60 seconds

SBOM Contents

The generated SBOM includes:

For each dependency:

• Package name and version
• Ecosystem (npm, pip, gem, go, maven, nuget, cargo)
• Whether it's a direct dependency or transitive
• License (if detectable)
• Known CVEs with severity, description, affected versions, and fix version
• Supply chain risk rating (low, medium, high)

Summary counts:

• Total dependencies (direct + transitive)
• Number with known vulnerabilities
• Count by severity (critical, high, medium, low)
• Number of license issues

Exporting the SBOM

Export in three formats:

Format	Use Case
CycloneDX JSON	Standard format for tooling integration, submission to customers or auditors
SPDX JSON	Alternative standard, preferred for open source and some government requirements
CSV	Human-readable spreadsheet for review and reporting

To export:

1. Open the SBOM for a repository
2. Click Export
3. Select the format
4. File downloads immediately

SBOM Dashboard

Navigate to SBOM to see an aggregate view:

• Vulnerable packages across all repos
• Critical CVEs requiring immediate attention
• License issues (copyleft, unknown, restricted, commercial risk)
• Per-repo breakdown sortable by vulnerability count or severity

Dependency Audit (Optimize Module)

The Dependency Audit in the Optimize module goes beyond the SBOM to give you actionable recommendations: which packages are outdated, how many versions behind they are, which are deprecated, and what license risks are present.

ℹ️The Dependency Audit is part of the Optimize subscription tier. The SBOM is available on the Govern tier and above.

What the Dependency Audit Analyzes

For each direct dependency, the audit collects:

Field	Description
Name	Package name
Current version	What's installed
Latest version	Most recent release
Ecosystem	npm, pip, nuget, maven, go, cargo, gem
Outdated	Whether the current version is behind latest
Deprecated	Whether the package is marked deprecated by its registry
Major versions behind	How many major versions out of date
License	Detected license identifier
Transitive count	How many packages this dependency pulls in

Plus, for each vulnerability found in dependencies:

Field	Description
Dependency + version	The package with the vulnerability
CVE ID	Standard CVE identifier
Severity	Critical, high, medium, low
Title	Vulnerability name/description
Fixed version	Earliest version that doesn't have the vulnerability
Direct	Whether this is a direct or transitive dependency

Triggering a Dependency Analysis

1. Navigate to the repository detail page
2. Click Analyze Dependencies (under the Optimize section)
3. The analysis reads dependency files from GitHub and cross-references against vulnerability databases
4. Results typically complete in 30–90 seconds

Dependency analysis also runs automatically when the background code-optimization-timer detects a dependency file has changed (triggered by push webhooks).

License Risk Detection

The dependency audit flags four categories of license issues:

Issue Type	Description	Risk Level
copyleft	GPL, LGPL, or AGPL licenses that may require open-sourcing derivative work	High for commercial software
unknown	No license detected — legal uncertainty	Medium
restricted	Licenses with explicit commercial restrictions	High
commercial_risk	Licenses that require commercial licensing for production use	High

For client software that will be distributed or offered as a service, copyleft and commercial_risk flags need legal review. Surface these findings in the QBR report.

Dependency Health in the Tech Debt Score

The dependency health category of the Technical Debt Score (see Optimization) incorporates:

• Percentage of dependencies that are outdated
• Presence of critical or high-severity vulnerabilities
• Count of deprecated packages
• License issues

A repository where 80% of dependencies are up-to-date with no critical CVEs will score much better on dependency health than one running year-old packages with known exploits.

Cross-Repo Vulnerability Summary

From the SBOM page, click Vulnerability Summary to see a cross-repository view:

• All critical CVEs across all repos in your tenant, sorted by severity
• Which repos are affected by each CVE
• Whether a fix version is available
• A "time to fix" estimate based on how quickly the package ecosystem typically releases patches

Use this view to prioritize remediation work — fix the CVEs that affect the most repos first, and always fix critical severity first.

Integrating with PSA

For every vulnerability or license issue surfaced in the SBOM or Dependency Audit, you can create a PSA ticket in one click:

1. Find the finding in the SBOM or dependency audit
2. Click Create Ticket
3. The PSA ticket is pre-populated with:
   • Finding type: vulnerability
   • Severity mapped to PSA priority
   • Title and description with the CVE ID, package name, and affected versions
   • Remediation steps: which version to update to
4. Select the client and assignee
5. Click Create

This creates a traceable work item in PSA, ensuring that vulnerability remediation is scheduled, assigned, and billed correctly.