The summary page of the application details section provides you with high-level information regarding the application you've submitted for analysis.
The scan history that features prominently provides insight into what ShiftLeft CORE looks at during each scan. As you read the graph from left to right, you'll move from seeing the types of findings identified by ShiftLeft CORE to the components that are a part of your application to seeing the findings identified as present in the individual components.
In addition to the scan history graph, you can toggle over to a simplified graph using the line graph icon; this graph shows you the number of findings present in the current and previous scans:
To the right and the bottom of these graphs are graphical summaries by finding types (vulnerabilities, OSS Vulnerabilities, container vulnerabilities, secrets, and insights). ShiftLeft also displays:
- Severity levels (e.g., critical, high, medium, or low) for vulnerabilities, OSS vulnerabilities, and container vulnerabilities;
- Reachability status for OSS and container vulnerabilities.
Metadata graph definitions
Application scan: The application that you submitted
Code: The code scanned by ShiftLeft
File: The number of source files scanned. When scanning compiled artifacts, the accuracy of this count may depend on the presence and accuracy of debug/source-map information.
Configuration: Files that have been scanned as configuration files
External: Files that contain at least one user-defined method
Internal: Files that contain no user-defined methods, including synthetic (i.e., fake) files like
Lines of Code: For each file with line number information and more than one method body, ShiftLeft takes the largest line number and sums it over the files present.
Method: Methods scanned
External: Built-in and library methods, as well as synthetic methods (i.e., those that are not present in the code, but implicitly exist in the type system).
If this list contains methods that you consider to be scanned project code, then please contact the ShiftLeft Customer Success team about blacklisting those methods.
Internal: Methods with bodies contained in the scanned user code.
If this list contains methods that should better be viewed as external library code (e.g., vendored dependencies), then please contact the ShiftLeft Customer Success team about blacklisting those methods.
Model: Statistics collected by ShiftLeft CORE demonstrating its understanding of inputs/outputs of the scanned code. You can use these statistics to verify that ShiftLeft has a correct understanding of vendored (external) libraries and frameworks used in your codebase.
If the statistics indicate that ShiftLeft CORE does not have a correct understanding of your code, please reach out to the ShiftLeft Customer Success team; we will then generate a model (a.k.a. policy or annotations) of the libraries you're using.
HTTP Routes: Exposed HTTP routes
Sinks: Points where potentially tainted data leaves your program; ShiftLeft CORE tracks and evaluates dataflows from sources to sinks. This statistic counts the number of methods where this happens (this statistic is a summary on a per-method basis rather than a granular count). Sinks are further divided into additional categories, but because they are not mutually exclusive, the sums of individual categories may not add up to equal the total number of sinks
Exposed (Public API): Methods where the return value or an output parameter is a sink of potentially tainted data. These are typically public API functions exposed by your program
Expressions: Expressions within method bodies that have been identified as sinks of taint (e.g., methods that can be used to write to global variables). This kind of sink is relatively rare.
HTTP Requests: Methods that send outgoing HTTP requests to a URL
HTTP Responses: Methods that send HTTP response data
Library Methods: Methods whose input parameters are sinks of taint. These are typically external library functions, as opposed to user code
Logging: Methods that log their inputs
SQL: Methods that perform SQL queries
Sources: Points where tainted data enters your program (or the ShiftLeft CORE scanning engine becomes aware that tainted data is present). This statistic counts the number of methods where this happens (this statistic is a summary on a per-method basis rather than a granular count). Sources are further divided into additional categories, but because they are not mutually exclusive, the sums of individual categories may not add up to equal the total number of sources
Attacker Controlled: Methods that process attacker-controlled data (and are not already counted above as an HTTP request)
Exposed (Public API): Methods where their input parameters are sources of taints. These are typically user-written code (as opposed to external library code) that are callable from the outside (e.g., HTTP handlers for applications or public API functions in cases where the user code is a library), but this also includes cases where ShiftLeft CORE attaches a taint to a method's input parameter for other reasons (e.g., various heuristics). The subcategories are not necessarily exhaustive or mutually exclusive, so the sums of individual categories do not necessarily add up to equal the total
Expressions: Expressions within method bodies that have been identified as sources of taint. In these cases, the source is typically not the true source of the taint -- it is instead a point where ShiftLeft CORE noticed that data is tainted. For example, ShiftLeft may mark all access to certain fields of classes as tainted, even though the taint actually comes from a system call deep in a library
HTTP Data: Methods that work with HTTP source data. These can be HTTP handlers or middleware written by you or library methods that return information about an incoming HTTP request
Library Methods: Methods that return a tainted value (directly or through an out parameter). These are typically external library functions, as opposed to user code
Library Users: Library-style sources are methods that return a tainted value (either directly or through an out parameter). These are typically external library functions, as opposed to user code
OSS: the open-source packages/libraries leveraged by your application
- Dependencies: Dependencies (including transitive dependencies) of your project. These are used by our SCA (software composition analysis) scanning for known CVEs. You can use this list to verify that ShiftLeft CORE has a correct understanding of your build configuration (ShiftLeft cannot report CVEs in your upstream if it doesn't understand your upstream)
Near the bottom of the application details summary page is a series of boxes displaying Additional Insights:
- The number of findings in each vulnerability category (e.g., 41 findings involving sensitive data usage);
- The top OSS packages with vulnerabilities leveraged by your application with vulnerabilities and the number of vulnerabilities resulting from that package;
- The top OSS vulnerability references (e.g., the number of times your application is affected by a specific CVE);
- The number of findings assigned to users for further work (if any).