Skip to content

Roadmap: Enterprise vulnerability management rollout #311

Description

@JustNZ

Objective

Evolve JustScan from point-in-time container scanning into a self-hosted vulnerability-management platform that continuously reassesses risk, coordinates remediation, and produces trustworthy evidence for enterprise, government, and EU-regulated environments.

Historical scan evidence and completed CI verdicts must remain immutable. Updated intelligence changes a separate current posture.

Release 1 — Living CVE intelligence

Recommended order: establish the versioned model first; feed adapters and offline bundle work can then proceed in parallel; finish with the user-facing timeline, policy, and notification integration.

Release outcome: An operator can open an old scan and see that a CVE was reduced, rejected, newly exploited, newly fixed, or no longer applicable, with source evidence and no loss of the original result.

Release 2 — VEX and remediation operations

Depends on the Release 1 intelligence/current-posture model. Product/release identity should land before VEX matching and remediation automation.

Release outcome: A team can receive a changed CVE signal, determine exact product applicability, document a VEX decision, assign remediation, enforce an SLA, connect the case to delivery teams, and export response evidence.

Release 3 — Regulated and air-gapped operations

Evidence bundles depend on the product, VEX, and remediation records from Release 2. Audit/RBAC work can begin earlier where it only extends existing governance surfaces.

Release outcome: An offline or regulated deployment can import verified intelligence, perform scans, preserve signed evidence, export audit and regulatory-support material, restore from backup, and operate without a mandatory external service.

Cross-cutting delivery rules

  • Run new policy capabilities in report-only mode before they can block pipelines.
  • Treat stale required intelligence and operational scan failures as errors, never passes.
  • Use additive migrations and preserve existing ownership, suppressions, audit records, and verdict history.
  • Add source attribution, timestamps, health metrics, and idempotency to every external feed or connector.
  • Keep connected and air-gapped workflows behaviorally equivalent.
  • Describe CRA functionality as evidence and workflow support, not automatic certification or legal compliance.

Deferred candidates

These are intentionally outside the three-release rollout and should receive separate discovery before implementation:

  • Kubernetes/Helm misconfiguration, embedded-secret, and license-policy scanning.
  • Registry-event rescanning and Kubernetes admission control.
  • Runtime/reachability context for vulnerable components.
  • Native ServiceNow and additional ticketing/SIEM adapters.
  • Cryptographic inventory/CBOM and post-quantum migration reporting.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions