# Breakdown of Code analysis 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.

Overview of the Code Analysis page. — The Code Analysis page

## Code analysis components 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
Project filters	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.
Data flow	Displays the taint flow of the issue in the code.
Fix analysis	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.
Open repository external link	Quick access to the integrated Git repository for immediate remediation.
Imported by	The Git repository username who imported the analyzed repository.
Project owner	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.
Environment	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.
Business criticality	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.
Lifecycle	The Lifecycle attribute categorizes a Pro, Development, or Sandbox.
Tags	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	Analyzed Files: Includes files that have been reviewed by Snyk Code, encompassing recognized extensions and programming languages. Unanalyzed Files: Consists of text files yet to be analyzed because of unsupported languages or extensions. Unknown: Files without recognized extensions, potentially including multimedia content (such as pictures and videos), binaries, proprietary format files, or any other formats that fall outside Snyk Code's scope of interest.

## Data flow 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. ### View Data flow 1. Log in to the Snyk Web UI and select your [Group and Organization](https://docs.snyk.io/snyk-platform-administration/groups-and-organizations). 2. Navigate to the **Projects** and select the Target folder containing your repository's Projects. 3. Open **Code analysis** Project. 4. (Optional) [Search or filter for a specific vulnerability issue](https://docs.snyk.io/scan-with-snyk/snyk-code/manage-code-vulnerabilities/..#vulnerability-issues). 5. Select a vulnerability issue and navigate to **Full details** > **Data flow**. 6. 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](#data-flow-analysis-example). * [Open Data flow external link in the integrated Git repository](#open-data-flow-external-link). * Ignore the open vulnerability issue using the **Ignore** button. See [Ignore issues](https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/ignore-issues). ### Data flow analysis example 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.

Overview of a Path Traversal vulnerability issue. — Data flow of a Path Traversal vulnerability issue

### Open Data flow external link 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.

Vulnerability shown in the external source code. — Vulnerability shown in the external source code

## Fix analysis 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 ](#example-cwe-22-path-traversal)and [CWE-601 examples](#example-cwe-601-open-redirect). Some vulnerabilities contain links to interactive lessons on understanding, fixing, and preventing vulnerability. See [Snyk Learn](https://learn.snyk.io/).

Fis analysis page for Path Traversal vulnerability — Fix analysis page for Path Traversal vulnerability

### View Fix analysis 1. Log in to the Snyk Web UI and select your [Group and Organization](https://docs.snyk.io/snyk-platform-administration/groups-and-organizations). 2. Navigate to the **Projects** and select the Target folder containing your repository's Projects. 3. Open **Code analysis** Project. 4. (Optional) [Search or filter for a specific vulnerability issue](https://docs.snyk.io/scan-with-snyk/snyk-code/manage-code-vulnerabilities/..#vulnerability-issues). 5. Select a vulnerability issue and navigate to **Full details** > **Fix analysis**. 6. 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](#data-flow-analysis-example). * Ignore the open vulnerability issue using the **Ignore** button. See [Ignore issues](https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/ignore-issues). The **Fix analysis** page enables you to do the following: ### **Open Fix analysis external link** 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 "eclipse-vertx/vert.x".

Data flow of a Path Traversal vulnerability issue. — Fix analysis of a Path Traversal vulnerability issue

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.

Source code external link in Fix analysis

## Severity score factors 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 ### **Exceptions** 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. ## Priority score factors 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](https://docs.snyk.io/manage-risk/prioritize-issues-for-fixing/priority-score#view-issues-by-priority-score)).

Priority Score factor	Description
Severity Level	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.
Fix analysis	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.
Project tags	When an issue has a Project tag, it decreases the Priority Score by 100 points. This internal tag can be one of the following: Test - The issue was found in a test file. Beta - The vulnerability type of the issue is in Beta status. These internal tags are automatically assigned by Snyk Code analysis, and they are not visible on the Web UI.

### Quantitative factors * Severity scores from other SAST products where information is publicly available * Severity scores from identifying similar vulnerabilities in the Snyk Vulnerability database ### Qualitative factors * The severity of source, direct versus indirect * Prevalence and impact of the sink * Security team experience and research * Customer feedback ## Example: CWE-22: Path Traversal 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.

Decision flow chart for Priority Score CWE-22 Path Traversal

## Example: CWE-601: Open Redirect 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.

Decision flow chart for Priority Score CWE-601 Open Redirect