Skip to content

Scan Results

View Snyk Scan Results

Once you have imported a project, it will be scanned. Learn how to view the scan results here.

Interpreting and Prioritizing Snyk Findings

Tip

Addressing all issues in Snyk will make prioritization a breeze. The recommendation is thus to either fix all issues or ignoring them - for a period of time or permanently - to show that the they have been evalutated and addressed.

The Snyk Priority Score is a good reference when prioritizing Snyk findings, and should be taken into consideration. Be mindful that Snyk reports on potential vulnerabilities, so you will still need to investigate if the reported issue is a true positive or not.

For issues with a fix available, you can trigger Snyk to create a pull-request which addresses the issue. The fix usually involves upgrading the dependency to a vulnerability free version or with a patch. This upgrade might break the code and Snyk will indicate this in the pull-request created. The reviewer is responsible to ensure that the changes in the PR won't cause issues with the project.

In most languages, a minor (1.1.x → 1.2.x) or patch (1.1.1 → 1.1.2) release is considered “non-breaking”. Whilst a major version (1.x.x → 2.x.x) contains breaking changes.

For issues with no fix available it is up to the developers to evaluate how to handle this - whether it be explicitly ignoring the issue until a fix is available, replacing the dependency, or removing the dependency all together as you discover it is not really needed. An important thing here is that an action has been taken and that the issue does not remain "unhandled".

On a side-note:
It is a good practice to define Security Requirements for your applications. In the context of adopting Snyk, it makes a lot of sense to add a requirement covering the how long exposure window is tolerated for your application.

Ex.

The remediation time of newly discovered vulnerabilities for our application will take no longer than:
Critical: < 7 days
High: < 30 days
Medium-Low: Resolve based on availability

Notifications

Set up notifications in Snyk so that you/the team gets notified when new issues are detected, eliminating the need to frequently do a manual check in the portal.

For more information, see Snyk's documentation

Interpreting Issues regarding Licenses

Intro

Disabled by default

To enable the rule-set that alerts on potential issues, add the "Distributed" environment-tag in your projects. If you cant see 'Distributed' in the list, try searching for it

Open source software you use in your projects (eg. libraries) are licensed by the author(s) to ensure that it is used the way the author attended. There are many different licenses out there. Some of them are created to ensure the freedom of use without asking anything in return. Others may require that projects using the licensed software adopt the same license and make their software open and free.

Information on why/how Snyk reports on License-issues

The subject of license-issues is most relevant for Equinor's Open Source Software projects, as obligations to comply is usually triggered by distribution.

From the OSLC-handbook:

Distribution is defined as:
providing software to another entity, i.e., an individual or organization outside your company or organization.

Determining the requirements that need to be met to comply with open source licenses involves the following:

  1. You must know what open source software you are using;
  2. You must know what license applies to that open source software and the relevant legal interpretation of the license; and
  3. You must know how you using that open source software.

What to do

We recommend that all teams, regardless of whether they are distributing their solutions or not, acquire a working knowledge of the subject of Open Source Licenses.

You should act when Snyk report on license issues. This will involve investigating the terms of the license in question, and to do the necessary steps to comply.

Sometimes in order to stay compliant, one might have to adopt a new license for your software, replace the open source software, or in some cases ignore it because you find out you are not under obligation to comply.

Example

This Equinor team maintains an application used by Equinor employees. The source-code is not made available, and the application is only reachable from the internal network.

Snyk report the following issue: aglp_issue

Investigating the AGPL-3.0 license, looking into the resources linked to at the bottom of this guide, the investigator finds the following useful information:

As any distribution of software that is linked to or incorporates AGPL components triggers copyleft, either the entire product must be made available under the AGPL or the product must only be used strictly internally.

Since this is the case for their application, they do not trigger the copyleft clause, and this issue can be resolved without further action.

What they do next is described bellow.

What to do after an issue is resolved

After a license-issue is resolved, a good practice would be to document it in Snyk via the 'ignore' button.

ignore_comment_1 ignore_comment_1

If you do need assistance, don't be afraid to reach out on Slack

More information

Some useful resources are listed bellow:

Some examples of compliance failures: