Create policies

Snyk AppRisk includes a powerful policy editor for creating and modifying policies.

There are two steps to building policies:

1. Define filters - Set filter conditions on asset properties.

2. Set actions - Define actions to be taken on filtered assets.

New policy

You can create a new policy using the Start from scratch option or choose one of the available policy templates using the Use a template option.

Start from scratch - policy creation

To create a new policy, you have to click the New Policy option from the Policies/Assets view and select the Start from scratch option.

You must name your policy and, optionally, provide a description of the policy. After you complete these steps you have to define the filters and set the actions of your policy.

Use a template - policy creation

You can create a new policy by using one of the available templates. To select one of the policy templates, you have to click the New Policy option from the Policies/Assets view and select the Use a template option. You can select one of the templates from the templates library by clicking the Use template button from the policy template card.

Each policy template has a name, a description, and displays the graphic connections between filters and actions.

The following video explains how to use a policy template from the Policies view:

You can customize the filters and actions or use the template as is. After finishing all the template changes, click the Save button to create the new policy.

Define Filters

Release status Risk factors on assets, Runtime discovered and Runtime last seen filters are currently in Closed Beta and available only with Snyk AppRisk Pro.

Each filter component requires you to specify an asset property. Available properties for asset policies include:

• Application* - the list of the applications for which you have configured the application context (Backstage catalog or ServiceNow CMDB) in Snyk AppRisk.

• Asset ID - the unique identifier of the asset.

• Asset name - the name of the asset.

• Asset type - repository, package or scanned artifact.

• Attribute - asset attributes retrieved from the data source.

• Catalog name* - the name of your application context.

• Category* - the category of a repository asset. For example, service or library.

• Class - specify the class of the asset.

• Coverage - specify the product or products used to scan the asset. The Coverage filter identifies if at least one scan has been run by the specified product.

• Coverage gap - specify the products for which the asset has not been scanned and do not meet the Set Coverage Control Policy requirements. The coverage gap applies only if you previously defined the coverage requirements of an asset and the asset has never been scanned, or the last scan is older than the default scanning frequency.

• Developers - specify the developer or developers who contributed to the asset.

• Discovered - specify the period when the asset was discovered.

• Issue severity - specify the severity of the issue: critical, high, medium, low.

• Issue source - specify where the issue was identified: SCM or third-party integrations. A source category will only be visible if there is at least one source present.

• Last seen - specify the repository freshness status.

• Lifecycle* - represents the lifecycle state of the application context component, for example production, experimental, deprecated.

• Locked attributes - specify if the attribute value is locked.

• Owner* - represents the team owning the repository for which the application context was configured.

• Risk factors - specify the risk factors from Insights that indicate potential elevated risk, based on data from runtime. This is only available for Snyk AppRisk Pro customers.

• Runtime discovered - specify the period when the runtime image asset was discovered.

• Runtime last seen - specify the freshness status for the runtime image asset.

• SCM Repository freshness - the status of the repository and the date of the last commit.

  • Active: Had commits in the last 3 months.

  • Inactive: The last commits were made in the last 3 - 6 months.

  • Dormant: No commits in the last 6 months.

• Source - specify the asset source.

• Tags - information about the detected languages and repository update status.

• Title* - represents the name of the component for which the application context was configured.

*All filters marked with * are visible only to the users who configured the application context for their SCM integrations.

Coverage and Coverage gap filter differences

• Use the Coverage filter to identify the assets scanned by the products at least once.

• Use the Coverage gap filter for assets that do not meet the requirements defined in the Set coverage control policy.

The Coverage gap filter identifies assets that fall 'out of policy' and do not satisfy the coverage criteria you have specified, due to infrequent scanning or no scanning at all. On the other hand, the Coverage filter allows you to locate assets that have or have not been scanned, irrespective of any coverage requirements.

The following video explains how to create a new policy:

Each property contains different options for conditions and values:

