• Browse topics
Login
Sign up
Login

SNYK LEARN LOGIN

OTHER REGIONS

For Snyk Enterprise customers with regional contracts. More info

Sign up

Snyk AppRisk Essentials

Training

Introduction

Snyk AppRisk Essentials allows organizations to

  • Discover your applications, getting visibility into your organization's application landscape
  • Manage security coverage, validating that controls are applied consistently and where required
  • Prioritize based on risk, focusing remediation efforts where it matters most

The following video discusses what is application security posture management (ASPM) and Snyk's capabilities with Snyk AppRisk Essentials.

Video: 3m12s

Requirements

  • A current Snyk Enterprise customer
  • Purchased AppRisk Essentials
  • You are a Group Administrator for the Group associated with Snyk AppRisk.
    • If you are utilizing group-level custom roles, the appropriate AppRisk role, "Access AppRisk", would need to be assigned
    • A read-only permission is available for 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.

Terminology

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

Navigating to the Snyk AppRisk Essentials interfaces

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.

Video: 0m 45s

Configure integrations

To configure Snyk AppRisk Essentials, navigate to, 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.

Backstage

  • Snyk can consume Backstage files and utilize key fields for searching, setting policies, and providing application context.
  • Enable Backstage 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 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

Scan your code & stay secure with Snyk - for FREE!

Did you know you can use Snyk for free to verify that your code
doesn't include this or other vulnerabilities?

Scan your code

Review Inventory

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.

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 ran, use a coverage filter either instead or as an "or" to this coverage gap filter

apprisk policies - 1 - coverage gap

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 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 apprisk policies - 2 - coverage missing

Example 3: Find all repositories that have coverage of the specified tools (the positive case) apprisk policies - 3 - coverage gap example1

apprisk policies - 3 - coverage gap example2

Example 4: Find repositories of a particular class. AppRisk - Example filtering

Example 5: Find repositories where the code repository topic contains "payment" AppRisk - tag example

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

AppRisk - Inventory - filter by application

AppRisk - Inventory - Catalog Name

Additional columns added

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

Create policies

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)

Additional Tips

  • 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

Dashboard

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

Insights

Insights, accessible from the Group or Organization level of the main menu, helps solve several questions asked when shifting security left as part of the development process:

  • What to fix , where to fix, or where it came from?
  • What issues have the highest risk and are in applications that are actually deployed?
  • Is the application publicly accessible or is it an issue in the operating system you're running it on?

Requirements

  • Snyk Enterprise customer with Snyk AppRisk Pro
  • Group Viewer Role for Group Level Access to Insights
  • Org Collaborator Role to access from the Org Level
    • Evidence graphs are only available when Insights is accessed from the Group level menu and have Group Viewer role
  • Insights Connector for Kubernetes.
  • Scanning your images with Snyk Container
  • Tags set in Snyk with the appropriate format on related elements like the open source, code, and container projects.
Info

Tagging Format

The tag will be in the form of component=pkg:__location__@__branch__ where __Location__ is the repository location i.e. github, specific to the project you are testing and the __Branch__ specific to the project you are testing.

Example: component=pkg:github/my-org/repo-a@main

For more information on tagging, see:

Filter Definitions

  • Open issues - a count of all open source, code, container issues identified by Snyk
  • OS Condition - a count of all open source, code, container issues identified by Snyk that apply to the operating system
  • OS Condition & Deployed - a count of all open source, code, container issues identified by Snyk that apply to the operating system and that are associated with a deployed container
  • OS Condition, Deployed & Public facing - a count of all open source, code, container issues identified by Snyk that apply to the operating system, are associated with a deployed container, and have a configured path to the internet

Important Considerations

The following videos discuss key considerations and initial workflows for setting up and using Insights:

Getting Started with Insights (2m21s)

Using Insights (6m06s)