All integrations

debsecan Integration with DefectDojo

debsecan Integration with DefectDojo

debsecan, the Debian Security Analyzer, is an open source command-line tool packaged in Debian. It reads the list of packages installed on a Debian system and compares it with data from the Debian security tracker, listing the CVEs (and tracker-only TEMP- issues) that apply to those packages on that system's suite, along with whether and where a fix is available. It produces plain text in several formats; DefectDojo imports the detail and simple formats.

debsecan Integration with DefectDojo

We run debsecan on our Debian hosts because it answers the question that matters for patching, whether a CVE applies to the package version actually installed on this release, using Debian's own tracker. We import its output into DefectDojo so those answers become tracked work. Each CVE and package pair becomes a Finding on the host's Asset, with the installed version, the source package it was built from, and the fix status, and the Finding is mitigated automatically once a rescan stops reporting it.

Why debsecan Matters

Generic scanners often match Debian packages against upstream version ranges, which can disagree with Debian's backported fixes. debsecan uses the distribution's own data.

  • It reflects Debian's security tracker, including backports and per-suite fix status.
  • It reports the binary package installed and the source package it was built from, which is what you upgrade.
  • It shows where a fix has landed, so you can tell "patch now" from "no fix yet".
  • It runs locally on the host with no agent or service to deploy.
  • It has no machine-readable output and no history. On its own it cannot show which CVEs are new since last week or which hosts still carry an old one.

Advantages of This Integration

What running debsecan through DefectDojo adds:

  • One Finding per CVE and package. A CVE that affects three installed packages is three upgrades, so it becomes three Findings.
  • Stable deduplication. Findings are hashed on vulnerability IDs and component name, so the same CVE in the same package is recognized across rescans of a host.
  • Fix availability on the Finding. Where debsecan reports a fixed version, it becomes the Mitigation. Where it reports none, the description says so explicitly.
  • Clean CVE data. Real CVE IDs are recorded as vulnerability IDs. Debian TEMP- identifiers are kept as the tool's own identifier but are not recorded as vulnerability IDs, because no CVE database can enrich them. In DefectDojo Pro, CVE IDs also feed automatic KEV and EPSS enrichment.
  • Patch tracking per host. Reimporting each host's report into the same Test mitigates CVEs that were patched and adds new ones.
  • Shared workflow. Package findings follow SLAs, can be assigned to the team that owns the host, risk-accepted when no fix exists, and pushed to Jira.

How This Integration Works

DefectDojo imports debsecan output with the debsecan Scan scan type. The parser detects whether the file is in detail or simple format.

1. Produce a report on the host. The detail format is the one to use:

debsecan --format detail > debsecan.txt

In detail format, each CVE is a block with a short description, the installed package and version, the source package it was built from, and where a fix has landed. The simple format (and summary) is one CVE and package pair per line with nothing else, so findings imported from it carry no version or fix information.

Severity needs a word of explanation. debsecan assigns no severity at all: its output says whether a CVE applies and whether a fix exists, not how serious it is. DefectDojo imports every debsecan Finding as Medium, uniformly, rather than inventing a score from fix status or description text.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select debsecan Scan, and upload the file. To automate it, use the import 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=debsecan Scan" 
  -F "file=@debsecan.txt" 
  -F "product_name=web-01" 
  -F "engagement_name=Host Packages" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "debsecan Scan" 
  --report-path "./debsecan.txt" 
  --product-name "web-01" 
  --engagement-name "Host Packages" 
  --auto-create-context

3. Reimport on a schedule. Run debsecan from a daily or weekly job on each host and send the output to /api/v2/reimport-scan/ for that host's Test, so patched packages close their findings.

Data Granularity: What Gets Imported

DefectDojo Field Source in debsecan Output Notes
Title CVE ID and package Formatted as CVE-ID: package
Severity None in source Always Medium
Description Description text and package details CVE, installed package and version, built-from source, flags (simple format), fix availability
Mitigation "fixed in" lines Where the fix has landed; empty if none reported
Component Name Installed package Binary package name
Component Version Installed version detail format only
Vulnerability IDs CVE ID Only real CVE- IDs; TEMP- IDs excluded
Vulnerability ID from tool CVE or TEMP ID Always set
Finding type Static All findings are marked static
Deduplication Hashcode vulnerability_ids, component_name

Use Cases

Patch compliance for a Debian fleet: An operations team runs debsecan nightly on every Debian host and reimports into a Test per host. The security team reports open package CVEs by host and by age without logging in to any server.

Separating fixable from unfixable: Mitigation is populated only when Debian has a fix. Filtering on that lets a team patch everything fixable now and risk-accept the rest with an expiration date, so it comes back for review when a fix is likely.

Golden image checks: A team that builds Debian base images runs debsecan in the image build and imports the result into the image's Asset, so base image CVEs are tracked separately from application code.

Audits: Each package CVE has a discovery date, status history, and the fix that closed it, which supports patch management evidence requests.

Operational Tips

  • Always use --format detail. The simple format loses version, source package, and fix information.
  • Severity is Medium for every finding. Grade them during triage (or with DefectDojo Pro's Rules Engine and EPSS or KEV enrichment) rather than treating all of them as equal.
  • Import each host into its own Asset or its own Test, so findings stay tied to a specific machine. Hostnames are not in the debsecan output, so the Asset or Test name has to carry that.
  • Use close_old_findings=true or reimport into the same Test so packages that were upgraded or removed are mitigated.
  • TEMP- issues have no CVE yet. Watch them, since they can be reassigned a CVE later and will then appear as a new finding.
  • Tag imports with the Debian suite and environment (for example tags=bookworm,prod) to compare exposure across releases.