AuditJS Integration with DefectDojo

AuditJS Integration with DefectDojo

AuditJS is an open source command-line tool from the Sonatype Nexus Community project, released under the Apache 2.0 license. It reads the installed node_modules tree of a JavaScript project, covering direct and transitive dependencies for npm, yarn, and similar package managers, and checks each package against Sonatype's vulnerability data. Results include the vulnerability ID, title, description, CVSS score and vector, CVE, and a reference link per package, and can be written as JSON for import into DefectDojo.

AuditJS Integration with DefectDojo

We added AuditJS to our Node.js builds because it is free, quick, and checks the dependency tree that actually got installed rather than only what package.json declares. The output is a JSON list per build, which is fine for failing a pipeline and not much use for knowing what has been open since last quarter. Importing AuditJS results into DefectDojo turns each vulnerable dependency into a Finding on the service's Asset, with a CVE, a CVSS-based severity, and an owner, so dependency upgrades get tracked like any other remediation work.

Why AuditJS Matters

A typical JavaScript application pulls in hundreds of transitive packages, and a vulnerability in any of them ships with the application.

• AuditJS audits the installed tree, so it sees transitive dependencies that a manifest-only check can miss.
• Every result names the package coordinates and version, which tells an engineer exactly what to upgrade.
• CVSS vectors from Sonatype's data give a consistent severity across projects.
• It runs locally and in CI with no server to maintain.
• Its output describes a single build. Without a platform, the same vulnerable package reappears in every report with no record of who owns it or how long it has been there.

Advantages of This Integration

What we gained by sending AuditJS results through DefectDojo:

• Deduplication on the vulnerability ID. DefectDojo deduplicates AuditJS Scan findings on the unique ID from the tool, which is the vulnerability id in the report (typically the CVE ID), so the same issue is recognized across builds.
• CVSS-driven severity. When a CVSS vector is present, DefectDojo computes severity from it and stores the CVSS v3 or v4 vector on the Finding. When only a score is present, standard CVSS bands are used.
• Lifecycle across releases. Reimporting each build's report into the same Test mitigates vulnerabilities removed by an upgrade and reactivates any that return.
• CVE-level reporting. CVE IDs are stored as vulnerability IDs, so a security lead can find every Asset affected by a specific CVE.
• Shared workflow. Findings can be assigned, risk-accepted, or pushed to Jira, under the same SLAs as SAST and DAST findings on the Asset.

How This Integration Works

DefectDojo imports AuditJS output with the AuditJS Scan scan type.

1. Install dependencies and run AuditJS with JSON output. AuditJS reads node_modules, so run it after npm install or npm ci. The DefectDojo documentation uses:

auditjs ossi --json > auditjs_report.json

AuditJS 5 marks the ossi command as deprecated in favor of guide, which uses Sonatype Guide and needs a free API token. If you switch commands, confirm the JSON is still an array of packages, each with coordinates and a vulnerabilities list, before wiring it into a pipeline. A report that is not valid JSON fails with a message asking whether --json was used.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select AuditJS Scan, and upload the file. For automation, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=AuditJS Scan" \
  -F "file=@auditjs_report.json" \
  -F "product_name=web-frontend" \
  -F "engagement_name=CI" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "AuditJS Scan" \
  --report-path "./auditjs_report.json" \
  --product-name "web-frontend" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on every build. Send later reports to /api/v2/reimport-scan/ against the same Test so upgrades close findings automatically.

Data Granularity: What Gets Imported

Within one report, entries that share a vulnerability ID are merged into a single Finding, with their descriptions combined. If one CVE affects two different packages in the same project, both appear in that Finding's description, and its component fields come from the first package.

Use Cases

In a Node.js CI pipeline: Each build runs AuditJS after installing dependencies and reimports the report into the service's Test. Pull requests surface only newly introduced vulnerabilities, and a merge check can query DefectDojo for new High or Critical findings.

Across many front-end repositories: An organization with 30 JavaScript applications imports each into its own Asset. When a widely used package gets a new CVE, a search by vulnerability ID shows every affected application.

During dependency upgrade sprints: A team bumps major versions of its frameworks, rebuilds, and reimports. The Test shows which findings the upgrade closed and which remain because a transitive package was pinned.

For audit evidence: SOC 2 and PCI-DSS reviews ask how third-party component risk is handled. DefectDojo shows discovery date, SLA status, and the closing build for each dependency finding.

Operational Tips

• Run AuditJS after dependencies are installed in the same environment you ship. It reads node_modules, so a partial install gives partial results.
• Expect findings to be keyed on the vulnerability ID. Keep one Test per project so a CVE in one service never matches a finding from another.
• CWE is only extracted when an OSS Index title begins with CWE-. Titles that start with a bracketed CVE ID carry the CWE name in the title text but leave the CWE field empty, so filter on title or vulnerability ID instead.
• Decide whether development dependencies belong in the report and keep that choice consistent across builds, so reimports don't close and reopen findings when the scope changes.
• Tag imports with branch or release (for example tags=main,2026.10) so findings can be traced to a build.
• Risk-accept vulnerabilities in packages with no fixed version, with an expiration date, so they come back for review when a fix is likely.