Bright Security Integration with DefectDojo

Bright Security Integration with DefectDojo

Bright Security (formerly NeuraLegion) makes a dynamic application security testing (DAST) platform that attacks running web applications and APIs to find exploitable weaknesses. Each Bright scan produces issues tied to the entry point that was tested, with a severity rating, CWE, CVSS score, remediation guidance, and the HTTP request and response that demonstrated the problem. DefectDojo can take those issues as a JSON export or, in DefectDojo Pro, pull them directly from the Bright API.

Bright Security Integration with DefectDojo

We run Bright Security against our staging environments because it shows us what an attacker can actually reach, and DefectDojo is where its issues get owners and deadlines. Each Bright issue arrives as a dynamic Finding with the attacked endpoint, the CWE, and the captured request and response, so the developer assigned to it can reproduce the problem without logging into the scanner. Scans repeat on every release, and DefectDojo matches each issue to the one we already have instead of reopening the same ticket.

Why Bright Security Matters

Static tools tell you what code could be dangerous. A DAST scanner tells you what a deployed application does when someone sends it hostile input.

• Bright tests running applications and APIs, which catches configuration and runtime problems that never appear in source code.
• Every issue includes the exchange that proved it, so triage starts from evidence rather than a rule description.
• Issues are mapped to CWE and scored with CVSS, which lets you compare them with findings from other tools.
• A single weakness reachable from several URLs is reported once with all affected resources, which reflects how the fix is usually made.

Advantages of This Integration

• Two ways in, one set of Findings. The file parser uses the same scan type as the DefectDojo Pro Bright connector, Bright - Connectors Import, so a file import and an API sync deduplicate against each other instead of producing two copies.
• Deduplication on Bright's own ID first. This scan type uses the unique-ID-or-hash-code algorithm: Bright's issue ID is matched first, with a hash of title, severity, and endpoints as the fallback.
• Endpoints that mean something. The attacked entry point becomes the Finding's endpoint, so you can filter and report DAST results by host and path.
• Reproduction evidence kept intact. Request and response are stored in fenced code blocks in the description, verbatim, so nothing captured from the target is rendered as markup.
• Platform workflow. Bright issues pick up SLA timers by severity, can be assigned, risk-accepted, marked false positive, or pushed to Jira, and appear in the same Asset metrics as your SAST and SCA results.

How This Integration Works

This page covers two import paths: a file import for organizations that can't hand DefectDojo Bright API credentials (air-gapped networks, procurement restrictions, a pending security review), and the DefectDojo Pro API connector for everyone else.

Option 1: Import a JSON export. Save the issues for one Bright scan from Bright's issues API as JSON. The parser accepts the bare array that endpoint returns, or an object carrying it under issues, items, or a scan or data object with nested issues. Then import with the Bright - Connectors Import scan type. In the UI, choose Import Scan Results on the Engagement and select that scan type. With 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=Bright - Connectors Import" 
  -F "file=@bright-issues.json" 
  -F "product_name=customer-portal" 
  -F "engagement_name=Staging DAST" 
  -F "auto_create_context=true"

Or, in DefectDojo Pro, with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Bright - Connectors Import" 
  --report-path "./bright-issues.json" 
  --product-name "customer-portal" 
  --engagement-name "Staging DAST" 
  --auto-create-context

Option 2: Use the API Connector (Pro). Create a Bright API key in the Bright app under User settings, API keys (an organization or personal key). In DefectDojo Pro, add the Bright Security connector, keep the pre-filled Location https://app.brightsec.com or enter your own Bright host, paste the key into the Secret field, and optionally set a Minimum Severity. DefectDojo discovers every scan the key can access, creates a Record for each completed scan, and imports that scan's issues as Findings on each sync. You then map Records to Assets in the connector UI.

Data Granularity: What Gets Imported

Use Cases

In a release pipeline: Bright scans staging after each deploy and the connector syncs the completed scan. New issues appear on the Asset with SLA timers running, and issues Bright no longer reports can be closed through the normal reimport lifecycle when you import files into the same Test.

In restricted environments: A team in an isolated network can't give DefectDojo a Bright API key. They export a scan's issues as JSON, carry the file across, and import it. If they later enable the connector, the shared scan type means the API sync matches the Findings already imported from files.

For API security programs: Bright's API tests produce issues per entry point. Because the entry point becomes the endpoint, a security lead can report open DAST issues per API host and see which teams own them.

For developer handoff: A Finding pushed to Jira carries the description with the captured request and response, so the developer has what they need to reproduce the issue on the first read.

Operational Tips

• Pick one Asset per application under test and map the Bright Records to it, so issues from repeated scans accumulate history in one place.
• If you import files, keep exporting one scan per file. The parser treats the file as one scan's issues.
• Watch for entry points with unusual hostnames. The parser skips endpoints DefectDojo would reject so the import doesn't fail, which means some Findings may have no endpoint even though the entry point appears in the description.
• Use the connector's Minimum Severity, or minimum_severity on file imports, if Info-level issues add noise. Unrecognized Bright severities also import as Info.
• Treat Bright's remediation text as a starting point and add notes with the project-specific fix, which carries over when the Finding is pushed to Jira.
• When an issue ID doesn't match an existing Finding, dedupe falls back to a hash that includes endpoints, so a changed staging hostname can make known issues look new. Keep test targets stable where you can.