TABLE OF CONTENTS

Overview

Assurance Policies apply to the code repositories which meet the defined scope. They include controls that are evaluated on the results of code repository scans. After Assurance Policies are applied to the code repositories, Aqua determines whether a repository is compliant with the applicable Assurance Policies.

This article explains the components in the Assurance Policies, and how to use the Aqua UI to create and manage them.

Assurance Policy components

An Assurance Policy consists of:

Scope: defines set(s) of code repositories to which the policy will be applied, by selecting resource type, property, and value
Controls: individual tests that are evaluated on the results of a scan as part of Assurance Policy
Action: select either Audit or Enforce to fail the PRs or builds respectively if the code repository used for the PRs or builds is not compliant with Assurance Policy. Aqua will always log an audit event if the code repository is not compliant with the policy.

Scope

Scope imposes restrictions on the code repositories, the Assurance Policy applies to. You can optionally configure a policy with a scope (for that policy only). Their purpose is to further limit the set of code repositories the policy applies to. (They might have no effect, but they cannot broaden the set of repositories.)

For example: An Assurance Policy might restrict policy compliance evaluation to the specific repositories or branches matching with the name given.

The scope definition includes the following components:

One or more terms. Each term consists of a resource type, a property, and its value (in a few cases, two values must be specified).
The available resource types and properties in each resource type are explained in the Specific Scope Definition below.
Values cannot contain embedded spaces. If you do not know the exact value name, you can enter a few letters in the value so that all the values that match the combination of letters are added to the scope.
The operator AND is applied between multiple scope terms automatically.

To define scope criteria when configuring an Assurance Policy:

In the "Scope" section, define a scope term by using the drop-down lists, and the text boxes to enter the related value(s). Refer to the Specific Scope Definition below for all the available resource types and properties.
Click Add to add multiple scope terms.

When you add each scope term, it will be added to the box shown under the scope selection. You can add multiple scope terms; operator AND will be applied between them by default. You can also see the complete scope definition in the syntax view by clicking the </> icon in the box shown under the scope selection.

Specific scope definition

The scope of an Assurance Policy can include the following properties against the resource type:

Resource: Repository
Property: Branch, Name, Organization, Provider Type, Topic

If you select "Branch" for property in the scope definition, you should enter either the branch name or glob pattern in the value field whereas if you select any property other than "Branch", you can select property value from the dropdown menu.

Controls

You can include the following controls in Assurance Policies:

Control	Description
Dependency Name	Fails the policy if the code repositories contain any of the dependencies added in this control. You should enter the exact dependency name or specific keywords to see all the dependencies matching the text with different versions in the dropdown menu. The dependencies which are displayed in the dropdown menu were used in one of the code repositories added to Aqua. Select the required dependency with version that you want to add to the control. Example: "graphql-relay@2.0.1" Notes: You can also add a dependency name without version as a keyword to the control to consider adding all the dependencies matching the text. Make sure that you use proper casing (upper or lower case) of the letters in the keyword to add correct dependency to the control. In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
IaC Misconfigurations by Service	Fails the policy if any check for the selected provider and service in the control does not pass. Example: AWS : S3 In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
IaC Misconfigurations Severity	Fails the policy if the severity of the detected misconfigurations is greater or equal to the selected value in this control. Example: Low, Medium, High, or Critical In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Pipeline Container Activity	Add the image name patterns in this control by referring customized Golang regular expressions. This control fails the policy if the build pipeline file configuration includes the image names which match the pattern added in this control.
Pipeline File Changes Activity	Select file change type: Added, Deleted, or Modified and enter file path pattern. This control will fail the policy if there are any file changes observed in the code repository associated with the pipeline.
Pipeline Misconfiguration Severity	Fails the policy if the severity of the detected misconfiguration in the pipelines is greater or equal to the selected value in this control. Example: Low, Medium, High, or Critical In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Pipeline Network Call Port Activity	Fails the policy if build pipeline configurations include network call ports entered in this control, e.g., 8080, 4646, 1313.
Pipeline Network Call URL Activity	Add the network call URL or IP address patterns in this control by referring customized Golang regular expressions. This control fails the policy if build pipeline configurations include any network call URLs or IP addresses added in this control.
Release Artifact Code Protection	This control checks whether the process of creating the latest version of release artifact followed the best practices. Select the following best practices to apply this control: Branch is protected: to check whether the branch used to create the latest version of release artifact is protected against security issues Multi-factor auth: to check whether multi-factor authentication is deployed, for the users to access the organization in which the release artifact is created Submitted as PR: to check whether code changes to the release artifact submitted through a pull request or merged directly Two min reviewers: to check whether the pull request used to deploy the code changes to the release artifact approved by a minimum of two reviewers
Release Artifact Security Checks	This control checks whether any scanner is used to detect the following security issues: Sensitive Data Misconfigurations Vulnerabilities SAST Scanning
SAST Severity	Fails the policy if the severity of the security issue detected by any SAST check is greater or equal to the selected value in this control. Example: Low, Medium, High, or Critical In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Sensitive Data Severity	Fails the policy if the severity of the detected instances of sensitive data is greater or equal to the selected value in this control. Example: Low, Medium, High, or Critical In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Specific IaC Misconfiguration	This control fails the policy and blocks the build if one of the selected checks find any IaC misconfigurations in the code repositories. You can configure this control using one of these options: Select any IaC misconfiguration check: Select one or multiple IaC misconfiguration checks for each provider and service combination (e.g. S3 in AWS). After selecting the checks, click Add. Example: "AWS > S3 > S3 data should be versioned". Add Specific AVD ID: Add one or multiple Aqua Check IDs (AVD ID) of the IaC misconfigurations in the text box one at a time. After entering each check ID, click Add. You can obtain check ID for any IaC misconfiguration in the Risks > IaC Misconfigurations tab. Example: "AVD-AWS-0080: RDS encryption has not been enabled at a DB Instance level". Click x to remove any added checks from the control. In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Specific Pipeline Misconfiguration Check	You can select one or multiple checks for misconfigurations in the pipelines. Example: Using Eval command This control fails the policy if the selected checks do not pass on the code repositories. In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Specific SAST Check	You can select one or multiple SAST checks for a specific programming language. This control fails the policy if the selected SAST checks do not pass on the code repositories. Example: Java : No null Cipher In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Specific Sensitive Data Check	Fails the policy if one or more of the selected sensitive data checks are detected in the code repositories. Example: Code Generic Credential In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Specific Vulnerability	You can add one or multiple vulnerabilities in the text box. Example: CVE-2022-1234 This control fails the policy if the applied code repositories have any of the vulnerabilities entered in this control. In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.
Suspicious Behavior in Pipelines	You can select one or multiple checks for suspicious behaviors in the pipelines. Example: Crypto Mining Detected This control fails the policy if the selected checks do not pass on the pipelines.
Suspicious Behavior in Pipelines by Severity	Fails the policy if the severity of the detected suspicious behavior findings in the pipelines is greater or equal to the selected value in this control. Example: Low, Medium, High, or Critical
Vulnerability Severity	Fails the policy if the severity of the detected vulnerabilities is greater or equal to the selected value in this control. There is another checkbox to apply the policy for vulnerabilities with a known vendor fix. Example: Low, Medium, High, or Critical In the optional file path field, you can enter a glob pattern for specific files and directories to selectively apply the control.

Operations on Assurance Policies

Refer to Operations on Assurance Policies for more information on different operations such as how to create, modify, delete Policies, and so on.

Welcome to Support Portal