Property	Conditions Values	Values
Application*	Is one of Is not one of	all available applications for which you have configured the application context in Snyk AppRisk.
Asset ID	is is not contains does not contain starts with ends with	[string]
Asset name	is is not contains does not contain starts with ends with	[string]
Asset type	Is one of Is not one of	Package Repository Scanned artifact
Attribute	is is not contains does not contain starts with ends with	[string]
Catalog name*	Is one of Is not one of	the list of names of your application context.
Category	Is one of Is not one of	the list of the available categories of a repository asset
Class	Is one of Is not one of	A, B, C, D
Coverage	containing one or more of containing all of not containing one or more of not containing all of	Snyk Code, Container, IaC, Open Source
Coverage gap	containing one or more of containing all of not containing one or more of not containing all of	Snyk Code, Container, IaC, Open Source
Developers	is is not contains does not contain starts with ends with	[string]
Discovered	Is within Is not within	Last 24 hours Last 7 days Last 30 days Last 12 months Year to date
Issue severity	containing one or more of containing all of not containing one or more of not containing all of	Critical High Medium Low
Issue source	containing one or more of containing all of not containing one or more of not containing all of	Snyk Code, Container, IaC, Open Source, Nightfall
Last seen	Is within Is not within	Last 24 hours Last 7 days Last 30 days Last 12 months Year to date
Lifecycle*	Is one of Is not one of	the available list of the lifecycle states of the application context component
Locked attributes	is one of is not one of	Class
Owner*	is one of is not one of	the list of teams owning the repository for which the application context was configured.
Risk factors	containing one or more of containing all of not containing one or more of not containing all of	the list of available risk factors
Runtime discovered	Is within Is not within	Last 24 hours Last 7 days Last 30 days Last 12 months Year to date
Runtime last seen	Is within Is not within	Last 24 hours Last 7 days Last 30 days Last 12 months Year to date
SCM Repository freshness	is one of is not one of	Active Inactive Dormant
Source	is one of is not one of	azure-devops GitHub GitLab Snyk
Tags	containing one or more of containing all of not containing one or more of not containing all of	all available tags you previously created
Title*	is one of is not one of	the list with all the names of the component for which the application context was configured

*All filters marked with * are visible only to the users who configured the application context for their SCM integrations.

You can specify more than one filter component with an And or Or operator.

The following video explains the use of filters and the use of the And, Or operator.

Set actions

After defining filter components, you need to define the actions that the policy has to perform on the filtered assets. Asset policies support the following actions:

• Send Email - Receive an email every time there are asset updates. You can choose between daily emails or scheduling the checks. You can include a link to the relevant assets. Each notification lists all impacted assets. You can view them individually or see the aggregated view by clicking Click Here. The list of assets displayed in the email notification is automatically generated.

• Send Slack Message - Receive a Slack notification every time there are asset updates. You need to add your Slack webhook URL, then you can choose between daily emails or scheduling the checks. You can include a link to the relevant assets. Each notification lists all impacted assets. You can view them individually or see the aggregated view by clicking Click Here. The list of assets displayed in the email notification is automatically generated.

• Set Asset Class - Sets the class on the matched assets. Removing the policy or turning in off does not retroactively change the asset class back to default.

• Set Asset Tag - Sets a tag on the matched assets. Removing the policy or turning in off will remove the tags of this policy from the relevant assets.

• Set Coverage Control Policy - Sets a control on filtered assets that checks whether selected security products are scanning assets, optionally within a given timeframe. Assets that fail this control will be marked accordingly on inventory pages. This control applies the OR logic across products.

• Set Jira policy - Automate the creation and management of Jira tickets based on specific conditions related to your assets. You can create new Jira tickets for new matches that meet the policy criteria, modify existing Jira tickets if the policy conditions change, set classifications and tags on assets using the policy, or notify users using Slack or email when a condition is met.

The editor supports multiple flows for the same policy. The flows can be independent or intersect.