NetRise Integration with DefectDojo

NetRise Integration with DefectDojo

NetRise is a software supply chain security company, now part of Dragos, whose platform analyzes firmware and the software deployed on devices. It inventories the components inside firmware artifacts and reports the vulnerabilities affecting those components, including whether a vulnerability is reachable and whether it is listed in CISA's Known Exploited Vulnerabilities catalog. NetRise exposes its data through a GraphQL API, and DefectDojo can take it either from a JSON export of that data or directly through a DefectDojo Pro connector.

NetRise Integration with DefectDojo

We use NetRise for the devices our own code scanners cannot see into: routers, controllers, and appliances that ship as firmware images. Bringing NetRise findings into DefectDojo puts firmware CVEs on the same Assets and under the same SLAs as our application findings. Each Finding is scoped to the firmware build it came from, so when one build is patched and another is still shipping, DefectDojo keeps them apart instead of quietly merging them.

Why NetRise Matters

Firmware bundles an operating system, libraries, and vendor code into one opaque file. Vulnerable components inside it are hard to inventory and slow to fix, because the fix usually means a new build from the vendor.

• It identifies the components inside firmware artifacts, which is the starting point for knowing what a device actually runs.
• It reports vulnerabilities per component with CVSS scores and the versions that fix them.
• Its reachability and CISA KEV signals help separate the CVEs worth escalating from the long tail.
• Firmware findings are often managed apart from everything else. Without a shared platform, device risk rarely appears in the same reports as application risk.

Advantages of This Integration

What DefectDojo adds to NetRise data:

• Two ways in, one identity. The file parser and the DefectDojo Pro connector use the same scan type name and the same field mapping, so a file import and an API sync of the same data deduplicate against each other.
• Build-scoped findings. The unique ID is built from the NetRise artifact ID plus the CVE (or component), so the same CVE in two firmware builds stays two Findings. Each build that still ships the flaw stays visible.
• Signals kept, severity unchanged. Reachability and KEV listing are recorded as the severity justification, as tags (reachable, cisa-kev), and in the description. They do not change the severity, which keeps file and API data consistent.
• Severity with a fallback. NetRise's severity word maps directly. An unrecognized word falls back to the CVSS score rather than to Info, so a Finding still lands where its score puts it.
• Filtering by device. The artifact's vendor and product are added as tags, so you can filter Findings by device family.
• Lifecycle and SLAs. Reimports or connector syncs update Findings over time, and SLAs, assignment, risk acceptance, and Jira integration apply as they do for any other Finding.

How This Integration Works

DefectDojo handles NetRise data with the NetRise Scan scan type, whether it arrives by file or through the connector.

Option A: API Connector (Pro). In DefectDojo Pro, set up the NetRise connector with your NetRise API URL in the Location field, a NetRise API client ID and client secret, and the organization ID those credentials belong to. You can optionally set a minimum severity to limit what is imported. The connector enumerates every firmware artifact in your NetRise tenant and creates a Record for each product line (the vendor and Asset pair), and each Record accumulates the CVEs found in that product line's firmware artifacts. Like other DefectDojo Pro connectors, it syncs on a schedule.

Option B: File import. The parser exists for teams that cannot grant NetRise API credentials, for example on air-gapped networks or while a security review is pending. Export NetRise's response for one firmware artifact and its vulnerabilities as JSON. The parser accepts NetRise's GraphQL Relay shape (rows wrapped in edges and node), a data envelope, an artifact delivered in its own assetsRelay envelope, or a list that has already been flattened.

Import the file in the UI by opening the Engagement, choosing Import Scan Results, and selecting NetRise Scan, or use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=NetRise Scan" 
  -F "file=@netrise-export.json" 
  -F "product_name=gn-1000-router" 
  -F "engagement_name=Firmware Review" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "NetRise Scan" 
  --report-path "./netrise-export.json" 
  --product-name "gn-1000-router" 
  --engagement-name "Firmware Review" 
  --auto-create-context

Send later exports for the same artifact to /api/v2/reimport-scan/ against the same Test to keep its history in one place.

Data Granularity: What Gets Imported

Score bands for the fallback are 9 and above Critical, 7 High, 4 Medium, and above 0 Low.

Use Cases

For device fleets: An operations team managing several router and controller models runs the NetRise connector in DefectDojo Pro. Each product line becomes a Record, and SLA reports show firmware CVEs by device family alongside application findings.

In air-gapped environments: A plant that cannot allow outbound API access exports NetRise data on a separate system and imports the JSON by file. If the organization later enables the connector, the API data deduplicates against what was already imported.

For vendor management: Security filters Findings by vendor tag and the cisa-kev tag to build a list of known exploited flaws in shipped firmware, then uses the fixed versions in the mitigation field when asking the vendor for an update.

Across firmware releases: Because identity is scoped to the artifact, a team comparing two builds can see which CVEs the newer build fixed and which ones the older build still carries in the field.

Operational Tips

• Choose one path per artifact where you can. File and connector data deduplicate against each other, but a single path keeps the history easier to read.
• Filter on the reachable and cisa-kev tags to prioritize. These signals do not raise severity by design, so a severity filter alone will not surface them.
• Expect the same CVE to appear once per firmware build. That is intentional, since each build is a separate thing to re-release.
• Use the connector's minimum severity setting, or minimum_severity on file import, if low-severity component findings overwhelm the first review.
• An export without an artifact still imports, but with an empty artifact in the unique ID. Include the artifact so builds stay distinguishable.
• Findings without a CVE fall back to the component name in the title and unique ID. Review those manually, since they cannot be matched by CVE across tools.