Finite State Integration with DefectDojo

Finite State Integration with DefectDojo

Finite State is a commercial product security platform for connected devices and embedded systems. It analyzes firmware images and software binaries, builds a software bill of materials for each build, and reports the vulnerabilities and weaknesses it finds, with CVSS, EPSS, exploit intelligence, and VEX status attached. Its data is available through a GraphQL API, and a saved findings response can be exported as JSON.

Finite State Integration with DefectDojo

Our device teams run their firmware through Finite State, and our security program runs through DefectDojo, so we connected the two. Finite State is good at telling us what is inside a firmware build and what is wrong with it. DefectDojo is where those findings get owners, SLAs, and tickets alongside everything else we track. The part that made the integration worth doing is VEX: when a product team has already stated that a CVE does not affect a build, that assertion comes across with the finding, so nobody re-triages a question that was answered weeks ago.

Why Finite State Matters

Firmware is hard to assess with tools built for source code. Vendors ship binaries, components are statically linked, and the same open source library can appear in a dozen builds of one product line.

• Binary analysis finds components and vulnerabilities even when source code and manifests are unavailable.
• Each finding is tied to a specific asset and firmware build, which is the level product security teams release and patch at.
• Exploit signals on each CVE (weaponized exploits, reports of exploitation in the wild) and EPSS scores help separate urgent fixes from background noise.
• VEX assertions record whether a vulnerability is actually reachable in the product, which matters most for embedded systems where much of a library may be compiled out.

Advantages of This Integration

What changed once Finite State findings started landing in DefectDojo:

• VEX status becomes Finding status. NOT_AFFECTED findings import as inactive and out of scope, and are also marked false positive when the justification says the vulnerable code is not present or not reachable. FIXED imports as mitigated, and UNDER_INVESTIGATION stays active and under review.
• Build context on every Finding. Each Finding is tagged firmware-build:<name>, and the description names the asset and build, so a reader can tell which firmware is affected without opening Finite State.
• Exploit intelligence as tags. Findings carry weaponized and exploited-in-the-wild tags from any of their CVEs, plus category, source type, and tool tags, which makes filtering and reporting straightforward.
• File and API imports agree. The parser uses the same scan type as the DefectDojo Pro connector, Finite State - Connectors Import, and mirrors its field mapping, so an export uploaded today and a connector sync enabled later deduplicate against each other.
• Platform workflow. Findings get SLAs by severity, assignment, Jira tickets, and risk acceptance like any other source.

How This Integration Works

There are two ways in, depending on whether DefectDojo can reach the Finite State API.

Option 1: API Connector (DefectDojo Pro). Configure the Finite State connector in the DefectDojo Pro UI. Enter your Finite State subdomain (for example https://acme.finitestate.io) in the Location field and an API token in the API Token field; DefectDojo appends the API path and sends the token in the header Finite State expects. Optionally set Import Every Firmware Build to true to pull findings from every build of each asset (by default only the newest build is imported), and set a Minimum Severity. The connector creates a Record for each Finite State asset, which is a product line rather than a single build, so one Record accumulates the history of a firmware line. Merged duplicates and deleted findings in Finite State are excluded automatically.

Option 2: File import. For air-gapped networks or environments where API credentials can't be granted, save a Finite State findings response as JSON. The parser accepts the GraphQL response shape (data.allFindings), an unwrapped allFindings or findings list, or a bare array. Top-level asset and assetVersion objects supply the asset and build context for the whole file; one export should cover one firmware build. Then import it through the UI (Import Scan Results, scan type Finite State - Connectors Import), the API, or Universal Importer:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Finite State - Connectors Import" 
  -F "file=@finitestate-export.json" 
  -F "product_name=generic-router" 
  -F "engagement_name=Firmware 1.4.0" 
  -F "auto_create_context=true"

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Finite State - Connectors Import" 
  --report-path "./finitestate-export.json" 
  --product-name "generic-router" 
  --engagement-name "Firmware 1.4.0" 
  --auto-create-context

Data Granularity: What Gets Imported

A finding with no VEX status block, or with AFFECTED or an unrecognized status, imports as active. That is the safe direction to be wrong in.

Use Cases

Release readiness for a device line: A product security team checks the newest firmware build before it ships. Findings land in DefectDojo with the build tag, VEX-cleared items are already out of scope, and the remaining active Critical and High findings become the release checklist.

Air-gapped manufacturing networks: A team that cannot let DefectDojo call out to Finite State exports the findings response for each build and imports the file. Because the scan type matches the connector, switching to the connector later doesn't create a second copy of every finding.

Tracking a firmware line over time: With Import Every Firmware Build enabled on the connector, findings from several builds accumulate under one Record per product line. Build tags make it possible to report which issues were fixed in which release.

Prioritizing patch work: Engineers filter on the exploited-in-the-wild and weaponized tags and sort by EPSS to decide which component upgrades go into the next maintenance build.

Operational Tips

• Keep one firmware build per export file. The asset and build context is read once for the file, so mixing builds in one export blurs the build tag unless each row carries its own context.
• Leave Import Every Firmware Build off unless you need build-by-build history. Importing only the newest build is what most teams want and keeps the queue focused.
• Record VEX decisions in Finite State, not only in DefectDojo. The VEX status is what the parser and connector translate into out-of-scope and false positive flags on each sync.
• Be aware that a finding Finite State grades unknown imports as Info even if its CVSS severity is higher. Review Info findings with high CVSS scores periodically.
• Use the Minimum Severity setting on the connector, or minimum_severity on file imports, if Low and Info findings would bury device teams.
• Build dashboards on the build and exploit tags. They are the quickest way to answer "is this CVE in what we ship today?"