-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
1. Proposed title of this feature request
Mark as fixable Operator based workloads when new version of the Operator include the fix only
2. What is the nature and description of the request?
Determine the specific OpenShift or layered operator version that resolves a given Red Hat Security Advisory (RHSA). Subsequently, set the "fixable" flag based on the availability of that operator version.
This information should be accessible from UI and API and documented accordingly
3. Why does the customer need this? (List the business requirements here)
PCI-DSS compliance depends on the availability of a fix for a specific vulnerability.
Currently, the ACS system marks a component as "fixable" (sets the fixable flag to true) as soon as a security advisory is released for it.
However, an operator that uses this component may not be rebuilt and made available immediately. Consequently, the ACS system indicates that a fix is available, but an operator containing the fixed component does not yet exist. Failure to meet the PCI-DSS requirements in this scenario could result in a compliance error, as the Service Level Agreement (SLA) would not be satisfied.
For example, when an advisory is released for a component like OpenSSL, ACS will identify any deployed pods that are fixable because they lack the necessary OpenSSL update. However, the Operators managing these pods may not incorporate this new OpenSSL version until they are rebuilt. Consequently, ACS will flag the pods managed by these Operators as fixable, but a resolution cannot be applied until a new Operator version is published.
This delay could result in a failure to comply with the PCI-DSS Service Level Agreement (SLA).
4. List any affected packages or components.
Scanner
Central