Summary

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.

The ShiftLeft dashboard's Summary tab with scan metadata graph

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:

The ShiftLeft dashboard's Summary tab with scan details graph

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 <builtins> in JavaScript, header files without code in C, or files from the Go standard library

      • 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

      • Library Users: Methods that call into a library-style sink. These methods are generally written by the application's developers. For performance reasons, this list only contains methods that perform a static call into such methods and can therefore be incomplete (especially in dynamic languages like JavaScript or Python)

      • 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)

Additional insights

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).
The bottom of the summary page showing additional insights information