Xeol Integration with DefectDojo

Xeol Integration with DefectDojo

Xeol is an open source scanner for end-of-life (EOL) software and dependencies, published under the Apache-2.0 license by the xeol-io project. It scans container images, directories, and SBOMs (Syft, SPDX, and CycloneDX formats are accepted as input) and reports packages whose release cycle has reached, or is approaching, its vendor end-of-life date. Each match carries the product's release cycle, EOL date, the artifact found, and where it was found. DefectDojo imports Xeol's JSON report.

Xeol Integration with DefectDojo

CVE scanners tell us what is vulnerable today. Xeol tells us what will stop getting fixes, which is a different and often bigger problem for long-lived services. We import Xeol reports into DefectDojo next to our container CVE scans so an EOL framework or runtime becomes a tracked finding with an owner, instead of a line in a pipeline log that nobody reads after the build passes.

Why Xeol Matters

Unsupported software is a slow-moving risk. Once a release line is past end of life, new vulnerabilities in it may never be patched.

• It finds EOL packages and runtimes inside container images, including ones pulled in by base images.
• It works from SBOMs, so you can check an artifact you already inventoried without rescanning it.
• It names the release cycle and EOL date, which is what a team needs to plan an upgrade.
• It complements CVE scanning: a package can have zero known CVEs and still be unsupported.

Advantages of This Integration

Importing Xeol into DefectDojo adds structure to EOL tracking:

• EOL as a first-class finding. Each match becomes a finding with CWE-672 (Operation on a Resource after Expiration or Release), so EOL items can be filtered and reported as their own class.
• Component and version on the finding. The artifact name and version populate component fields, which lets you group EOL findings by package across Assets.
• Deduplication on what matters. Findings are matched on title, component name, and component version, so rescanning the same image does not create duplicates, and an upgrade to a new version shows up as a change.
• Upgrade plans with deadlines. SLAs, assignment, and Jira tickets turn "we should upgrade someday" into tracked work with a due date.
• Accepted exceptions. When an upgrade is scheduled but not yet possible, risk acceptance with an expiration date documents the decision.

How This Integration Works

DefectDojo imports Xeol output with the Xeol Parser scan type, using UI Import, API Import, or Universal Importer in DefectDojo Pro.

1. Run Xeol with JSON output. Point Xeol at an image, a directory, or an SBOM and write the report to a file:

xeol myapp:1.4.2 -o json --file xeol-report.json

The parser expects a JSON object with a top-level matches list, plus an optional distro block. A file without matches imports as zero findings rather than failing.

Each match pairs a Cycle block (the product name, release cycle, EOL date, latest release date, and a permalink for the product) with an artifact block (the package name, version, type, licenses, PURL, CPEs, and the paths and image layers where it was found). DefectDojo copies all of this into the finding description, so an engineer looking at the finding can see which layer of the image introduced the EOL package without rerunning the scan.

If you also want the pipeline itself to stop, Xeol's --fail-on-eol-found flag makes it exit with an error when it finds EOL packages. Write the report first and import it in a step that runs even when the scan step fails, so the findings still reach DefectDojo.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Xeol Parser, and upload the JSON. 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=Xeol Parser" 
  -F "file=@xeol-report.json" 
  -F "product_name=myapp" 
  -F "engagement_name=EOL Tracking" 
  -F "auto_create_context=true"

With Universal Importer in DefectDojo Pro:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Xeol Parser" 
  --report-path "./xeol-report.json" 
  --product-name "myapp" 
  --engagement-name "EOL Tracking" 
  --auto-create-context

3. Reimport on each build. Send later reports to /api/v2/reimport-scan/ against the same Test so upgraded components are mitigated automatically.

Data Granularity: What Gets Imported

Use Cases

Container build gates: Each image build runs Xeol and reimports into the image's Test. A new Critical EOL finding shows the team that a base image or dependency has crossed its end-of-life line.

Runtime upgrade planning: A platform team filters EOL findings by component name to see every service still on an unsupported language runtime, then assigns upgrades by Asset.

SBOM review: For third-party or archived artifacts, teams run Xeol against an existing SBOM and import the results without rebuilding anything.

Audit and compliance: EOL findings with CWE-672, owners, and closure dates provide a record of how unsupported software was handled.

Operational Tips

• Know how severity is assigned. The parser marks a match Critical whenever its Eol field holds a date or true, and does not compare that date with today. Matches with an empty or false Eol import as Info.
• The DefectDojo parser docs describe a tiered scale by weeks past EOL. The current parser code uses the Critical or Info rule above, so set SLAs based on that.
• Give EOL findings a longer Critical SLA, or a dedicated Engagement, if a platform upgrade cannot realistically land in your normal Critical window.
• Use risk acceptance with an expiration date for components with a scheduled upgrade rather than closing them.
• Pair Xeol with a CVE scanner on the same Asset. EOL tells you what will stop receiving fixes; CVE findings tell you what is exploitable now.
• Tag imports with image name and tag so EOL findings can be traced to a specific build.