Action1 Integration with DefectDojo

Action1 Integration with DefectDojo

Action1 is a cloud-based patch management and vulnerability remediation platform. An agent on each managed endpoint reports installed software, which Action1 matches against known CVEs, and Action1 then lists the updates available to fix them. DefectDojo accepts Action1 data as a JSON vulnerability export or through the DefectDojo Pro Action1 connector, which reads the same data over the Action1 API.

Action1 Integration with DefectDojo

We already used Action1 to push patches, so it knew exactly which machines were missing which updates. What it didn't give us was a vulnerability program: SLAs, ownership, and a history we could show an auditor. Bringing Action1 into DefectDojo turns every CVE on every endpoint into its own Finding, with the patch Action1 has ready listed as the mitigation. Because the file parser and the Pro connector produce identical findings, we could start with exports and move to the connector without duplicating anything.

Why Action1 Matters

Endpoint CVEs are where patch management and vulnerability management overlap, and they tend to fall between the IT team and the security team.

• Action1 reads installed software from an agent, so it reports what is actually on each machine rather than what a network scan can infer.
• It ties each vulnerability to available updates, which turns a CVE list into a patch list.
• The installed version differs from one machine to the next. Tracking per machine is the only way to know whether a CVE is really gone from the fleet.
• Security teams need endpoint exposure next to application and cloud findings when they report risk, and Action1 alone doesn't provide that view.

Advantages of This Integration

• Per-machine findings. The identity is action1-<CVE>-<endpoint id>, so one CVE on three machines becomes three findings that can be closed independently as each machine is patched.
• Version-aware deduplication. component_version is part of the hash for this scan type, so a patched machine doesn't merge with one that is still vulnerable.
• Patch-ready mitigation. Mitigation lists the updates Action1 already has for the affected software. When Action1 knows of no patch, the field stays empty instead of being filled with generic advice.
• File and API in agreement. The parser mirrors the connector field for field under the scan type Action1 Scan, so file imports and connector Syncs deduplicate against each other.
• Standard workflow. Endpoint CVEs get SLAs by severity, assignment, risk acceptance, Jira pushes, and the same metrics as everything else in DefectDojo.

How This Integration Works

Option 1: File import. Use this path when you can't grant Action1 API credentials. The export is the Action1 vulnerability-list response, with rows under items (a bare array also works). Action1 lists the vulnerability catalogue and the affected machines through two different calls, and the affected endpoint is what makes a finding: a catalogue entry with no affected endpoint produces nothing. Include the affected endpoints either as a top-level endpoints object keyed by CVE ID or as an endpoints array nested on each vulnerability. You can also add the managed-endpoint list as managed_endpoints to supply each machine's operating system.

Import it in the UI with the Action1 Scan scan type, or through 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=Action1 Scan" 
  -F "file=@action1-export.json" 
  -F "product_name=endpoint-fleet" 
  -F "engagement_name=Action1" 
  -F "auto_create_context=true"

With DefectDojo Pro, Universal Importer does the same from a scheduled job:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Action1 Scan" 
  --report-path "./action1-export.json" 
  --product-name "endpoint-fleet" 
  --engagement-name "Action1" 
  --auto-create-context

Option 2: Action1 connector (DefectDojo Pro). In the DefectDojo Pro UI, add the Action1 connector, enter https://app.action1.com/api/3.0 as the Location, and supply an Action1 API key (used as the OAuth client ID) and API secret. Set a Minimum Severity if you want to limit what comes in. The connector creates a Record for each endpoint and one finding per endpoint-and-vulnerability pair, so a CVE present on fifty hosts produces fifty findings, each on its own host's Record. Finding counts therefore scale with fleet size, not with the number of distinct CVEs.

Data Granularity: What Gets Imported

Affected-endpoint rows with no endpoint ID are skipped, since the ID is half of the finding's identity.

Use Cases

Patch SLA tracking: IT pushes patches through Action1 while security measures how long Critical endpoint CVEs stay open. Each reimport closes the per-machine findings that disappeared, so time to remediate is measured per host instead of estimated.

Restricted environments: A team that can't connect an outside platform to the Action1 API exports the vulnerability list with affected endpoints on a schedule and imports the file. Moving to the connector later keeps the same findings.

Exception handling: A legacy machine can't take a vendor update. Its single finding is risk-accepted with an expiration date, while the same CVE on the rest of the fleet stays under SLA.

Fleet reporting: Endpoint exposure sits next to application, cloud, and container findings in DefectDojo, so a security lead can report total open Criticals by business unit from one place.

Operational Tips

• Always include the affected endpoints in a file export. A vulnerability list without them imports zero findings.
• Add managed_endpoints if you want each finding to name the machine's operating system. It is optional and best-effort.
• Action1 machine names are free text. Names with spaces (such as Reception Desk PC) can't be stored as a DefectDojo endpoint, so the parser keeps them in the description only.
• Expect large finding counts on big fleets. Use minimum_severity or the connector's Minimum Severity to start with Critical and High.
• Reimport into the same Test so patched machines are mitigated automatically on the next run.
• Findings with no mitigation text mean Action1 has no update available. Those are good candidates for risk acceptance or compensating controls.