Overview

Suppressions 2.0 introduces a unified, scope-driven model for accepting vulnerability risk in the Aqua platform. It replaces the previous Acknowledgements workflow with a more flexible and deterministic approach that persists across rescans, lifecycle stages, and environments.

 

This feature is available in 10.7.0 (SaaS U14) / On-Prem 2022.4 Update 47.

 

What is changing

Suppressions 2.0 splits risk acceptance into two clear mechanisms:

 

1. Suppressions

A one-off, manual risk acceptance for a single image and a specific CVE (with optional resource details).

 

• Scope: Single image only.

• Effect: Immediate. Policy/assurance re-apply runs only for that image.

• Does not propagate to other images.

 

Best used for:

• Pipeline unblock (e.g., unblocking a CI/CD failure for a known risk).

• One-off image exceptions.

• Immediate scan/registry compliance updates.

 

2. Suppression Rules

Proactive, broad risk management across many images. Rules target one or multiple CVEs and apply across a defined scope.

 

• Scope: Application Scope, registries, repositories, image patterns, or multiple targets.

• Target: One or multiple CVEs (comma or space-separated).

• Application Scope selection is mandatory.

• Runtime (running workloads): Policy re-apply happens immediately.

• Scan/Registry/CI: Compliance state changes only after image rescan.

 

Best used for:

• Team-wide or organisation-wide suppression policies.

• Multi-registry or multi-environment deployments.

• Long-term suppression governance.

 

Resource flexibility

Both Suppressions and Suppression Rules support flexible resource matching. When suppressing a CVE, you can choose:

 

• Suppress for a specific resource version, path, and OS only.

• Suppress for all versions, paths, and OS variants of that resource.

 

This means a single suppression can cover the same CVE across different packages, paths, or builds without needing to be re-created each time.

 

Why this change is being made

The previous Acknowledgements workflow had several limitations that caused operational friction:

 

• Inconsistent behaviour across the image lifecycle (CI, Registry, Runtime) — suppressions applied in CI may not carry through to Registry or Runtime.

• Overly specific matching — acknowledgements were tied to OS, resource name/version, and file path. Small build or path changes could invalidate them, requiring repeated re-acknowledgement.

• No reliable link between CI and Registry — manual re-acknowledgement was common when the same image was scanned in different stages.

• Limited scope options — customers could not easily suppress across Application Scopes, multiple registries/repos, or future images.

• Operational impact — repeated acknowledgements, pipeline failures despite prior risk acceptance, and lower confidence in scan consistency.

 

Suppressions 2.0 addresses all of these by providing a deterministic, scope-driven model that persists across rescans and lifecycle stages.

 

Migration from Acknowledgements

Existing acknowledgements will be automatically migrated to the new model:

 

• Image-level acknowledgements → migrated as Suppressions.

• Repository-level and Global-level acknowledgements → migrated as Suppression Rules with Global Application Scope.

 

Important notes about migration:

 

• Migration runs as an automatic background job. No console downtime is required.

• Migrated rules are visible only to users with Global scope access. This may differ from pre-migration visibility expectations.

• No action is required to trigger migration — it happens automatically on upgrade.

 

How Suppression Rules apply

Runtime (running workloads):

 

• Policy re-apply happens immediately when a rule is created or updated.

• Runtime alerts and policy state reflect the rule right away.

 

Scan / Registry / CI:

 

• Compliance state changes only after image rescan.

• Existing images will not change state until rescanned.

 

If you need immediate compliance updates for specific images, use a Suppression (single image) rather than a Suppression Rule.

 

Application Scope and Suppression Rules

Application Scope selection is mandatory for Suppression Rules. Rules apply only within the selected scope, allowing organisations to:

 

• Isolate teams — each team manages suppressions within their own scope.

• Control visibility — rules are only visible to users with access to the relevant scope.

• Manage suppressions per application boundary.

 

If you modify an Application Scope that is used by Suppression Rules:

 

• Adding resources to the scope: Existing rules remain valid and now apply to additional images.

• Removing resources from the scope: If the rule's target (e.g., a specific repository) is no longer in the scope, the rule becomes invalid and is disabled. Existing suppressed CVEs remain suppressed, but on future rescans the suppression will be removed.

 

A warning dialog will appear when modifying an Application Scope that is in use by Suppression Rules.

 

CI/CD integration

The Images → CI/CD Scans tab will include a new column: Associated Registry. This shows:

 

• The linked registry for images scanned with --register --registry.

• A direct link to the Registry image in Images → General.

 

This clarifies the CI → Registry relationship and helps determine how suppressions propagate across lifecycle stages.

 

Legacy API support

Existing acknowledgement APIs remain supported during the initial rollout period:

 

• New acknowledgements created through legacy APIs are automatically translated into the new model (image-level → Suppression; repo/global → Suppression Rule).

• After the GA rollout period, legacy APIs will be deprecated. Advance notice will be given.

• Customers using automation or scripts that rely on acknowledgement APIs should plan to migrate to the new Suppression Rules APIs.

 

Prerequisites

All scanner instances must be upgraded before using this feature.

 

Because scan requests are distributed across available scanners, environments running a mix of upgraded and older scanner versions may experience inconsistent suppression behaviour. Older scanners do not support Suppressions 2.0 functionality.

 

To ensure consistent results, begin using the Suppressions feature only after all scanners have been upgraded to a supported version.

 

Frequently Asked Questions

Q: Will my existing acknowledgements be lost?

A: No. Existing acknowledgements are automatically migrated to the new model. Image-level acknowledgements become Suppressions; repository and global-level acknowledgements become Suppression Rules with Global scope.

 

Q: Do I need to do anything for the migration to happen?

A: No. Migration runs automatically as a background job on upgrade. No console downtime or manual steps are required.

 

Q: Why can I not see my migrated rules?

A: Migrated repository/global-level rules are created with Global Application Scope. Only users with Global scope access can view and manage them. Confirm scope access if rules are not visible.

 

Q: When do Suppression Rules take effect?

A: For running workloads (runtime): immediately. For scan/registry/CI compliance: after the next rescan. If you need immediate compliance updates for a specific image, use a Suppression instead of a Suppression Rule.

 

Q: What happens if I modify an Application Scope used by a Suppression Rule?

A: If you add resources, the rule applies to the additional images. If you remove resources that the rule targets, the rule becomes invalid and is disabled. A warning dialog will alert you before the change is saved.

 

Q: Can I still use the old acknowledgement APIs?

A: Yes, during the initial rollout period. Requests through legacy APIs are automatically translated into the new model. After GA, legacy APIs will be deprecated with advance notice. We recommend planning migration to the new Suppression Rules APIs.

 

Q: Do Suppressions propagate from CI to Registry?

A: Suppressions (single image) do not propagate. Suppression Rules propagate based on scope — if the CI image and Registry image fall within the same Application Scope, the rule applies to both.

 

Q: Can I suppress a CVE across all versions of a package?

A: Yes. When creating a Suppression or Suppression Rule, you can choose to suppress for all versions/paths/OS of the resource, rather than a specific version. This is supported through the flexible resource matching option.