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 Bandit.
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.
When a category's process deems findings to be the same, or if they are similar enough that a noise reduction is required, only one finding is kept and the other(s) are eliminated. This is an irreversible action. Deduplication is only done for findings in reports of the same category. Deduplication does not occur between reports of different categories.
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.
We want to provide ways for users to view items in groups when there are multiple findings that are likely related but do not qualify for deduplication. Examples include findings that: should be evaluated together, would be fixed by the same action, or come from the same source. Grouping behavior for vulnerabilities is currently in design and subject to change. It is intended as a way for users to visually organize vulnerabilities for noise reduction and more efficient workflow. Grouping is flexible and not a destructive or irreversible action like deduplication.
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 Package manager is a system that manages your project dependencies.
The package manager provides a method to install new dependencies (also referred to as "packages"), manage where packages are stored on your file system, and offer capabilities for you to publish your own packages.
Each package manager, platform, type, or ecosystem has its own conventions and protocols to identify, locate, and provision software packages.
The following table is a non-exhaustive list of some of the package managers and types referenced in GitLab documentation and software tools.
| Package Type | Package Manager |
|---|---|
| gem | bundler |
| packagist | composer |
| conan | conan |
| go | go |
| maven | gradle |
| maven | |
| sbt | |
| npm | npm |
| yarn | |
| nuget | nuget |
| pypi | setuptools |
| pip | |
| Pipenv | |
| Poetry |
A page that displays Findings discovered in the associated CI Pipeline.
We will provide ways for users to specify criteria that update or modify vulnerability data based on scanner results. Post-filters can help reduce noise and automate manual tasks. Examples include flagging findings as likely False Positives and automatically resolving vulnerabilities that are no longer detected. These are not permanent actions and can be changed.
This will occur in the future, some of the related backlog items are automatically resolve findings and cheap scan.
An irreversible action that is done to filter out target(s) before analysis occurs. This is usually provided to allow the user to reduce scope and noise as well as speed up the analysis. This should not be done if a record is needed as we currently do not store anything related to the skipped/excluded code or assets.
Examples: DS_EXCLUDED_PATHS should Exclude files and directories from the scan based on the paths provided.
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 PluginID, or 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.
A Finding that only exists in a report produced by an Analyzer and is yet to be persisted to the database. The Report Finding becomes a Vulnerability Finding once it's imported into the database.
Describe the type of scan. This includes container_scanning, dependency_scanning, dast, sast, api_fuzzing, coverage_fuzzing, and secret_detection.
This list is subject to change as scanners are added.
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.
When a Report Finding is stored to the database, it becomes a vulnerability Finding.
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.
