Dependency Vulnerability Audit

Overview

Dependencies are the largest attack surface in most projects. This skill provides a structured audit process for Go and Maven/JVM projects, combining static manifest review with tool-driven vulnerability scanning.

Critical rule: Never judge a dependency as safe or unsafe based on your knowledge of its version number. Version numbers in your training data are stale. Always run the tools.

---

Audit Checklist

For every project

• Automated vulnerability scanner is run in CI (not just locally)
• Direct dependencies are intentional and documented
• No replace directives in go.mod pointing to local paths or forks
• Dependency manifest is committed (not generated at build time)

Go-specific

• go.sum is committed alongside go.mod
• govulncheck runs in CI and fails the build on known CVEs
• No replace directives substituting public modules with local or private alternatives
• go mod verify passes (confirms module content matches go.sum hashes)

Maven/JVM-specific

• Dependency versions are pinned (no version ranges: [1.0,2.0))
• OWASP Dependency-Check (or equivalent) runs in CI
• No dependencies with legacy or low-trust group IDs without provenance verification
• Transitive dependency tree has been reviewed (mvn dependency:tree)

---

Go: Running the Audit

Check for known CVEs

# Install once:
go install golang.org/x/vuln/cmd/govulncheck@latest

# Run from the module root:
govulncheck ./...

govulncheck cross-references the Go vulnerability database (https://vuln.go.dev/) against the specific functions your code actually calls — not just which modules are present. This means fewer false positives than tools that flag any version of a module with any CVE.

Verify module integrity

# Confirms every module in the build matches its go.sum hash.
# Fails if any module has been tampered with or if go.sum is stale.
go mod verify

Check for suspicious replace directives

# Print any replace directives in go.mod:
grep -A1 "^replace" go.mod

A replace directive substituting a public module with a local path (=> ../local-fork) or a private fork is a supply chain red flag — it bypasses the module proxy and checksum verification.

List all modules including transitive

go list -m all

Review the output for unfamiliar or unexpected module paths.

---

Maven/JVM: Running the Audit

Check for known CVEs (OWASP Dependency-Check)

# Run from the project root (downloads NVD data on first run — takes ~5 min):
mvn org.owasp:dependency-check-maven:check

# HTML report is generated at:
# target/dependency-check-report.html

Review the dependency tree

# Show all direct and transitive dependencies with versions:
mvn dependency:tree

Look for:

• Unexpectedly old versions of well-known libraries
• Multiple versions of the same library (version conflicts)
• Unfamiliar group IDs — especially legacy namespaces (com.googlecode.*, org.codehaus.*) where maintainer continuity may be uncertain

Check for version ranges (prohibited)

# Version ranges in pom.xml allow Maven to silently pull newer versions:
grep -E "\[|,|\)" pom.xml

Any match is a risk: Maven may resolve a different version than was tested.

---

CI Integration

Go: Add govulncheck to CI

- name: Run vulnerability scan
  working-directory: go-tui
  run: |
    go install golang.org/x/vuln/cmd/govulncheck@latest
    govulncheck ./...

Maven: Add OWASP Dependency-Check to CI

Add the plugin to pom.xml under <build><plugins>:

<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>9.0.9</version>
  <executions>
    <execution>
      <goals><goal>check</goal></goals>
    </execution>
  </executions>
  <configuration>
    <!-- Fail build if any dependency has a CVSS score >= 7 (high) -->
    <failBuildOnCVSS>7</failBuildOnCVSS>
  </configuration>
</plugin>

Then in the CI workflow:

- name: Run OWASP dependency scan
  working-directory: tui
  run: mvn -B org.owasp:dependency-check-maven:check

Dependabot for package updates

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: gomod
    directory: /go-tui
    schedule:
      interval: weekly

  - package-ecosystem: maven
    directory: /tui
    schedule:
      interval: weekly

---

Report Format

After completing the audit, produce a findings table:

## Dependency Audit

| Ecosystem | Finding | Severity | Fix |
| --- | --- | --- | --- |
| Go | `govulncheck` not in CI | Medium | Add govulncheck step to go-tui-tests.yml |
| Maven | OWASP Dependency-Check not in CI | Medium | Add plugin + CI step |
| Maven | `lanterna:3.1.1` — legacy com.googlecode group ID | Low | Verify provenance once; monitor for updates |
| All | No dependabot.yml for packages | Medium | Add gomod + maven ecosystems to dependabot.yml |

Severity guide:

• Critical — actively exploited CVE in a direct dependency
• High — CVE with CVSS ≥ 7 in direct or transitive dependency
• Medium — no scanner in CI; unverified provenance; stale unpinned dependency
• Low — legacy group ID with no known CVE; minor hygiene

---

What the Tools Cannot Catch

• Malicious code with no published CVE — a new supply chain attack has no CVE until discovered. Tools only know about known vulnerabilities.
• Your knowledge of version numbers — do not assert that a version "doesn't exist" or "seems wrong" based on training data. Module proxy and go.sum are the ground truth; tool output is the authority.
• Semantic correctness of a dependency — tools verify identity and known CVEs, not whether a library does what its README claims.

For highest assurance, generate an SBOM and sign it:

# Using Syft (install from https://github.com/anchore/syft):
syft dir:. -o cyclonedx-json > sbom.json