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:

  1. 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.
  2. 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


Controls

You can include the following controls in Assurance Policies:


ControlDescription
Dependency NameFails 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.
IaC Misconfigurations by ServiceFails the policy if any check for the selected provider and service in the control does not pass.

Example: AWS : S3
IaC Misconfigurations SeverityFails 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
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 SeverityFails 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
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 ProtectionThis 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 ChecksThis 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
Sensitive Data SeverityFails 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
Specific IaC MisconfigurationYou can select one or multiple checks for misconfigurations for each provider and service combination (e.g. S3 in AWS). You can add multiple combinations of provider, service, and checks in the control.

Example: AWS : S3 : S3 data should be versioned

This control fails the policy if the selected checks do not pass.
Specific Pipeline Misconfiguration CheckYou 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.
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
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
Specific VulnerabilityYou 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.
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 SeverityFails 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



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.