Breakdown of Code analysis
Last updated
Last updated
More information
Snyk privacy policy© 2024 Snyk Limited | All product and company names and logos are trademarks of their respective owners.
When you import repositories, Snyk Code automatically tests for vulnerabilities within the imported code. The vulnerabilities detected across all files in a single repository are compiled into a Snyk Project, labeled as Code Analysis. Code Analysis presents the test outcome for a specific repository, listing all discovered vulnerabilities in the repository's source code.
This table summarises the elements of a Code analysis Project.
| Component | Description |
|---|---|
Header | Includes the details of the imported repository with a link to the repository in the Git repository, the Project name, and the Projects tabs: Overview, History, and Settings. |
The Project Summary Information area | Includes the dates of the repository import and the last test of the repository, the Retest now option for an on-demand test, the name of the user who imported the repository, the name of the Project owner, and the number of code files that were analyzed and not analyzed. See Retesting code repository |
Includes a set of pre-defined criteria for filtering the displayed issues. | |
Vulnerability issues | Includes the vulnerability issues that Snyk Code discovered in the imported repository. |
Displays the taint flow of the issue in the code. | |
Provides additional details about the discovered vulnerability type, best practices for preventing this issue, and code examples of fixes. | |
CWE | The CWE (Common Weakness Enumeration) ID of the specific vulnerability type and a link to the CWE website, where this vulnerability type is described. See Example: CWE-22: Path Traversal. |
Quick access to the integrated Git repository for immediate remediation. | |
Imported by | The Git repository username who imported the analyzed repository. |
Identifies the lead for the Project in your Organization for administrative purposes only; it does not impact the Snyk Project itself. This is not a required field and is left blank by default. | |
The Environment attribute describes the software's context, ranging from client-side (Frontend) to server-side (Backend), private (Internal) to public (External), across platforms like Mobile, Cloud (SaaS), On-Premises, Hosted services, and Distributed systems. | |
When the Risk Score feature is enabled, the Business Criticality attribute automatically influences the score, scaling it to the most significant attribute level. See Risk Score. | |
The Lifecycle attribute categorizes a Pro, Development, or Sandbox. | |
The Snyk Project tags feature enables the addition, removal, and use of custom metadata tags to organize and filter Projects, simplifying Project management and navigation. | |
Analysis summary | The number of code files analyzed in the repository and the percentage of the analyzed files out of the total repository code files. |
Repo breakdown |
|
Data flow shows the location of the discovered issue in your source code and how it flows throughout your application. It shows the taint flow of the issue in the code, with a step-by-step visualization from the source to the sink, presenting the code lines of all the steps in the flow.
The source is the input point of the potential problem. This is a point in the application where a user or an external device can enter data, which will potentially violate the security of the application. For example, in an SQL Injection issue, the source will be a form or any other data input area filled by a user.
The sink is the operation in the code where the application executes the problem. This point must receive clean input, or it can be exploited. For example, in an SQL Injection issue, the sink will be the internal operation that instructs the DB to perform certain actions according to the received input.
Every issue discovered by Snyk Code has a data flow. If an issue has only one step, for example, in the case of hardcoded secrets, the source of the issue will be displayed on the Data flow page.
Log in to the Snyk Web UI and select your Group and Organization.
Navigate to the Projects and select the Target folder containing your repository's Projects.
Open Code analysis Project.
Select a vulnerability issue and navigate to Full details > Data flow.
As part of the Data flow analysis, you can take the following actions:
View the taint flow of an issue in your code from source to sink. See Data flow analysis example.
Ignore the open vulnerability issue using the Ignore button. See Ignore issues.
In the following Path Traversal issue, the developer has not sanitized the input. This allows an attacker to perform a pass traversal attack to access any file in the file system, including sensitive data such as password files.
To open the displayed source code on the Git repository, select the file name above the right panel. In this example, the file name is routes/profileImageUrlUpload.ts.
The source code appears in the integrated Git repository, showing you exactly where to fix the vulnerability. You can make the required fix to address the vulnerability in your code.
Fix analysis helps you fix the vulnerability issue discovered in your code. It provides details about the vulnerability type discovered, any available best practices for preventing this issue, and code examples of fixes from the global open-source community.
To explore in-depth details about the specific vulnerability identified, you can open the CWE link to understand more about the vulnerability type. See CWE-22 and CWE-601 examples.
Some vulnerabilities contain links to interactive lessons on understanding, fixing, and preventing vulnerability. See Snyk Learn.
Log in to the Snyk Web UI and select your Group and Organization.
Navigate to the Projects and select the Target folder containing your repository's Projects.
Open Code analysis Project.
Select a vulnerability issue and navigate to Full details > Fix analysis.
As part of the Fix analysis, you can take the following actions:
View the discovered issue and ways to prevent it.
Examine fix examples from the global open-source community by reviewing and browsing through code samples.
View the code diff of the fix example that appears in the integrated Git repository, showing you how this vulnerability was fixed. See Open Fix analysis external link in the integrated Git repository.
Ignore the open vulnerability issue using the Ignore button. See Ignore issues.
The Fix analysis page enables you to do the following:
To open the code fix for the vulnerability on the Git repository, select the git repository above the right panel. This will show you the differences in the Git repository code that address the issue. In this example, the Git repository name is NodeBB.
The fix appears in the Git repository, showing you exactly where to fix the vulnerability. You can make the required fix to address the vulnerability.
Snyk Code reports issues by severity levels: High, Medium, and Low. Snyk Code currently does not use the Critical severity level. The severity score is based on the following factors:
Qualities intrinsic to a vulnerability
Evolution of vulnerability over a lifetime
If a vulnerability is detected in code, filename, or folder with the word test, it is deemed a low-severity vulnerability. This applies to all languages. The severity of CWEs may change depending on the environment.
Use the Priority Score to filter and prioritize discovered issues based on their importance, risk, frequency, and availability of a Fix analysis.
A Priority Score for each issue can be between 0 and 1,000, which changes automatically if one of its factors changes. For example, if the Severity Level of an issue has increased or decreased, the Priority Score of the issue changes accordingly.
You can filter issues in the Code analysis Project by Priority Score using the PRIORITY SCORE slider to set the range of the scores you want to display (see View issues by Priority Score).
| Priority Score factor | Description |
|---|---|
The higher the severity level, the higher the security risk of the issue. Each severity level adds a different Score to the issue. The Score can be, at most, 500 points. Currently, Snyk Code does not use the Critical severity level. | |
When an issue has a real-world fix example, it is marked as easier to fix, with a higher Priority Score. The Score can be, at most, 200 points. When Fix analysis is available, it is displayed in the Full Details panel of the issue on the Fix analysis tab. | |
Issue occurrence in a Project | The number of times a specific issue appears in the Code Analysis Project. The higher the frequency, the higher the risk and the Score. The Score can be, at most, 100 points. |
Issue occurrence in a File | The number of times an issue appears in a specific file. The higher the frequency, the higher the risk and the Score. The Score can be, at most, 100 points. |
Community Projects | The number of times an issue was fixed in external open-source Projects that Snyk examined. The Score can be, at most, 100 points. |
When an issue has a Project tag, it decreases the Priority Score by 100 points. This internal tag can be one of the following:
|
Severity scores from other SAST products where information is publicly available
Severity scores from identifying similar vulnerabilities in the Snyk Vulnerability database
The severity of source, direct versus indirect
Prevalence and impact of the sink
Security team experience and research
Customer feedback
For CWE-22 Path Traversal, if the vulnerability occurs in a test, it is Low severity. If not, and it comes from a direct source, it is High severity. Otherwise, it is Low severity.
For CWE-2601 Open Redirect, if the vulnerability occurs in a test, it is Low severity. If not, and it comes from a direct source, it is Medium severity.
