Available Snyk Reports
The following reports are available:
Select Change Report to change the report displayed:
Issues Detail report
The Issues Detail report displays all known issues in all of your Projects that are being monitored by Snyk. The report gives details about each issue and which of your Projects are affected and provides links to fix information.
The Issues Detail report displays the number of issues as well as the number of unique vulnerabilities that make up the issues.
Quick aggregations are available by categories including Severity, Product Name, and Issue Type.
Individual issues are displayed in a table according to the selected category. You can modify columns as needed.
For a table of only the unique vulnerabilities, use Change Report to switch to the Vulnerabilities Detail report.
Issues Summary report
The Issues Summary report highlights the value that Snyk is providing by enabling both the identification and resolution of issues.
The report provides a glimpse into how well teams are optimizing the use of the Snyk platform for their workflow and provides a means to measure and improve security.
This report enables you to easily understand the current state and trends of the highest security risk items. This report also provides a quick view into where risk is coming from and where remediation efforts are most and least effective.
Use the date filter in the upper right corner of the Issues Summary report to see key metrics and charts for a specified interval.
This report shows a number of key metrics associated with issues in that interval with a comparison to the same metrics in the previous period so you can get a quick understanding of trends. See tooltips in the app for definitions of the metrics.
Scroll down for additional charts that show trend information in greater detail.
Key metrics are then broken down to point out information at the Organization or Project level. You can drill down to see what new and resolved issues were introduced during the date range selected.
Vulnerabilities Detail report
The Vulnerabilities Detail report is similar to the Issues Detail report but shows issues grouped by Snyk Problem ID (see Snyk Vulnerability DB).
You can easily see how many instances of a vulnerability exist and how many Projects are affected. Use this report to understand which vulnerabilities are most prevalent for both resolution and prevention use cases.
For a table of Total Issues, use Change Reports to switch to the Issues Detail report.
Dependencies and license information
To view Dependencies and license information, select the Dependencies menu option. See Dependencies and licenses for details.
Featured Zero-Day report
This report addresses primary scenarios for managing and resolving emerging zero-day vulnerabilities, which carry significant consequences and attract substantial attention in the global AppSec community.
Use this report to discover your exposure to issues highlighted in a zero-day publication across various Targets and Projects. The report helps you prioritize zero-day issues and monitor the progress of remediation efforts against any remaining occurrences.
The Security team at Snyk continuously updates the Vulnerability Database with new vulnerabilities several times a day. When the team discovers a major new zero-day vulnerability—typically in a widely used package with high severity that affects many customers—it will be announced and addressed as a zero-day event.
Upon the announcement of a new zero-day event, begin by examining the Impacted Targets table to gain a deeper understanding of the exposure. Use filters such as Project Lifecycle, Environment, or Project Criticality to focus solely on Targets associated with Projects in production that are externally exposed or of high criticality. Gaining such insights depends on the availability of Project attributes.
Next, proceed to the All Issues table and compile a prioritized list of issues requiring remediation. Typically, prioritization is determined by either the Snyk Risk Score or NVD CVSS Score, with emphasis placed on addressing vulnerabilities within sensitive targets. Apply filters based on Project Lifecycle, Environment, or Project Criticality to identify and address these targets promptly.
For continuous monitoring of remediation progress and efficacy, refer to the trend diagrams. The Accumulative Issues Backlog Trend diagram shows the weekly changes in the zero-day backlog by accumulating the weekly delta between identified and resolved issues. Use this diagram to ensure that your R&D teams are reducing the zero-day backlog consistently, which will be indicated by a negative trend line.
In parallel, review the Issues Identified versus Resolved over Time diagram to conclude whether additional emphasis should be placed on preventing the introduction of new issues or on accelerating the remediation efforts.
SLA Management report
The report presents a set of default SLA targets per severity based on common security standards, such as FedRAMP. These SLA targets can be modified to meet your own security requirements.
The SLA status of an issue can be:
Within SLA - the age of the issue has not exceeded the SLA target, and it is expected to have sufficient lead time before breaching.
At Risk - the issue is considered to be approaching an SLA breach and is flagged as “At Risk”.
Breached - the age of the issue has exceeded the SLA target.
You can control the SLA targets and the transition of issues to the “At Risk” status by editing the SLA target and setting the At risk duration before breach (days) field.
The SLA report includes additional filters under the SLA category, allowing for better identification of the age of issues in relation to the SLA target:
SLA status - allows the filtering of the report according to a specific SLA status.
Issue age - allows to discover issues within a range of age.
Time until breach - identifies issues that will breach the SLA target within days.
You can share the report with predefined SLA targets by sharing the report URL or return to a predefined SLA report by bookmarking the web page in your browser.
In the Open issues section, the SLA severity breakdown shows a distribution of severity levels by the SLA compliance status of the viewed Group or Organization.
The SLA trend shows the cumulative SLA status of issues over time.
The SLA breakdown table allows you to compare the SLA compliance results of Organizations in the Group view, or Targets in the Organization view. The table is sorted by default according to the quantity of breached issues.
The Breached and at-risk open issues table helps you prioritize issues based on their aging and SLA compliance status. You can use the Modify Column picker to add additional columns and learn more about the specific issues.
You can review the SLA results for resolved issues and perform a retrospective analysis by reviewing the Resolved issues section.
OWASP Top 10 report
The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks for web applications and is globally recognized by developers as the first step towards more secure coding.
Each control in the list (A1, A2, and so on) is based on a list of Common Weakness Enumerations (CWEs). For example, A01:2021 – Broken Access Control is based on a list of 34 CWEs.
The CWEs are mapped to Snyk-IDs (), which are mapped to issues.
For example, the critical vulnerability SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720 is classified as CWE-94, which is part of the OWASP TOP 10 A03:2021 - Injection. All the issues related to this vulnerability will be under the A03 category.
Learn more by using the OWASP TOP 10 Learning path on Snyk Learn.
The report is based on the latest mapping released in 2021. The supported products are Snyk Open Source, Snyk Container, and Snyk Code.
CWE Top 25 report
The CWE Top 25 Most Dangerous Software Weaknesses is a list that demonstrates the current most common and impactful software weaknesses based on Common Vulnerabilities and Exposures (CVEs) severity and their exploitation potential.
The report is based on the latest version released in 2023 by Mitre. The supported products are Snyk Open Source, Snyk Container, and Snyk Code.
CWE Top 10 KEV report
The CWE Top 10 KEV Weaknesses list identifies the top ten CWEs in the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) Catalog, a database of security flaws in software applications and weaknesses that have been exposed and leveraged by attackers.
The report is based on the version released in 2023 by Mitre. The supported products are Snyk Open Source, Snyk Container, and Snyk Code.
PCI-DSS v4.0.1 report
PCI Security Standards are technical and operational requirements created by the PCI Security Standards Council (PCI SSC) to safeguard cardholder data. These standards apply to all entities that store, process, or transmit this information and include requirements for software developers and manufacturers. The Council manages these standards, while compliance is enforced by founding members: American Express, Discover Financial Services, JCB, MasterCard, and Visa Inc.
Snyk PCI-DSS v4.0.1 Report is designed to help you:
Estimate readiness for meeting the PCI-DSS AppSec requirements for SCA and SAST based on the Snyk scan results.
Provide evidence that the Organization is meeting the PCI-DSS AppSec requirements for SCA and SAST vulnerabilities.
Prioritize issues to improve PCI-DSS compliance readiness.
The report identifies PCI-DSS risks and violations based on the following PCI-DSS v4.0.1 requirements:
Requirement 6.2.4: Engineers use various techniques to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software. This includes but is not limited to the following methods:
Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system or application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms or attempts to exploit weaknesses in the implementation of such mechanisms.
Attacks using any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
Requirement 6.3.3: All system components are protected from known vulnerabilities by installing applicable security patches and updates as follows:
Patches and updates for critical vulnerabilities, identified according to the risk ranking process at Requirement 6.3.1 are installed within one month of release.
Snyk Violation Analysis based on PCI-DSS attack categories
As the standard does not explicitly define specific CWEs or CVEs, Snyk provides an analysis based on leading CWEs associated with the named attack categories. Below are the CWEs categorized by attack type:
Injection Attack Violations Summary
The following list provides an association between the identified attack categories and the CWEs associated with each category:
SQL Injection: CWE-89
LDAP Injection: CWE-90
XML Injection (XPath Injection): CWE-91
Command Injection: CWE-77
Use of Unsafe Reflection: CWE-470
Attacks on Data and Data Structures Violations Summary
The following list provides an association between the identified attack categories and the CWEs associated with each category:
Buffer Overflow: CWE-120
NULL Pointer Dereference: CWE-476
Double Free: CWE-415
Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’): CWE-362
Attacks on Cryptography Usage Violations Summary
The following list provides an association between the identified attack categories and the CWEs associated with each category:
Use of a Broken or Risky Cryptographic Algorithm: CWE-327
Use of Insufficiently Random Values: CWE-330
Improper Verification of Cryptographic Signature: CWE-347
Cleartext Transmission of Sensitive Information: CWE-319
Use of Hard-coded Cryptographic Key: CWE-321
Attacks on Business Logic Violations Summary
The following list provides an association between the identified attack categories and the CWEs associated with each category:
Server-Side Request Forgery (SSRF): CWE-918
Cross-Site Request Forgery (CSRF): CWE-352
Cross-Site Scripting (XSS): CWE-79
Origin Validation Error: CWE-346
Improper Authorization: CWE-285
Exposure of Sensitive Information to an Unauthorized Actor: CWE-200
Attacks on Access Control Mechanisms Violations Summary
The following list provides an association between the identified attack categories and the CWEs associated with each category:
Improper Authentication: CWE-287
Improper Access Control: CWE-284
Incorrect Authorization: CWE-863
Authorization Bypass Through User-Controlled Key: CWE-639
Missing Authentication for Critical Function: CWE-306
Incorrect Implementation of Authentication Algorithm: CWE-303
Attacks on Access Control Mechanisms Violations Summary
The Missing Authorization attack category is associated with CWE-862.
PCI-DSS v4.0.1 Guidance
The report is filtered by default on open issues of critical severity. Those filters are also applicable when exporting the report to PDF.
PCI-DSS Readiness Trend
The PCI-DSS Readiness Trend is designed to help you track your progress toward eliminating PCI-DSS violations. A violation is defined as a critical vulnerability elected by the PCI-DSS attack categories (as explained in Requirement 6.2.4) that is more than 30 days old, as stated in Requirement 6.3.3.
The number on the left indicates the violation status and the progress made in the last seven days.
The trend shows all vulnerabilities per Requirement 6.2.4, categorized by age bucket. This allows for quick identification of potential violations and vulnerabilities that may soon become violations.
Attack category breakdown
The breakdown table helps identify the number of vulnerabilities by attack category (as per requirement 6.2.4) or by Snyk Organization based on the relevant age bucket.
Use the table to pinpoint major attack categories or Snyk Organizations that lead to PCI-DSS violations. You can click on the figures to explore the specific issues in more detail.
Developer IDE and CLI usage
To use this report, you must ensure you have installed the following prerequisites:
Snyk CLI version 1.1292.1 or newer
VS Code 1.86.0 or newer and Snyk Security plugin 2.3.3 or newer
IntelliJ IDEs 2023.3 or newer and Snyk Security plugin 2.7.3 or newer
Visual Studio 2019, 2022 and Snyk Security Plugin 1.1.47 or newer
Eclipse 2023.12 or newer and Snyk Security plugin 2.1.0 or newer
This report shows the adoption of Snyk testing in local development through the IDE plugins and using the CLI locally. The report is available under the Change Report dropdown at the Group and Organization levels.
Security teams can use this report to demonstrate strong shift-left behavior as a model behavior to bring to other teams. This report also shows where teams or individual developers are not adopting Snyk locally. Companies can use this report to encourage more shift-left behavior.
This report shows the test usage in the IDE and CLI by developers:
Total number of developers running scans and the number of scans in IDE and CLI
Charts and summary tables breaking down this data by different dimensions, including IDE plugin
List of organizations and developers adopting Snyk locally
Teams can filter by date and Organization.
Repositories Tested in CI/CD report
To use this report, you must ensure you have installed Snyk CLI version 1.1292.1 or newer.
This report analyzes Snyk tests performed as part of CI/CD pipelines executed using Snyk CLI. It will inform you about the usage of your company and adoption of testing in CI/CD, ensuring repositories are tested as expected and preventing critical vulnerabilities and misconfigurations from being deployed and reaching the production environment.
The numbers displayed on the main view of the report represent the number of repositories tested in the selected date range per Snyk product.
In addition, you can learn about the change in the number of tested repositories compared to the previous sequential period, so you can conclude whether the adoption of CI/CD tests across repositories improved.
A green upward arrow indicates that more repositories were tested compared to the previous sequential period, while a red downward arrow indicates the opposite. The absolute change value appears next to the arrow, and the perception of change appears right underneath to measure the degree of change.
Repository Test Adoption
Review the Repository Test Adoption trend to learn more about the adoption over time. Represented by the green line, you can see the weekly number of repositories that have been tested compared to the repositories that had commits in the last 30 days, represented by the purple line.
This comparison helps determine whether Snyk tests in CI/CD are being increasingly adopted over time and highlights the number of repositories that have received commits but have not been tested in CI/CD.
You can filter by specific products or by specific organizations or extend the viewed period using the date range filter.
Test Success Rate Trend
The test success rate serves as an indicator of how well the engineering department or specific Snyk Organizations can adopt a "shift left" approach, which aims to identify and resolve issues before the code reaches the build process. This success rate is calculated by dividing the number of tests that passed by the total number of relevant tests conducted.
Having a low success rate can indicate that:
Snyk tests are failing due to security issues that can be prevented in local development or in the PR Check stages. Snyk recommends testing with the Snyk IDE plugin, using Snyk PR Checks and enroll in a Snyk Learn program.
The test success criteria are too strict. To explore this option further, Snyk recommends reviewing the test definitions of the organizations with the lowest success rate, as shown by the Adoption by Organizations widget. For more details about defining test success criteria, navigate to the Failing of builds in Snyk CLI page.
Adoption by Organizations
Launching an Application Security program to boost testing adoption in CI/CD pipelines can be challenging. This initiative requires collaboration between the AppSec and R&D teams and will be implemented gradually, with regular progress monitoring.
The Adoption by Organization table facilitates tracking and comparing the adoption rates of Snyk Organizations, helping you identify the organizations that are struggling or lagging behind.
In addition, you can examine the success rate column to surface organizations that have lower success rates.
Columns descriptions:
Tested Repositories: the number of repositories that were tested in the selected time range, with an indication of the percentage of change compared to the previous sequential period.
Committed Repositories: the number of repositories that had any commits in the last 30 days at any given time within the selected time range, with an indication of the percentage of change compared to the previous sequential period.
Success Rate: the portion of successful tests in CI/CD against all other tests that were executed.
Repository Test Summary
The repository test summary table shows the performed tests during the selected date range.
The default sorting in the table surfaces repositories according to their last commit, allowing you to identify repositories that were expected to be tested in CI/CD pipelines and verify they were tested. Clicking the column names to sort the table according to the selected column. You can sort the table by multiple columns at a time.
You can execute the test on a specific repository branch in the table. The tested indicator means that any branch of this repository was tested during the selected date range.
Cloud Compliance Issues report
The Cloud Compliance Issues report shows cloud issues for an entire Organization, organized by compliance standard.
You can view a report for a single version of a compliance standard at a time, for example, CIS AWS Foundations Benchmark v1.4.0, by selecting the desired standard from the dropdown menu. Each report includes a list of compliance controls organized by control category, with corresponding issue counts.
Selecting an issue count lets you view the list of issues associated with that control in the Cloud Issues UI, where you can view each issue in detail.
Use the information in the Cloud Compliance Issues report to investigate, triage, and fix cloud compliance issues.
Snyk Generated Pull Requests
Access the report
The Generated Pull Requests report can be accessed at both Group and Organization level from the Change Report drop down in the Reports menu.
This report type provides an overview of how Fix, Backlog, and Upgrade PRs are used and highlights the efficiency of PR merges.
The analytics report covers the following:
Overview of PRs status by type and the PR merge ratio.
Visibility of issues.
Breakdown by repository for PR status.
The report summary enables you to check the total number of Snyk PRs created, the total pull requests merged, and the mean time to merge for those pull requests.
Report features
Use the date filter in the upper right corner of the report to display data based on a specific interval.
Add various filters to narrow down results to specific configurations. The filter options are Organization, SCM, Project, and Repository.
Snyk Generated Pull Requests usage
Pull Request usage is visualized in a Pull requests by type graph and a Pull requests by status table, displaying the same data in different formats. These distinguish the number of PRs into Fix, Backlog, and Dependency upgrade categories, segmented by Open, Merged, and Closed status types. Merge rate is presented as a percentage for each row.
Open vs Fixed issues
The Open vs Fixed issues in Snyk PRs graph and table displays the number of open and fixed issues based on severity.
Snyk Generated Pull Requests by repository
The Projects/Org/Repository table displays the number of Total, Open, Merged, and Closed PRs for each Organization and repository relationship. Merge rate is presented as a percentage for each row.
Select a repository name to open a modal containing additional metrics for that specific repository.
The repository breakdown details the number of PRs segmented by PR type and PR status. Merge rate is presented as a percentage for each row. It also lists the Projects within that repository, with the number of issues categorised by severity.
Asset Dashboard
The Asset Dashboard provides a comprehensive overview of your application and security controls. It displays essential data such as the status and trends of open issues, control coverage, and repository metadata.
The Asset Dashboard is a central hub for managing and reviewing assets, making tracking inventory size easier over time and understanding the interaction between different asset types.
While Snyk Inventory enables the discovery and management of your assets that should be secured, the Snyk Asset Dashboard allows you to go beyond the details and better understand the main building blocks of your inventory. The Asset Dashboard brings all the asset data that is available in your inventory and helps to answer various questions, such as:
Does my AppSec program meet the coverage requirements for business-critical assets and strategic applications?
Are the assets being classified properly according to their criticality?
Do you know which repositories belong to which application or code owners? Are newly introduced repositories being updated with that data?
What are the main programming languages and package managers that are used in repositories that have been worked on recently?
Filters
The filters are located at the top left of the page, with the following filtering options: Asset Class, Asset type, Add filter. The filter selection applies to all available data widgets.
Here are the available filters:
Asset Class
The business criticality of an asset (A - most critical to D - least critical).
Asset type
The type of an asset (Container image, Package, Repository). Most data widgets already present certain asset types by default.
*Application
The list of the applications for which you have configured the application context catalog in Snyk Essentials.
*Catalog name
The name of your application context catalog.
*Category
The category of a repository asset. For example, service or library.
Discovered
The period when the asset was discovered.
Last Seen
The period when the asset was last imported from the integration.
*Lifecycle
The lifecycle state of the application context catalog component. For example production, experimental, deprecated.
*Owner
The team that owns the repository for which the application context catalog was configured.
Repository Freshness
The last commit date in the repository:
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.
N/A: There are no commits detected by Snyk Essentials.
Source
The integration that imported the asset.
Tags
The asset tags. For more details about tagging assets using a policy, see the Tagging policy page.
*Title
The name of the component for which the application context catalog was configured.
*All filters marked with * are visible only if you configured the application context catalog for your SCM integrations.
Repository coverage widget
The repository coverage widget provides an overview of the percentage of scanned repositories compared to the total number of available repositories, using integrated Snyk or third-party security products.
Hover over any column to see how the coverage percentage is calculated.
Asset class breakdown
The asset class breakdown widget surfaces the distribution of repositories and container images by asset class. Reviewing this widget allows you to determine the percentage of business-critical assets in your inventory and drill down to see the actual assets.
Top 10 technologies breakdown
The top 10 technologies widget identifies the leading programming languages and frameworks used in repositories. Using the available filters enables you to determine the most commonly used technologies in active or business-critical repositories. Moreover, you can investigate specific applications or code owners.
Top 10 package managers breakdown
The top 10 package managers widget allows you to identify the leading package managers in your inventory. The quantities represent assets of package type. A package asset is defined as software or library that is managed by package management systems.
Repository freshness
The repository freshness widget displays the distribution of repositories according to the last commit date:
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.
N/A: Commits data is unavailable.
You can use this widget to surface the quantity of repositories that are more or less maintained in various contexts, such as specific applications.
Application context availability
The application context availability widget allows you to discover gaps in the context of assets. The available columns include:
Application Context - displays the analyzed context attribute.
Unique Values - shows how many unique instances exist for an attribute. For example, you can check how many unique applications or code owners are available for any of the listed attributes.
Availability in Repos - indicates the completeness of a certain attribute across the repositories.
Asset source breakdown
The asset source breakdown widget visualizes the quantities of detected assets from various sources. A source can be a platform where the asset is being managed directly (such as an SCM, container registry, and so on) or a platform that enriches the assets (such as security products and ASTs).
Last updated
Was this helpful?