Add Seal Security CSV parser

[amita-seal]

Description

Adds a parser for the CSV export of the Seal Security CLI, produced by seal scan --csv <file>. Seal backports security fixes into "sealed" versions of open-source packages, so a vulnerable dependency can be remediated without a major-version upgrade.

The export has one row per vulnerable package, with a pipe-separated list of vulnerability identifiers:

Library,Version,Ecosystem,Vulnerabilities,Can Seal,Sealed Version
lodash,4.17.15,NPM,CVE-2021-23337|CVE-2020-8203,TRUE,4.17.15-sp1

Each identifier becomes its own Finding, so that each one can be triaged and risk-accepted independently. Identifiers are not always CVEs: Seal reports the most specific identifier it has, falling back to a GitHub advisory or Snyk identifier when no CVE is assigned.

Two properties of the export are worth calling out, both covered by test files:

• A scan without findings leaves the export file empty rather than writing a header, so a zero-byte file is a valid report that yields no findings.
• A vulnerability that reaches the project through an embedded (shaded) package is reported as CVE-2021-1234(via shaded lib1&lib2). The identifier is used for the Finding, and the embedding packages are named in the description. The Finding's component stays the package that is actually present in the project.

When a sealed version is available, fix_available is set and the mitigation names the version to update to.

Severity

Not every Seal report carries severity, so the parser supports both shapes of the export.
When a Score column is present its value is mapped onto the standard severity bands;
when it is absent there is nothing in the report to derive a severity from, and findings
are imported as Medium. Either export imports cleanly, with no configuration and no
scan-type variant.

For that reason severity is deliberately left out of the deduplication hashcode. A
project can import a report without a score today and one with a score tomorrow, and
including severity would fork every existing finding into a duplicate at that point.

Test results

$ ./run-unittest.sh --test-case unittests.tools.test_seal_parser.TestSealParser
Ran 6 tests in 0.020s
OK

$ ./run-unittest.sh --test-case unittests.test_parsers
Ran 2 tests in 0.513s
OK

$ ./run-unittest.sh --test-case unittests.test_factory
$ ./run-unittest.sh --test-case unittests.test_deduplication_logic
Ran 89 tests in 17.577s
OK (skipped=2)

Ruff clean against the pinned ruff==0.16.1.

Documentation

docs/content/supported_tools/parsers/file/seal.md added.

Checklist

• Make sure to rebase your PR against the very latest dev.
• Features/Changes should be submitted against the dev.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is Ruff compliant (see ruff.toml).
• Your code is python 3.13 compliant.
• If this is a new feature and not a bug fix, you've included the proper documentation in the docs at https://github.com/DefectDojo/django-DefectDojo/tree/dev/docs as part of this PR.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

🤖 Generated with Claude Code