Skip to main content

Semgrep Supply Chain glossary

The terms and definitions provided here are specific to Semgrep Supply Chain.

Advisory​

Announcement of a vulnerability, typically but not always with an associated Common Vulnerabilities and Exposures (CVE) number. All Advisories can be found by Semgrep Supply Chain rules. Advisories can be seen within the Supply Chain > Advisories tab.

Dependency​

Publicly available code used as a part of your application. Common examples include Flask, React, and Lodash. Each dependency is listed in a registry, such as npm for JavaScript and PyPI for Python.

Exploitability​

Exploitability is the practical assessment of a vulnerability's threat, typically proved with a real proof of exploit. Proving exploitability is often the last step of triaging a vulnerability.

EPSS probability​

The Exploit prediction scoring system (EPSS) probability represents the likelihood that the vulnerability will be exploited in the wild in the next 30 days. Its values range from 0% to 100%. The higher the score, the greater the probability the vulnerability will be exploited. Semgrep groups probabilities as follows:

  • High: 50 - 100%
  • Medium: 10 - <50%
  • Low: <10%

Lockfile​

A lockfile describes a dependency tree to ensure that deployments and organizations install the same dependencies and exact versions for their codebase. Lockfile information includes versions of the dependency and any transitive (indirect) dependencies. Lockfiles are automatically generated by a package manager such as pip or npm.

Semgrep Supply Chain uses lockfiles as part of its analysis to determine the exact version of a dependency that a codebase is using.

Rules without reachability analysis​

Some Semgrep Supply Chain rules do not perform reachability analysis. These rules only check a package's version against versions with known vulnerabilities. These rules produce vulnerabilities similar to GitHub Dependabot's results, and have a higher false positive rate than reachability rules.

Compare its opposite: Reachability-rules.

Manifest file​

A manifest file describes the dependencies used in your codebase. In a manifest file, a dependency may indicate a range of versions. A package manager reads the manifest file when installing dependencies into a specific implementation of your codebase, then generates a manifest file specifying the exact version of each dependency installed and any transitive dependencies.

Semgrep Supply Chain uses manifest files to resolve transitive dependencies for some languages. For more information, see Supported languages.

Package manager​

A software tool that interacts with a package registry to download, upload, or search for dependencies. Package managers typically generate manifest files or lockfiles by analyzing manifest files.

Package registry​

A package registry stores dependencies and provides a means to upload or download dependencies. Each programming language has its own separate registry such as npm for JavaScript and PyPI for Python.

Reachable finding (and reachable vulnerability)​

A reachable finding means that you are using both a vulnerable code pattern (the usage) and the vulnerable version of a dependency. Within Semgrep Supply Chain, specific findings (usages) are grouped together by their vulnerability.

CI scans with Semgrep Supply Chain rules can block pull requests or merge requests upon detecting any reachable findings.

See also Reachability.

Reachability​

Reachability refers to whether or not a vulnerable code pattern from a dependency is used in the codebase that imports it. In Semgrep Supply Chain, both a dependency's vulnerable version and code pattern must match for a vulnerability to be considered reachable.

See Overview of Semgrep Supply Chain to learn how Semgrep leverages its code-scanning and rule syntax capabilities to provide high-signal rules that determine a finding's reachability. This assists security engineers in remediation and triage processes.

Reachability rules​

A type of Semgrep Supply Chain rule that performs reachability analysis. A reachability rule can determine if the vulnerable code pattern from a dependency is used in the codebase that imports it.

Compare its opposite: rules without reachability analysis

Software bill of materials (SBOM)​

Software Bill of Materials (also known as 'Cyber Bill of Materials', CBOM) is an artifact produced by many software composition analysis tools. It enumerates the various components of a software artifact such as dependencies, licenses, and security statuses. SBOMs are typically generated for compliance purposes. Regularly, a security engineer or related role signs-off on the SBOM, meaning that they accept the security and legal risk of the associated artifact.

Semgrep Supply Chain can export a CycloneDX 1.4 XML/JSON-formatted SBOM.

Threat​

A threat is any malicious event that violates the security of an application or network. A threat can result in disrupted business operations and loss or theft of data.

See also NIST definition of threat.

Transitive or indirect dependency​

A transitive or indirect dependency is a dependency of a dependency. If your codebase uses a dependency A, and A is dependent on B, then B is a transitive dependency. An example would be a codebase that uses Cloudinary, which is dependent on Lodash. In this example, Lodash is a transitive dependency of the codebase.

For more information, see Supported languages.

Transitivity​

Pertains to a dependency's relationship to your codebase or first-party code.

  • Direct: Your project depends directly on the dependency.
  • Transitive: Your project's dependency depends on a vulnerable dependency.
  • Undetermined: Semgrep had no transitivity information for the dependency as it relates to your project.

Usage​

In Semgrep Supply Chain scans, a **usage **is a specific finding in your codebase where Semgrep has found a vulnerability. A vulnerability may have more than one usage, such as when a library is imported and used in many code files.

Unreachable finding (and unreachable vulnerability)​

An unreachable finding means that the dependency's version contains a known vulnerability, but the vulnerable code is not used within your codebase. Within Semgrep Supply Chain, specific findings (usages) are grouped together by their vulnerability.

Vulnerability​

A vulnerability is an unintentional flaw in a dependency that can be exploited. Vulnerabilities are assigned a CVE by the MITRE corporation. Semgrep Supply Chain uses GitHub Security Advisory (GHSA) in categorizing the severity of a vulnerability.

Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.