FOSSA Integration with DefectDojo

FOSSA Integration with DefectDojo

FOSSA is a commercial software composition analysis platform focused on open source license compliance and dependency security. Teams run the open source fossa-cli in their builds to analyze dependencies, and the FOSSA service reports two kinds of issues per project: security vulnerabilities in dependencies, and licensing or quality issues such as policy conflicts, unlicensed or denylisted dependencies, and outdated packages. Issue data is available through FOSSA's v2 API as JSON.

FOSSA Integration with DefectDojo

We use FOSSA because our legal and engineering teams both need answers about the same dependencies, and DefectDojo is where we manage remediation across every security tool. Connecting them puts FOSSA's CVEs next to our SAST, container, and DAST findings for each Asset, with the same SLAs and ticketing. It also brings licensing issues into the same workflow, so a copyleft policy conflict in a shipping service gets an owner and a due date instead of sitting in a separate dashboard.

Why FOSSA Matters

Most application code is open source dependencies, and each dependency carries two kinds of risk: known vulnerabilities and the license terms it ships under.

• FOSSA covers both in one analysis, which matters for teams that distribute software and need license obligations tracked as carefully as CVEs.
• Vulnerability issues include CVE, CVSS score and vector, CWE, affected and patched version ranges, and upgrade advice.
• Licensing issues are evaluated against your organization's policies, so the output reflects what your legal team has actually approved or denied.
• Dependency depth (direct versus transitive) is reported, which tells an engineer whether a fix is a one-line version bump or a conversation with an upstream maintainer.

Advantages of This Integration

What changes when FOSSA issues flow through DefectDojo:

• Vulnerabilities and license issues in one queue. Both categories import, tagged category:vulnerability or category:licensing, so you can route them to different owners while tracking them in one place.
• Upgrade advice as mitigation. FOSSA's complete fix and partial fix versions, with the semver distance of each bump, become the Finding's mitigation text.
• Correct per-project findings. One FOSSA issue can affect several projects. DefectDojo creates one Finding per project, suffixing the tool ID with the project locator, so the same dependency issue in two Assets never collapses into one.
• Deduplication between file and API. The parser and the DefectDojo Pro connector share the scan type FOSSA - Connectors Import and its deduplication settings (unique ID from tool, falling back to a hash of title, severity, and component name), so an uploaded export and a later connector sync don't create two copies.
• Platform workflow. SLAs, assignment, risk acceptance for license exceptions, Jira tickets, and metrics apply to FOSSA findings like any other source.

How This Integration Works

Option 1: API Connector (DefectDojo Pro). In the DefectDojo Pro UI, configure the FOSSA connector with https://app.fossa.com/api in the Location field and a FOSSA Full API token in the Secret field. A Push-Only token cannot read the APIs the connector uses, and the sync will retrieve nothing; this is the most common misconfiguration. Optionally set a Minimum Severity. Each FOSSA project becomes a Record in DefectDojo, and only your organization's active issues are imported, covering both vulnerability and license-policy findings.

Option 2: File import. For environments that can't grant FOSSA API credentials to DefectDojo, save the response from FOSSA's v2 issues endpoint (requesting all categories) as JSON. The parser accepts the API's issues envelope or a bare array of issues. Then import it through the UI (Import Scan Results, scan type FOSSA - Connectors Import), the API, or Universal Importer:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=FOSSA - Connectors Import" 
  -F "file=@fossa.json" 
  -F "product_name=billing-service" 
  -F "engagement_name=Dependencies" 
  -F "auto_create_context=true"

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "FOSSA - Connectors Import" 
  --report-path "./fossa.json" 
  --product-name "billing-service" 
  --engagement-name "Dependencies" 
  --auto-create-context

If the export has no project context on its issues, the tool ID is the issue ID alone, so per-project separation depends on importing each project's issues into the right Asset.

Data Granularity: What Gets Imported

FOSSA issues hang off dependencies, not files, so there is no file path or line. The dependency coordinates in the description are the location.

Use Cases

Release compliance: Before a product ships to customers, the release manager filters the Asset's FOSSA findings on category:licensing. Every High policy conflict needs either a dependency change or a documented, time-boxed risk acceptance approved by legal.

Dependency CVE remediation: Engineers sort FOSSA vulnerability findings by severity and depth. Direct dependencies with a complete fix available go into the next sprint, and the mitigation text tells them exactly which version to move to.

Shared libraries across many projects: A vulnerable internal-standard library affects 25 FOSSA projects. Each mapped Asset gets its own Finding, so each team's progress is tracked separately instead of one shared ticket staying open until the last team finishes.

Restricted networks: A team that cannot let DefectDojo call FOSSA exports the issues response and imports it as a file, keeping the same scan type the connector would use.

Operational Tips

• Use a Full API token for the connector. A Push-Only token is the usual reason a FOSSA sync returns nothing.
• Route by tag. Send category:licensing findings to whoever owns license policy and category:vulnerability findings to the owning engineering team.
• Set SLAs knowing how licensing severities are assigned. FOSSA publishes no severity for licensing issues, so the High, Medium, and Low grades come from a fixed mapping by issue type.
• Expect some vulnerabilities graded from CVSS. FOSSA reports unknown severity often enough that the CVSS band fallback matters for SLA timing.
• Use risk acceptance with an expiration for approved license exceptions rather than marking them false positive. The issue is real; the decision is what changed.
• Use minimum_severity or the connector's Minimum Severity to keep Low quality signals out of the queue if your team doesn't act on them.