This feature is not Generally Available yet. You can refer to this document only if your Aqua environment is enabled with the feature, Suppression of image vulnerabilities. If you are interested to experience this, please contact Aqua Support for enabling the feature.


Introduction

Aqua may detect security issues (vulnerabilities, malware, and/or sensitive data) during image scanning, and/or Image Assurance Policy violations during evaluation of image compliance.


If so, the Aqua UI will tell you precisely which security issues and policy violations were detected, and make it possible for you to take the required corrective actions as described here.


Note that an image might have security issues without being considered non-compliant. Consider the extreme case of an image with vulnerabilities, malware, and sensitive data. If none of your Image Assurance Policies are configured with controls that relate directly to such security issues, the image will not be considered non-compliant (unless it fails other controls). The controls related to vulnerabilities are CVEs Blocked, Vulnerability Severity, and Vulnerability Score. There are also controls for Malware and Sensitive Data.


Risk-based Insights

A valuable tool in reactive risk management is Risk-based Insights. This feature is designed to help you focus on the most important and urgent vulnerabilities to manage. The predefined risk categories are based on several factors, including the availability of exploits for the vulnerabilities found; the highest importance and urgency is assigned to such vulnerabilities that are already running as containers in your environment.


Risk-based Insights is a display mode of the Vulnerabilities screen.


Manage vulnerabilities

As mentioned in the Proactive Risk Management, you can create suppression rules to suppress the specific vulnerabilities automatically which meet your criteria and scope as soon as they are detected after scanning the images. Image scanning may reveal vulnerabilities in your images which were not suppressed through the suppression rules earlier.


The options for managing vulnerabilities are described in this topic. It is important to understand that:

  • Not all options may be available under all circumstances. For example, there may or may not be a fix for a given vulnerability.
  • The options are not listed in any order of desirability. Your best option (and second best, etc.) may depend on many aspects of your container development and deployment process. For example: You might deem it best to eliminate the vulnerability. If that is not possible, your best alternative might be to deploy the image as a container, protected with a Vulnerability Shield -- see below. However, since this could affect the functioning of the container, you might prefer to be extremely cautious, and block the image.


Eliminate the vulnerability by updating the resource in question

The Aqua UI will tell you if the vulnerability has been corrected in a later version of the affected resource. If so, rebuild your image with this version. Then re-scan the image to ensure there are no vulnerabilities remaining.


It goes without saying that this option will not always be available. So-called zero-day vulnerabilities can take a long time to discover, and an additional long time for the software vendor to make fixes available.


Apply a Vulnerability Shield™ (vShield) to the image

A Vulnerability Shield (vShield) prevents attackers from being able to exploit a specific vulnerability in all containers based on the image in question. Aqua Security Research employs technology to analyze vulnerabilities and, in many cases, generate vShields for images containing that vulnerability.


Aqua continually updates the CyberCenter as new vulnerabilities are discovered and new vShields are developed. The Aqua Server uses the information in the CyberCenter to inform you, in the Vulnerabilities screen, if a vShield is available for the vulnerability and container in question. You can then choose to apply the vShield from the same screen.


As such, applying a vShield can help you "buy time" until a real fix is made available (whereupon you should update the resource as soon as possible).


A vShield is implemented as an automatically generated Container Runtime Policy. The policy contains the actions and controls required to block execution of non-secure runtime actions resulting from the vulnerability. The scope of the policy is restricted to the containers whose base image is the one in which the vulnerability was discovered.


As with any Container Runtime Policy, you can view the contents of a vShield. However, you can only:

  • Set or change its Enforcement mode (to either Audit or Enforce)
  • If the policy is set to Audit: an automatic transition to Enforce mode if [N] days have passed without the policy generating any audit events
  • Delete the vShield policy


Suppress or Unsuppress the vulnerability

You can suppress a given vulnerability for a specific image only. When you do so, you tell Aqua not to fail any Image Assurance Policies, for that image, that would be failed by that vulnerability. In other words, you believe that deploying containers based on the image in question will not cause unacceptable security risks due to that vulnerability.


You can optionally set an expiration period (between 1 and 999 days) for the suppression. This can give you a "grace period" for deploying containers based on the image with the vulnerability.


At any later time, you can unsuppress (cancel the suppression of) the vulnerability or change or cancel its expiration period.


See Apply and Manage Security Issue Manual Suppressions for details.


Allow the image

While similar to suppression, allowing an image has broader applicability: it applies to all security issues that may be present in the image, not only to a single vulnerability.


You can allow one or more images while in the Images section of the UI. When you do so, Aqua will allow deployment of the image in containers, irrespective of the image's compliance status. Allowing an image does not actually change its compliance status; it can tell Aqua to ignore non-compliance for the purposes of image deployment.


You should allow an image only if you believe that running the image in containers will not cause unacceptable security risks.


See Allow image(s) for details.


Block the image

This is the opposite of allowing an image. When you block an image, Aqua will block deployment of the image in containers, irrespective of the image's compliance status. Blocking an image does not actually change its compliance status; it can tell Aqua to ignore compliance for the purposes of image deployment.


See Block image(s) for details.


Assign custom severities for selected vulnerabilities

From the security perspective of your organization, a given vulnerability might be either less or more severe than the Aqua-assigned severity. See Custom Vulnerability Severity for details.


Eliminate your need for the resource in question

Re-evaluate your usage of the resource with the vulnerability. If you don't really need it, remove or replace it.


Manage malware

If scanning reveals malware in your image, and it was found in your own code, then you should first attempt to clean your code; then re-scan the image. Your other options are the following (as described above):


Manage sensitive data

Your options are the same as for managing malware. If scanning reveals sensitive data in your image, and it was found in your own code, then you should first attempt to clean your code; then re-scan the image. Your other options are the following (as described above):


Manage Image Assurance Policy violations

An Image Assurance Policy is violated when an image fails one or more of the controls you have configured. Aqua will show you which control(s) your image has failed and suggest specific fixes when possible.