The Secure Glossary of Terms aims to achieve the following:
The definitions of the terms outlined in this document are provided in the specific context of the GitLab Secure Products. Please note, therefore, that a term may have a different meaning to users outside of GitLab Secure.
Software that performs a scan. The scan analyzes an attack surface for Vulnerabilities and produces a report containing Findings. Reports adhere to the Secure Report Format.
Analyzers integrate into GitLab using a CI job. The report produced by the Analyzer is published as an artifact once the job is complete. This is ingested by GitLab, to allow users to visualize and manage found vulnerabilities. More information can be found at Security Scanner Integration.
Many GitLab Analyzers follow a standard approach using Docker to run a wrapped Scanner. For example, the Docker image
bandit-sast is an Analyzer that wraps the Scanner
The Common library can be optionally used to assist building an Analyzer.
The different places in an application that are vulnerable to attack. Secure products discover and search the attack surface during scans.
Each product defines the attack surface differently, for example, SAST will use files and line numbers, while DAST uses URLs.
CVE Numbering Authorities (CNAs) are organizations from around the world that are authorized by the Mitre Corporation to assign CVEs to vulnerabilities in products or services within their respective scope. Gitlab is a CNA.
Common Vulnerabilities and Exposures (CVE®) is a list of common identifiers for publicly known cybersecurity Vulnerabilities. The list is managed by the Mitre Corporation.
The Common Vulnerability Scoring System is a free and open industry standard for assessing the severity of computer system security Vulnerabilities.
Common Weakness Enumeration (CWE™) is a community-developed list of common software and hardware weakness types that have security ramifications. "Weaknesses" are flaws, faults, bugs, Vulnerabilities, or other errors in software or hardware implementation, code, design, or architecture that if left unaddressed could result in systems, networks, or hardware being vulnerable to attack. The CWE List and associated classification taxonomy serve as a language that can be used to identify and describe these weaknesses in terms of CWEs.
A legitimate Finding which was found, but for some reason is reported multiple times. This can occur when different scanners find the same Finding, or when a single scan inadvertently creates the same Finding more than once.
A Finding which does not actually exist but is incorrectly reported as existing.
Feedback provided by the user about a Finding. Types of Feedback include dismissal, creating an issue, or creating a merge request.
An asset that has the potential to be vulnerable, identified within a project by an Analyzer.
Assets include but are not restricted to source code, binary packages, containers, dependencies, networks, applications, and infrastructure.
A legitimate Finding that a particular customer does not care about.
A Finding's Location Fingerprint is a text value that is unique for each location on the Attack Surface. Each Secure product defines this according to their type of Attack Surface, for example, SAST will incorporate file path and line number.
A page that displays Findings discovered in the associated CI Pipeline.
A Finding's Primary Identifier is a value that is unique for each Finding. The external type and external ID of the Finding's first identifier combines to create the value.
Examples of Primary Identifiers include ZAP's
CVE for Klar.
Note that the identifier must be stable; subsequent scans must return the same value for the same Finding, even if the location has slightly changed.
Describe the type of scan, must be one of
Please use Scan Type instead of Report Type in future.
Software that can scan for Vulnerabilities. The resulting report of the scan is typically not in the Secure Report Format. Examples include ESLint, Klar, and ZAP.
A group of features related to a specific area of application security with first-class support by GitLab.
Products include Container Scanning, Dependency Scanning, Dynamic Application Security Testing (DAST), Secret Detection and Static Application Security Testing (SAST). Each of these products typically includes one or more Analyzers.
A standard report format that Secure products comply with when creating JSON reports. The format is described by a JSON schema.
Provides an overview of all the Vulnerabilities for a project, group, or GitLab instance. Vulnerabilities are only created from Findings discovered on the default branch of the project.
The party maintaining an Analyzer. As such, a vendor is responsible for integrating a Scanner into GitLab and keeping them compatible as they evolve. A vendor is not necessarily the author or maintainer of the Scanner as in the case of using an open core or OSS project as a base solution of an offering. For Scanners included as part of a GitLab distribution or gitlab.com subscription, the vendor will be listed as "GitLab".
A flaw that has a negative impact on the security of its environment. Vulnerabilities describe the error or weakness, and do not describe where the error is located (see Finding).
Each Vulnerability maps to a unique Finding. Plans are underway to group related Findings to the same Vulnerability to empower users with additional workflows and improve the tracking of Findings.
Deals with the responsibility of matching Findings across scans so that the life cycle of a Finding can be understood. Engineers and Security Teams use this information to decide whether to merge code changes, to see unresolved Findings and when they were introduced.
Vulnerabilities are tracked by comparing Location Fingerprint, Primary Identifier, and Report Type.
Deprecated, see Finding.