Skip to content

Add case-insensitive expression index on Vulnerability_Id.vulnerability_id#15218

Draft
devGregA wants to merge 1 commit into
DefectDojo:masterfrom
devGregA:feature/threat-intel-vulnid
Draft

Add case-insensitive expression index on Vulnerability_Id.vulnerability_id#15218
devGregA wants to merge 1 commit into
DefectDojo:masterfrom
devGregA:feature/threat-intel-vulnid

Conversation

@devGregA

Copy link
Copy Markdown
Contributor

Add a case-insensitive expression index on Vulnerability_Id.vulnerability_id

Adds an index on UPPER(vulnerability_id), finding_id to dojo_vulnerability_id.

Why

Vulnerability-id → finding lookups (CVE-keyed enrichment, exploit/threat-intel matching, dedupe helpers) currently sequentially scan dojo_vulnerability_id — the string column has no index today, and scanner-supplied ids aren't case-normalized, so any correct lookup must fold with UPPER(). This adds the matching functional index; including finding_id makes the changed-CVE → finding fan-out an index-only scan.

What

  • Vulnerability_Id.Meta.indexes gains Index(Upper("vulnerability_id"), "finding", name="dojo_vulnid_upper_idx").
  • Migration 0278 builds it CREATE INDEX CONCURRENTLY IF NOT EXISTS (non-atomic) so it doesn't lock the table on large instances, with SeparateDatabaseAndState keeping Django's model state in sync. IF NOT EXISTS makes it idempotent and safe to co-exist with any downstream migration that created the same-named index first.

Notes

  • ~250–350 MB on a 5M-finding instance; concurrent build, no lock.
  • Verify build time on a large clone before release.

🤖 Generated with Claude Code

…ty_id

Index UPPER(vulnerability_id), finding_id on dojo_vulnerability_id so CVE-keyed
lookups (enrichment, exploit/threat-intel matching, dedupe helpers) stop
sequentially scanning the table; scanner-supplied ids are not case-normalized, so
the index and any query both fold with UPPER(). finding_id is included so
changed-CVE -> finding fan-out is an index-only scan. Built CONCURRENTLY IF NOT
EXISTS (non-atomic migration) via SeparateDatabaseAndState so it does not lock the
table on large instances and is idempotent.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions github-actions Bot added the New Migration Adding a new migration file. Take care when merging. label Jul 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

New Migration Adding a new migration file. Take care when merging.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant