Intelligent Software Composition Analysis (SCA)

ShiftLeft CORE can help you identify open source vulnerabilities and prioritize them based on how problematic they may be to your application's security.

Requirements

Before proceeding, please ensure that you have set up and authenticated with ShiftLeft. Then, analyze your application to obtain a list of findings, including OSS vulnerabilities.

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

Currently, ShiftLeft is capable of scanning for open-source vulnerabilities in applications written in C#, Java, JavaScript, and Scala. Support for other languages is forthcoming.

ShiftLeft supports the following package formats:

LanguagePackage format
C# - .NET Core and .NET Framework.csproj, packages.config
Java/ScalaMaven (pom.xml), Gradle (build.gradle, .kts), scala (sbt)
JavaScript (Node.js)package-lock.json, pnpm-lock.yaml, yarn.lock, Rush.js

Background

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:

  1. Is the package that contains the CVE loaded by the application?
  2. Is the package that contains the CVE in use by the application?
  3. Is the CVE in the package in an attacker-controlled path? Is it reachable via data flows?
  4. 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.

Reachable Findings

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 sl analyze.

For example, to analyze a Java application, use:

sl analyze --app <name> --oss-project-dir <path-to-directory> --java [<path-to-JAR-or-WAR>]

or to analyze a .NET Framework application that is located at <application-directory>, use:

sl.exe analyze --app <name> --csharp --dotnet-framework <application-directory>\my-project.csproj

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 sl analyze.

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 pom.xml, the csproj file, or build.sbt, and uses this information during code analysis.

When running sl analyze, you can explicitly point to the location of your application source code using the flag --oss-project-dir <path-to-directory>.

Viewing Your Results

You can view all OSS findings using the ShiftLeft Dashboard.