Meterian Integration with DefectDojo

Meterian Integration with DefectDojo

Meterian is a software composition analysis (SCA) product from Meterian Ltd, a company based in London. Its scanner inspects a project's dependency manifests across ecosystems such as Java, .NET, JavaScript and Node.js, Python, Ruby, PHP, Go, Rust, and others, and scores the project on security, stability, and licensing. The Meterian client, commonly run as a Docker container, can write its results to a JSON report with the --report-json option, and that report is what DefectDojo imports.

Meterian Integration with DefectDojo

We send Meterian results into DefectDojo because a dependency report is only useful if someone follows it through to an upgrade. Meterian tells us which library versions carry known advisories and which version fixes them. DefectDojo turns each advisory into a Finding on the Asset that owns the code, keeps it from duplicating on the next scan, and puts an SLA clock on it. When a team bumps the library and the next report comes in clean, the Finding closes on reimport, and we have a record of when it happened.

Why Meterian Matters

Most of the code in a modern application comes from third-party packages, and most teams don't track the versions they pull in by hand.

• Meterian covers many language ecosystems in one client, which helps polyglot repositories that would otherwise need a different audit tool per language.
• Each advisory comes with a CVSS score, a CVE where one exists, a CWE, and links to the advisory and the fix commit.
• The report includes safe versions for each vulnerable dependency (latest patch, minor, or major), which tells an engineer how disruptive the fix will be.
• On its own, a JSON report has no history. It can't tell you whether an advisory appeared this week or has been ignored for six months.

Advantages of This Integration

What running Meterian through DefectDojo gives us:

• Deduplication per advisory. Meterian findings hash on CWE, component name, component version, description, and severity, so the same advisory against the same library version is recognized on every rescan.
• Upgrade guidance in the Finding. The parser writes the recommended safe version into the Mitigation field, so the person assigned the Finding knows the target version without opening the Meterian report.
• Lifecycle on reimport. Reimporting into the same Test mitigates advisories that disappeared after an upgrade, adds new ones, and reactivates any that return, for example after a dependency is pinned back.
• Consistent severity. When an advisory has a CVSS score, the parser applies standard CVSS bands, so Meterian findings line up with SLA rules for other SCA tools.
• Language tags for filtering. Each Finding is tagged with the language section it came from (for example nodejs), which makes it easy to route Java findings to one team and JavaScript findings to another.
• Shared triage. Findings can be assigned, risk-accepted with an expiration, marked false positive, or pushed to Jira like any other DefectDojo Finding.

How This Integration Works

DefectDojo imports Meterian results with the Meterian Scan scan type.

1. Produce a JSON report. From the project folder, run the Meterian client and write the report to a file:

meterian-docker --report-json=meterian-report.json

The parser reads the reports.security.reports section of the file. If that section is missing, the import fails with a "Malformed report" error, so check that your client run produced security results before wiring it into a pipeline.

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

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Meterian Scan" \
  -F "file=@meterian-report.json" \
  -F "product_name=orders-service" \
  -F "engagement_name=Dependency Scans" \
  -F "auto_create_context=true"

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

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Meterian Scan" \
  --report-path "./meterian-report.json" \
  --product-name "orders-service" \
  --engagement-name "Dependency Scans" \
  --auto-create-context

3. Reimport on each build. For a repository you scan on every merge, send later reports to /api/v2/reimport-scan/ against the same Test so upgrades close Findings automatically.

Data Granularity: What Gets Imported

The parser creates one Finding per advisory per dependency. A library with three advisories produces three Findings.

Only the security section is imported. Meterian's stability and licensing scores stay in Meterian.

Use Cases

In a CI/CD pipeline: A team runs the Meterian container on every merge to main and reimports into a Test named for the repository. The Test shows the current set of vulnerable dependencies, and a release check can query the DefectDojo API for active Critical Findings before deploying.

For polyglot repositories: A monorepo with a Java backend and a Node.js frontend produces one Meterian report with two language sections. The language tags let each team filter to its own Findings while security leads still see one Asset-level total.

During dependency upgrade sprints: Because the Mitigation field states whether the fix is a patch, minor, or major upgrade, teams can sort the backlog into quick patch bumps and the major upgrades that need planning, then risk-accept the latter with an expiration date.

For audit evidence: DefectDojo keeps the discovery date, SLA status, and closure date for each advisory, which answers the common audit question of how long known vulnerable components stayed in production.

Operational Tips

• Use one Test per repository and reimport into it. Separate imports work, but reimport gives you a clean open-to-mitigated history.
• Expect several Findings with the same name:version title when a library has multiple advisories. Look at the CVE and CWE columns to tell them apart, and don't treat matching titles as duplicates.
• Advisories without a CVSS score fall back to Meterian's own severity label. If those cluster at Info, review them before deciding they are noise.
• Since File Path is always "Manifest file", add the repository or service name with tags or test_title on import if you need to trace a Finding to its source.
• Set minimum_severity if Low advisories would bury the team at first, then lower the threshold once the backlog is under control.
• When Meterian reports no safe version, the Mitigation text recommends replacing the component. Those Findings usually need an owner decision, so assign them explicitly rather than letting them age.