Goal Summary:

Sunsetting the legacy Scanner v2 engine within Red Hat Advanced Cluster Security (ACS) to consolidate the vulnerability management pipeline. This feature ensures all image scanning is handled exclusively by Scanner v4, providing higher precision, better language support, and reduced operational complexity by eliminating the need to maintain dual scanning architectures.

Goals and Expected User Outcomes:

• Primary Persona: Security Administrators and DevSecOps Engineers.

• Outcome: A unified scanning experience where all vulnerability data is derived from the v4 engine, eliminating "data split" or conflicting results between versions.

• Functional Change: Complete removal of Scanner v2 components. Users will no longer see "Scanner v2" as a configurable option in the UI or via the API.

• Existing Feature Expansion: Enhances Vulnerability Reporting modules by ensuring all audits are based on the more robust Scanner v4 vulnerability database.

Acceptance Criteria:

• Decommissioning: All Scanner v2-specific deployments, services, and config maps must be removed from the ACS installation manifests (Helm charts/Operator).

• Auto-Migration: Upon upgrade, any existing scan requests queued for v2 must be transparently rerouted to Scanner v4.

• API Integrity: Deprecated v2 API endpoints must return a 410 Gone or a clear error message directing users to the v4 equivalents.

• UI Cleanup: All references to "v2" must be purged from the Vulnerability Management dashboards.

• Performance: Total ACS resource footprint should decrease as the v2 database (Postgres) and scanning sidecars are removed.

• Security: Ensure that Scanner v4 successfully inherits all secret/pull-secret configurations previously utilized by v2.

Success Criteria or KPIs Measured:

• System Overhead: A measurable reduction in Central/Scanner memory and CPU usage (targeting 15-20% reduction in baseline resource requirements).

• Scan Accuracy: Elimination of "false negatives" previously associated with v2’s older indexing logic.

• System Reliability: 0% downtime for active scanning pipelines during the transition from v2 to v4 during the upgrade process.

• Database Efficiency: Reduction in total storage used by Central due to the removal of legacy v2 vulnerability metadata.

Use Cases (Optional):

• Standard Upgrade Scenario: An administrator performs a minor version upgrade. The ACS Operator automatically detects and deletes the Scanner v2 deployment while ensuring the Scanner v4 deployment is scaled to handle the full load.

• Legacy Integration Scenario: A CI/CD pipeline using a legacy roxctl command for a v2 scan receives an informative error or is automatically redirected to use the v4 scanning logic, maintaining the "fail-build" security gate.

Out of Scope (Optional):

• Vulnerability Database Content: This feature does not involve adding new CVE data, only the engine used to process it.
• Third-Party Integration: Removal of v2 does not impact external integrations like Clair or Quay, provided they do not rely on the internal v2 engine for proxying.