Seal Security Integration with DefectDojo

Seal Security Integration with DefectDojo

Seal Security is a vendor focused on remediating vulnerable open source dependencies without forcing a version upgrade. Instead of pointing to the next fixed release, Seal backports the security fix onto the version a project already uses and publishes it as a "sealed" version of the same package, such as lodash@4.17.15-sp1 for npm or requests@2.19.1+sp1 for PyPI. Sealed packages are served through registry proxies, so adopting one is a package manager configuration change. The Seal CLI scans a project against Seal's vulnerability data and can export its results as CSV, which DefectDojo imports.

Seal Security Integration with DefectDojo

We brought in Seal Security for the dependencies we could not upgrade: a framework pinned two major versions back, a library whose fixed release breaks our API. Those findings used to sit open for months with a note saying "blocked on upgrade." Importing Seal Security results into DefectDojo shows, for every vulnerable package, whether a sealed version exists right now. That changes the conversation with engineering from "plan a migration" to "change one line in the registry config," and DefectDojo tracks the Finding until the next scan shows it closed.

Why Seal Security Matters

Most SCA tools answer one question: is this package vulnerable? The harder question is what to do when the fix requires a breaking upgrade.

• Sealed versions keep the same major version and change only the patch content, so they are intended as drop-in replacements.
• This targets the long tail of findings that stay open because upgrading is expensive, not because nobody cares.
• The CLI reports, per vulnerable package, whether a sealed version is available for the exact version in use.
• Seal reports vulnerabilities reached through embedded (shaded) packages, which are easy to miss when a vulnerable library is bundled inside another artifact.
• Knowing a fix exists is only useful if someone acts on it. That needs ownership and tracking.

Advantages of This Integration

What we gained by sending Seal Security results through DefectDojo:

• Fix availability on every Finding. When Seal has a sealed version, DefectDojo sets fix_available and the mitigation names the version to move to. When it does not, the mitigation says so plainly.
• One Finding per vulnerability. A CSV row listing several identifiers for one package becomes one Finding per identifier, so each can be triaged and risk-accepted on its own.
• Stable deduplication. Findings are matched on vulnerability ID, component name, and component version. Severity is left out on purpose so a future score column does not duplicate existing Findings.
• Visibility into shaded dependencies. For a vulnerability that arrives through an embedded package, the description names the embedding package while the component stays the package actually present in the project.
• A clear lifecycle. Reimporting after a project switches to sealed versions mitigates the Findings that no longer appear.
• Prioritization with filters. Filtering on fix availability gives the team a list of Findings that can be closed now, without an upgrade project.

How This Integration Works

DefectDojo imports Seal results with the Seal Security Scan scan type.

1. Export CSV from the Seal CLI. Run the scan in the project directory with the --csv flag:

seal scan --csv results.csv

The export contains one row per vulnerable package, with the library, version, ecosystem, vulnerability identifiers, whether it can be sealed, and the sealed version. A scan that finds nothing may leave the file empty, which imports as zero Findings.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Seal Security Scan, and upload the file. For automation, use 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=Seal Security Scan" 
  -F "file=@results.csv" 
  -F "product_name=orders-service" 
  -F "engagement_name=CI" 
  -F "auto_create_context=true"

DefectDojo Pro users can run it with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Seal Security Scan" 
  --report-path "./results.csv" 
  --product-name "orders-service" 
  --engagement-name "CI" 
  --auto-create-context

3. Reimport on every build. Send later exports to /api/v2/reimport-scan/ against the same Test. Packages moved to sealed versions drop out of the report and their Findings are mitigated.

Data Granularity: What Gets Imported

Multiple identifiers in one cell are split on the pipe character, and shaded entries written as ID(via shaded lib) are unpacked into the identifier and the embedding package names.

Use Cases

For pinned legacy dependencies: A team running an older framework version imports Seal results and filters on fix available. Each Finding with a sealed version becomes a small task (switch the package source), while the rest stay on the upgrade backlog with a clear reason.

In a CI/CD pipeline: Each build runs the Seal CLI and reimports the CSV into a Test for the service. When engineers adopt sealed packages, the next build mitigates those Findings without anyone closing them by hand.

When reporting on remediation options: AppSec leads can show how many open dependency Findings have a sealed fix available today, which helps decide where to spend upgrade effort and where a backported patch is enough.

For shaded Java artifacts: A service shipping a fat JAR sees vulnerabilities from embedded libraries attributed to the JAR it actually depends on, with the embedded package named in the description.

Operational Tips

• Without a Score column every Finding imports as Medium. Adjust severity during triage for packages that matter most, or cross-check against another SCA tool's results on the same Asset.
• Because severity is not in the hash, a future CLI version that exports scores will not fork existing Findings into duplicates.
• Not every identifier is a CVE. Search by GitHub advisory or Snyk ID as well when looking for a specific vulnerability.
• Use the fix available filter to build a quick-win list for each sprint.
• Tag imports with the ecosystem or repository (for example tags=maven,orders-service) to split metrics by stack.
• Risk-accept Findings with no sealed version and no feasible upgrade, with an expiry, so they return for review when Seal or the upstream project ships a fix.