Reviewing Inventory for asset management and discovery with Snyk Essentials and Snyk AppRisk

The All Assets view categorizes the type of asset, such as containers or repositories, and helps to logically organize filter results along those lines.

The Teams and Technology views are derived from the code repository.

The Asset Hierarchy view, displays the relationshop between assets. In the case of Repositories, you will see the related Packages. In Snyk Essentials/Snyk AppRisk, Packages are defined as software or libraries that are managed by package managers. Package assets are created when you scan the dependencies of a Project through code repository systems or by using the Snyk CLI. For example, the package.json or pom.xml that might be found in a scan is a Package asset.

Types of Assets

1. Repository assets: Repository assets represent SCM repositories. A repository asset is created by discovering the repositories directly in the source code management (SCM) system, provided the integration is configured. Alternatively, a repository asset can also be created by scanning a repository using Snyk or third-party tools, as long as the scanned code is associated with a specific repository. In Snyk, this can be achieved by entering the gitRemoteURL parameter.
2. Packages: software or libraries that are managed by package management systems. When you scan the dependencies of a Project through package management systems or the Snyk CLI, Snyk creates Package assets. This allows Snyk AppRisk to analyze the security vulnerabilities of the packages used in the Project. By doing so, it can identify possible risk exposures and provide recommendations for mitigation.
3. Container images: Software packages called container images are designed to be self-contained and able to run consistently in any environment. These images consist of the code, libraries, dependencies, and system tools necessary for an application. The lightweight containers created from these images are portable and provide a consistent runtime environment across different development, testing, and production setups. You can identify a container image based on the Image ID. If multiple container images share the same Image ID, a single image asset is generated with information from all the identified container images.
4. Scanned artifacts - entities detected by Snyk that cannot be identified as repository assets because they lack any identifying information, such as a Git remote URL. While scanned artifacts provide visibility into what Snyk AppRisk detects from scans, they may require additional troubleshooting. You can see the scanned artifacts in the Inventory Type view, but Policies do not support them. Due to missing identifying information, scanned artifacts may include duplicates.

Video: 11m 39s

When clicking the Filter button in Inventory, a selection of predefined filters are available. Once selected the values can be modified.

In order to make use of these quickfilters, which consist of some of the most common filters customers utilize, it's strongly suggested you have the direct code repository integrations configured at the group level and have coverage policies defined, otherwise if you're still early in your implementation or seeing no results, manually select the filters that fit your search (as shown in coverage examples later in this module).

Snyk Enterprise Plan - Snyk Essentials filters

Snyk AppRisk Filters

With the purchase of Snyk AppRisk, comes the availability of runtime risk factor and other filterable metadata fields (Runtime last seen, Runtime discovered, etc).

Examples of such filters might consist of customers of Snyk Essentials, which comes with the Snyk Enterprise plan, specifying filters for active repositories but missing coverage, as defined by policy.

Another example is where a Snyk AppRisk customer may want to focus on applications that are Public Facing and Deployed if runtime features have been configured. Quickfilter criteria may vary over time and by Snyk plan.

Coverage vs Coverage Gap

Essentially, the Coverage filter helps you find assets that have/haven't been scanned, regardless of any coverage requirements. The Coverage Gap filter helps you find assets that are 'out of policy' and don't meet the coverage requirements you defined (whether not scanned frequently enough or at all).

The following presentation will provide glimpses of how policies are created for Coverage Gap, however the dedicated lesson on policies, found on Snyk Learn, will provide much more robust training on policy creation.

Video - 5m 27s

Examples

The following examples are performed from the Repository view of inventory.

Example 1: Find any repository where Snyk Open Source or Snyk Code on those assets are out of policy, because it has not run in specified timeframe. Note that in this scenario only Snyk Code and Snyk Open Source appear in the list because only those coverage policies have been created in that environment.

To find assets that have never had a scan run, you could alter it in one of two ways:

a) Change the policy such that the policy consists of a single rule, where you use "coverage" instead of "coverage gap" filter, where it does not contain Snyk Open Source or Snyk Code.

b) Take the example screenshot and add an "or" to combine it with suggestion "a"

An extension of this would be if you had policies defined for all of your Snyk Products, you could specify all products in your filter and essentially say "find anything that's out of policy"

Example 2: When you first onboard with Snyk Essentials, you may not have created any coverage policies. The following example is a simple way to get a list of repositories where a scan of the specified type is not present for the repository

Example 3: Find all repositories that have coverage of the specified tools (the positive case)

Example 4: Find repositories of a particular class.

Example 5: Find repositories where the code repository topic contains "payment"

Example 6: Utilize Application and other Backstage related fields context from Backstage to view related assets.

Repository freshness

• An active repository is where commits have been made in the last 3 months.
• Inactive repository: Last commits were in between the last 3 to 6 months.
• Dormant repository: No commits in the last 6 months.
• Blank indicates that it was detected via Snyk and not the SCM integration

Asset Source

Asset source which indicates the data source of the asset.

• A repository asset can be from only Snyk, Snyk and a SCM tool, or only a given SCM tool
• A scanned artifact is going to have a single source, likely Snyk
• A package currently has a single source, Snyk
• Containers may be detected via Snyk scan , or with Snyk AppRisk, via runtime integration.

The Policy editor allows for powerful creation of rules that are trigger based on specified criteria. For example, you could indicate you want to send a slack message for any detected Snyk Code coverage gaps detected. While the rule is created in the policy editor, the Inventory is a useful place to tryout filter creation and see what would cause a particular rule to trigger.