In this lesson we learn about Snyk AppRisk Essentials, however if you have purchased Snyk AppRisk Pro, you may be taking this lesson as the starter lesson to learn the base platform. Many other modules are available under the AppRisk tag in Snyk Learn! See Snyk Learn's Snyk AppRisk content for more learning content for these features.

Snyk AppRisk Essentials capabilities, available as part of the Snyk Enterprise plan, allow organizations to

• Discover applications, getting visibility into your organization's application landscape
• Manage security coverage, validating that Snyk controls are applied consistently and where required
• Prioritize with issue level risk scoring

The following video provides a high-level overview of Snyk AppRisk's core capabilities and the problems it solves for. Note, some of the functionality outlined in the video is only available in Snyk AppRisk Pro.

Video: 3m30s

• A current Snyk Enterprise customer
• Purchased Snyk AppRisk Essentials
• You are a Group Administrator for the Group associated with Snyk AppRisk.
  • If you are utilizing group-level custom roles, the appropriate Snyk AppRisk role, "Access AppRisk", would need to be assigned
  • A read-only permission is available for Snyk AppRisk. See Documentation for more information
• The Group, with Snyk AppRisk enabled, includes organizations that have been onboarded with Snyk application security products.
• You have the necessary permissions and authority to integrate cloud-based source code management (SCM) tools (Azure DevOps, GitHub, GitLab, and so on) to Snyk AppRisk for repository asset discovery.

• Asset: An asset is an identifiable entity that is part of an application, and relevant for security and developers.

• Class: A way to assign business context to assets and categorize an asset based on its business criticality. Class can be used in policies as well as defined in a policy. Assets can be assigned classes A, B, C, or D, where

  • Class A - assets that are business critical, deal with sensitive data, subject to compliance, and so on, are the most important.
  • Class D - test apps, sandbox environments, and so on, are the least important.
  • Assets are assigned Class C by default.

• Controls: The security controls associated with the asset, such as Snyk Open Source or Snyk Code.

• Coverage: An assessment of whether applicable assets are scanned and tested by security controls, such as Snyk Open Source, as it relates to an application security program. A type of policy that allows you to specify what controls should be applied and, optionally, how often it needs to be run.

• Coverage Gap: the asset does not meet the coverage requirements as set by the "set coverage control policy" action.

  • Note that 'Coverage Gap' is not the opposite of "Coverage': an asset may be 'covered' (was scanned a month ago) and still has a coverage gap (if the requirement is a daily scan)

• Policy: A way to automate actions in certain conditions, like classifying and tagging assets with business context. You can also use a policy to configure actions like sending a message or setting the coverage gap control using a Policy builder UI.

• Tags: A way to categorize assets. Helps you recognize or handle assets differently according to mutual properties. Assets can be filtered by their tags in the inventory or when creating policy rules. A tag can be automatically assigned to an asset, or the asset can be tagged by a policy you created. GitHub and GitLab topics are treated as asset tags and you can use them for creating policies.

After setting up the Snyk Platform with applications being monitored via the web interface or via CLI monitoring/reporting, the next step is to navigate to the group, then open and configure Snyk AppRisk integrations screen.

Note that Insights and Tenant->Analytics->Applications are Snyk AppRisk Pro Features.

Video: 0m 45s

To configure Snyk AppRisk Essentials, navigate to the Group level, and click the Integrations menu on the left.

Preconfigured Integrations

• Snyk will automatically begin detecting assets and cataloging them.
• Clicking Integration Hub provides access to specify which repositories to integrate into.

Integrating Code Repositories

• Click Integration Hub, and choose the code repository to integrate into, providing the data each field requires.

Application Context with Backstage and CMDB

• Snyk can consume Backstage files and utilize key fields for searching, setting policies, and providing application context.
• Enable Backstage in the Git integration settings, if you have your supported file, for example catalog-info.yaml, in the root.
• Change the field values if you are using alternate names or you wish alternate values to be displayed in Snyk.
• To see how these fields are used, fast forward in the course to the related Backstage sections in Policy and Inventory sections below.

Private Code Repositories

• For Brokered Integrations, follow the steps described here to enable Snyk AppRisk on the broker

Important Considerations

An important note about integrating Git code repositories with Snyk AppRisk is that a secondary token should be used with a broad/complete view of the code repository, not just what's been imported into Snyk. This provides a counterview to what's been onboarded via Snyk and reduces the likelihood of a blindspot being introduced by using a limited token at the organization level configuration. It's not uncommon at the organization level to only provide a token that has access to the applications that that organization owns.

Plan on your first import/sync taking up to 24 hours to complete.

Last Sync/Next Sync

Updates to your controls and assets are analyzed on a schedule. You can determine the last/next run by observing the "Last Sync" and "Next Sync" on each integration.

Video: 4m 19s

Tip: The Inventory by Type, where Type=Repository, is a valuable place to start when reviewing discovery in Snyk AppRisk. Additionally filtering by team or technology type can be valuable when reviewing results. The following video demonstrates how to view your Asset Inventory from within Snyk, and then learn some common filtering examples on this page.

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: 7m53s

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).

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 AppRisk, 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.

The following features have been added since the initial recording:

• 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 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

To create a policy, click Policy on the left hand menu,then select the Asset tab at the top.

Policies generally fall under four categories

• Sending a notification via Email or Slack
• Setting a tag that assists with filtering or defining policies
• Setting a classification, indicating the importance of an application
• Setting a coverage policy to determine what controls are run and, optionally, frequency they must be run

You can find common policy examples and suggested settings in the documentation for AppRisk policies.

• Click into each item listed for more information on the relevant usecase

The following videos provide examples and tips for creating policies.

• Policy overview (3m16s)

• Policy editor (3m51s)

• Policy editor - and,or filters (2min) . Please note that the "Name" field is now referred to as "Asset Name" in the filter selector.

• Policy editor - Coverage policy example (2m5s)

• Policy templates - created by Snyk for common policies and best practices. Learn how to use a policy template (1m26s)

• When creating policies checking for the use of Snyk Code or Snyk Open Source, be clear on the use case. Is it:
  • Coverage you are typically looking if all tools are in use
  • Coverage gaps are typically where one or more are not in use
• Don't forget to filter by asset-type=repository in most cases. If you're using OR's in your rules you may need to create a higher level block to nest a rule with an OR in it.
• Repository Name is using the Asset Name option when selecting "Contains" or "Not Contains"
• The URL for a repository is identified by the Attribute when asset-type=repository
• The default rescan for Snyk Open Source is one day, whereas Snyk Code is one week, and will rescan on merging pullrequest/mergerequest provided the webhook for the associated PR check is present. This potentially necessitates two policies being created for coverage.

See documentation for common implementation examples of policies

The Asset Dashboard, found on the Group level main menu, provides an overall view of your coverage and provides quick access to where gaps may reside.

Important Considerations

The configuration options for SAST and SCA effectively "or" the controls, such that a repository is considered covered under these conditions

• For SAST: Snyk Code or Snyk Infrastructure as Snyk Code is configured
• For SCA: Snyk Open Source or Snyk Container is configured

You can configure the definition to be more strict, such that SAST is Snyk Code only, or SCA is Snyk Open Source, as desired.

Video: 3m 41s