ShiftLeft CORE can help you identify open source vulnerabilities and prioritize them based on how problematic they may be to your application's security.
This feature is available as part of the ShiftLeft Premium trial; if you're on a free account, you can upgrade to see your results. For existing users with an upgraded subscription as of 30 March 2021: please work with your account representative to get this feature enabled.
Supported languages and package formats
ShiftLeft supports the following package formats:
|C# - .NET Core and .NET Framework|
When you include open-source packages in your application, you take on the possibility of introducing security vulnerabilities due to their presence in the open-source package.
To mitigate such security issues, you have to know what is present. However, the problem is that you may end up with a lot of information from your security tools. With this abundance of information, it can be challenging to determine which items are high priority and which ones are less likely to affect your application. To that end, it's essential to decide if a finding is potentially problematic in the context of your application.
How ShiftLeft Can Help
ShiftLeft seeks to help you answer the following four questions when it comes to any common vulnerability and exposure identified as being present due to the use of an open-source package:
- Is the package that contains the CVE loaded by the application?
- Is the package that contains the CVE in use by the application?
- Is the CVE in the package in an attacker-controlled path? Is it reachable via data flows?
- What can you do to mitigate the CVE? Typically, you can't fix an issue in an open-source package, but are there options (other than upgrading) available to you?
In short, ShiftLeft will help you identify CVEs and determine if the CVEs are high-priority items. With that information in hand, you should be better informed when it comes time for you to mitigate the open-source vulnerability.
We consider a finding to be reachable if an attacker-controlled path connects application inputs to the CVE. The concept of reachability is crucial because it tells you if someone can exploit a vulnerability in your application; if not, then you can consider this vulnerability a low priority for mitigation.
How to Identify Open Source Vulnerabilities
To identify open source vulnerabilities that may affect your application, invoke
For example, to analyze a Java application, use:
or to analyze a .NET Framework application that is located at
Source Code Filepaths
For languages that NG SAST analyzes using the application's source code (e.g., C#), NG SAST automatically searches for build manifests in the project path you provided when running
For all other languages (e.g., Java) where NG SAST requires the packaged artifact or the project package, NG SAST assumes that the directory from which you run
sl analyze is the directory that contains the application's source code.
Regardless of language, NG SAST automatically searches for build manifests, such as the
csproj file, or
build.sbt, and uses this information during code analysis.
sl analyze, you can explicitly point to the location of your application source code using the flag
Viewing Your Results
You can view all OSS findings using the ShiftLeft Dashboard.