fix(importers): accept scan severities case-insensitively

[Maffooch]

Description

Scan imports fail with a hard ValidationError when a finding's severity is supplied in the wrong letter case — for example a Generic Findings Import whose findings carry "severity": "medium":

django.core.exceptions.ValidationError: ['Finding severity "medium" is not supported.
Any of the following are supported: ['Info', 'Low', 'Medium', 'High', 'Critical'].']

The whole async import task aborts, so a single lowercase severity value stops the entire report from being ingested.

Root cause

BaseImporter.sanitize_severity (dojo/importers/base_importer.py) only normalized case for the Info/Informational/None family. Every other severity was matched case-sensitively against SEVERITIES (['Info', 'Low', 'Medium', 'High', 'Critical']), so "medium", "high", "critical" and "low" fell straight through to the "not supported" ValidationError. Several parsers (Generic Findings Import among them) pass a user-provided severity string through untouched, which is how a wrong-case value reaches the sanitizer.

Fix

Normalize the severity's case against the supported set before the membership check: a value whose lowercase form matches a supported severity is mapped to the canonical spelling ("medium" → "Medium"). Genuinely unsupported values still raise ValidationError, and the existing Info/None handling is unchanged. This makes severity matching consistently case-insensitive, matching the leniency already applied to the Info family. No migration — this is pure importer-validation logic.

Impact on DefectDojo Pro

sanitize_severity is inherited unchanged by the Pro importers: Pro's importer goes through the OSS process_findings/_process_findings_internal path, and Pro's Smart Upload importer calls self.sanitize_severity directly. Neither overrides it, so the fix flows through to Pro's importers and Smart Upload with no Pro-side change and no override to update.

Test results

Added TestSanitizeSeverity in unittests/test_importers_importer.py:

• A parameterized case-insensitivity test covering the failing inputs (medium, MEDIUM, high, HIGH, critical, low) alongside control inputs already in canonical case (Medium, Critical, Info) and the existing info/informational/none normalization. It asserts both the normalized severity and that numerical_severity is set correctly.
• A test that a genuinely unsupported value (bogus) still raises ValidationError, locking in that the sanitizer stays strict for real garbage.

Verified locally against a PostgreSQL test database: the six wrong-case cases fail before the fix with the exact ValidationError above and pass after; the full test_importers_importer.py module is green (63 passed, 23 subtests) with no collateral damage.

Documentation

No documentation change needed — this restores acceptance of a value users already reasonably expect to work; there is no new setting or user-facing behavior to document.

Checklist

• Bugfix submitted against the bugfix branch.
• Meaningful PR name for release notes.
• Code is Ruff compliant.
• Code is Python 3.13 compliant.
• No model changes / no migration required.
• Added unit tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DUqP65vyMekyL3ZgTBCkmw

---

Generated by Claude Code

[Maffooch]

CI note: the only red check is test-rest-framework (linux/amd64, false) / Rest Framework Unit Tests (debian), on a single failure:

FAIL: test_asset_edit_cannot_add_authorized_users
 (unittests.test_v3_alias_authorized_users_api_authz)
AssertionError: 403 != 404 : b'{"detail":"No Product matches the given query."}'

This is unrelated to this PR. The change here is confined to dojo/importers/base_importer.py::sanitize_severity (case-insensitive severity normalization) plus a unit test in unittests/test_importers_importer.py — nothing that touches product authorization or object visibility. The failing test is a pre-existing test_v3_alias_authorized_users_api_authz case that asserts a 403 permission-denied but received a 404 ("No Product matches the given query"), i.e. the product was filtered out by object-visibility before the permission check — a shared-state/ordering-sensitive outcome in the single-process REST suite, not a deterministic failure of this diff. The identical test-rest-framework check is green on concurrent bugfix PRs (e.g. #15845).

Locally against a PostgreSQL test DB, the six wrong-case severity inputs fail before this fix with the exact production ValidationError and pass after it, and the full test_importers_importer.py module is green (63 passed).

I'll re-run the failed job once the workflow finishes (a re-run is currently blocked while the run is still in progress) to confirm the flake clears.

---

Generated by Claude Code

[Maffooch]

Update: the merge queue dequeued this PR (CI_FAILURE), and the cause is the same pre-existing flaky test flagged above — test_asset_edit_cannot_add_authorized_users in unittests/test_v3_alias_authorized_users_api_authz.py:

AssertionError: 403 != 404 : b'{"detail":"No Product matches the given query."}'

This time it failed on the linux/arm64 rest-framework shard (merge-queue run 30000); on the PR head earlier it failed on linux/amd64 and passed on re-run. It's the same 403-vs-404 object-visibility flake — the test intermittently sees the product filtered out before the permission check — and it is unrelated to this diff (which only touches sanitize_severity). The change here has never failed a check.

Since the flaky test is outside this PR's scope, I'm not modifying it here (that would widen an importer bugfix into an unrelated test-isolation fix). This PR just needs to be re-queued — the merge-queue check should pass on a clean run, as it did on the PR head. Re-queuing/merging is a maintainer action I can't perform. The underlying flake is worth a separate fix so it stops blocking the queue.

---

Generated by Claude Code