Release Notification: Compliance Criticality Mapping Changes in Qualys Container Security

Overview

As part of our ongoing effort to standardize severity terminology across the platform, we are updating the criticality labels used for compliance evaluation in images and containers. This change aligns the naming convention with the widely accepted criticality model already used in Qualys TotalCloud™’s Container Security (KSPM) and Cloud Security Posture Management (CSPM) capabilities, making it easier for security teams to interpret and act on compliance findings consistently across the platform.

This notification outlines the new mapping, the scope of affected APIs and UI components, how the transition will work for existing scans, and what users can expect going forward.

Criticality Mapping (New)

The table below shows how existing criticality values map to the new standardized values:

Old Values (Previously Used)	New Value
Minimal	Low
Medium, Serious	Medium
Critical, Urgent	High

Note: To align with the widely accepted criticality model used in TotalCloud’s KSPM & CSPM capabilities, we are consolidating the existing compliance criticality tiers into a simpler, more intuitive three-level scale. This ensures a consistent experience for users working across container security and cloud security workflows.

Scope of Changes

These changes apply to both the UI and API layers, specifically for compliance evaluation in images and containers. The rollout is staggered across two releases to ensure stability. Note that backward-compatibility behavior applies only to the API — the UI will always reflect the new criticality values.

These changes are applicable to the following APIs from release 1.43 onwards:

• Image Compliance — To get the compliance posture for an Image
• Container Compliance — To get the compliance posture for a Container
• List of Controls – To get a list of all compliance controls
• Fetch Control Details – To get the details of a specific control

No other APIs or UI components are affected by this change.

Backward Compatibility Behavior (API Only)

The backward compatibility rules described in this section apply exclusively to the API. The UI will always display the new criticality values regardless of when the image or container was scanned.

To ensure a smooth transition for integrations relying on existing data, the following rules apply:

For images/containers scanned before backend version 1.43:

Older scan data retains the original criticality values internally. The display behavior is controlled by the showOldCriticality parameter:

• showOldCriticality = true: The criticality value will be returned exactly as it was at the time of the scan. This is useful for audits or historical comparisons where the original compliance labels need to be preserved.
• showOldCriticality = false (default): The API will automatically convert old criticality values to their new equivalents in the response, ensuring a consistent experience across old and new scan data.

For images/containers scanned with backend version 1.43 or later:

For all new scans performed after the 1.43 backend release, the API always returns the new criticality values — regardless of the showOldCriticality parameter setting. This ensures that fresh compliance data always reflects the updated standard.

QScanner Behavior

The criticality evaluation is also tied to the version of QScanner used at the time of the scan:

• Older QScanner versions (prior to v5.0.0): Scans executed using earlier QScanner versions will continue to follow the legacy compliance criticality evaluation logic. As a result, the scan results will display the criticality labels as calculated under the previous methodology.
• Newer QScanner versions (v5.0.0 and later): Scans executed using newer QScanner versions will apply the updated compliance evaluation logic and will produce the new standardized criticality values.

This means the compliance result is consistent with the QScanner version that performed it, ensuring accuracy and traceability across scan histories.

QQL (Query Language)

From the API side, there are no changes to QQL filter behavior. All existing filter values that users or integrations currently rely on will continue to work exactly as before. No updates to existing queries or automation scripts are required.