Goal Summary:

An elevator pitch (value statement) that describes the Feature in a clear, concise way. Complete during New status.
This feature extends the 4.10 base image layer identification capability (ROX-27632) to enable policy evaluation that differentiates between base image layers and application layers. This allows security teams to create policies that don't produce false positives from base image choices and don't mask violations in application layers.

Note: The 4.10 implementation uses a user-defined base images list, not automatic detection. Users must explicitly configure their organization's base images in RHACS before layer attribution works.

Background: How 4.10 Base Image Identification Works

Before 4.10, when RHACS reported CVEs for a container image, there was no way to know:

• Which CVEs came from the base image (managed by platform/security teams)
• Which CVEs came from application layers (managed by dev teams)

The 4.10 Solution: User-Defined Base Images

Base images are explicitly defined by users in Platform Configuration → Base Images.

Workflow:

1. User defines base images — Enters paths like registry.redhat.io/ubi9:9.* (wildcards supported)
2. RHACS pulls and stores base images — Images are pulled from registries and the metadata is stored (name, digest, created timestamp, layer chain, CVE data)
3. Application image is scanned — When scanning an application image, RHACS compares its layer chain against stored base images
4. Component attribution to layer type — If the layer index is higher than the last base image then we know this is an application layer. each component is marked as belonging to base or application
5. CVE attribution — CVE can be found in both a base or an application component.  Even in the same image.

What 4.10 Delivers

• Configuration UI to define base images (Platform Configuration → Base Images)
• CVE filtering by layer type in Vulnerability Management (filter: Layer type = Base image)
• Base image assessment - include information about the base image
  • name
  • digest
  • age

Goals and expected user outcomes:

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

Customer Problem

Motivation

My security team will maintain base image components and vulnerability management, and supply updated base images for DevOps to use. I will maintain a list of approved based images. DevOps should not be responsible for vulnerabilities in base image layers.

Use Cases

As a security engineer using ACS -

1. I want image vulnerability policies to differentiate between CVEs coming from a base image to CVEs coming from an application layer, so that I can effectively route the violations to the respective owners, who are in two different teams.     

This is the highest value use case.  It may serve as MVP, but the following two uses cases are highly desired as well.

1. I want base image identification policies to restrict which container images DevOps teams will be permitted to use so that I can reduce the security risk of my teams using untrusted base images. 
   1. I want to  evaluate these policies in Build and Deploy stages.
   2. I also want to trigger policy violations for running applications, when a base image layer is removed from an approved list , when those deployments are using the now-unapproved base.
2. I want base image age policies to enforce the use of newer versions of base images, in order to help my teams keep the list of approved base images up to date. Specifically, a base image layer would not be permitted, even if it were previously approved, if it is older than a certain age. In other words, I want to distinguish in policy criteria the age of the base layer, separate from the overall image age.
   1. I want to  evaluate these policies in Build and Deploy stages.
   2. I also want to trigger policy violations for running applications, when a base image layer violates the age policies, when those deployments are using the now out-of-compliance  base.

Proposed Policy Criteria (for review with Eng team)

Prerequisite

All base image policy criteria require:

1. The organization has defined base images in Platform Configuration → Base Images
2. The image being evaluated has layers that match a defined base image

If no match exists, base image criteria will not trigger.

Policy differentiation (suggestion)

Add a new (optional)  Layer Type modifier  {Base | Application}

• If the layer type is missing, the scope of the criteria is the entire image (existing behavior)
• If the layer type is present, the scope of the criteria is limited to that layer type only

Section 1:  Policy Criteria to be supported 

New Modifier: Layer Type

When Layer Type is not specified, criteria apply to the entire image (existing behavior).

"Image Registry" Criteria (with Layer Type = Base)

These criteria, when combined with `Layer Type = Base`, apply to the matched base image.

"Image Content" Criteria (with Layer Type = Base)

These existing criteria, when combined with `Layer Type = Base`, apply to the matched base image.

"Image Scanning" Criteria

These criteria can be scoped using the Layer Type modifier. 

With Layer Type = Base : applies to CVEs in base layers only

With Layer Type = Application: applies to CVEs in app layers only{}

—

Section 2: Policy Criteria — Out of Scope

—

Open Questions for Engineering

1. Scan lifecycle for base images:

• Are base images re-scanned on a schedule?
• Is there a `last_scanned` timestamp for base images?

2. Multiple base image matches:

• If an image matches multiple defined base images, how is this handled in policies?
• Should policies evaluate against all matches or the most specific?

3. Performance considerations:

• What's the performance impact of adding base image criteria to policy evaluation?

4. Error handling:

• What happens if a defined base image can't be pulled ?
• How do we surface this to users?

UX requirements 

1. UI mockup with the new modifier
2. How do we address the n/a combinations?  
   1. At a minimum, Document invalid combinations
   2. Highly desired - check in the UI and block combinations that do not make sense

Acceptance Criteria 

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

1. Users can create policies with the new Layer Type modifier (Base / Application)
2. Existing image identifier criteria (Name, Registry, Tag, Age) work with Layer Type modifier
3. Existing CVE-related criteria (CVSS, Severity, Fixable, Component) work with Layer Type modifier
4. New Image Digest criterion available for exact base image matching
5. Violation details show which base image was matched when relevant
6. Comprehensive documentation 

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios together with user type/persona. Initial completion during Refinement status.

<your text here>

Out of Scope (Optional):

High-level list of items that are out of scope. Initial completion during Refinement status.

<your text here>