Proposal: make CVE enrichment durable using the existing worker model

[Abdulrehman-glitch]

I’ve been reviewing the CVE enrichment flow and wanted to check whether this would fit OpenShield’s roadmap before starting any implementation.

At the moment, POST /api/scans/<scan_id>/enrich marks enrichment as ENRICHING and starts the work in a daemon threading.Thread inside the API process.

Because enrichment can take some time due to NVD lookups and rate limits, it looks like an API/container restart or worker recycle could terminate that thread before completion, potentially leaving the persisted enrichment state stuck at ENRICHING.

OpenShield already has a PostgreSQL-backed worker model for scan execution, including atomic job claiming and stale-job recovery. I was wondering whether CVE enrichment could reuse the same general pattern rather than introducing another queue dependency such as Celery or Redis.

A possible scope would be:

persist/queue enrichment work through PostgreSQL
atomically claim enrichment jobs to prevent duplicate execution
move enrichment execution out of the API process
recover stale/incomplete enrichment jobs after process failure
preserve clear COMPLETED / FAILED status handling
keep the operation idempotent where possible
add regression tests for duplicate requests, failure, and worker restart/recovery

I’d aim to keep this incremental and aligned with the existing scan-worker architecture rather than introducing a new job-processing stack.

Would this direction fit the project architecture, and would you be open to an external contribution for it? If so, I’d be happy to work from whatever persistence/job model you prefer.