Security glossary | GitLab Docs Skip to main content Go to GitLab Docs homepage What's new? What's new? Get free trial Toggle menu * Use GitLab * GitLab Duo * GitLab Orbit * Extend * Install * Administer * Subscribe * Contribute * Solutions Getting started Tutorials Manage your organization Organize work with projects Plan and track work Manage authentication and authorization Use Git Manage your code Use CI/CD to build your application Secure your application Getting started Tutorials AI Governance Application security Compliance Detect Triage Analyze Remediate GitLab advisory database CVE ID requests Policies Security glossary Deploy and release your application Manage your infrastructure Monitor your application Analyze GitLab usage Release notes Feature support Find your GitLab version * GitLab Docs / * Use GitLab / * Secure your application / * Security glossary Help us learn about your current experience with the documentation. Take the survey . Security glossary * Tier : Free, Premium, Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated This glossary provides definitions for terms related to security features in GitLab. While some terms may have different meanings elsewhere, these definitions are specific to GitLab. Analyzer Software that analyzes a scan target type for security vulnerabilities. Internally, it is responsible for gathering required configuration parameters and performing necessary data transformations to convert the target into a standardized format for the scanner to execute the scan operation. Finally, it produces a report in the format required by the caller. CI/CD-based analyzers integrate into GitLab using a CI/CD job. The report produced by the CI/CD-based analyzer is published as an artifact after the job completes. GitLab ingests this report, allowing users to visualize and manage found vulnerabilities. The generated reports adhere to the secure report format . Many GitLab analyzers follow a standard approach using Docker to run a wrapped scanner. For example, the image semgrep is an analyzer that wraps the scanner Semgrep . However, some analyzers run directly within GitLab Rails or other target environments rather than in separate containers. Attack surface 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 uses files and line numbers, and DAST uses URLs. Component A software component that makes up a portion of a software project. Examples include libraries, drivers, data, and many more . Corpus The set of meaningful test cases that are generated while the fuzzer is running. Each meaningful test case produces new coverage in the tested program. You should re-use the corpus and pass it to subsequent runs. CNA CVE Numbering Authorities (CNAs) are organizations from around the world that are authorized by the Mitre Corporation to assign CVE s to vulnerabilities in products or services within their respective scope. GitLab is a CNA . CVE Common Vulnerabilities and Exposures (CVE®) is a list of common identifiers for publicly known cybersecurity vulnerabilities. The list is managed by the Mitre Corporation . CVSS The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CWE 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. If left unaddressed, weaknesses could result in systems, networks, or hardware being vulnerable to attack. The CWE List and associated classification taxonomy serve as a language that you can use to identify and describe these weaknesses in terms of CWEs. Deduplication 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 others are eliminated. Read more about the deduplication process . Dependency graph export A dependency graph export lists the direct and indirect dependencies used by a project and the relationships between them. It s generated by a package manager command (for example, go mod graph or mvn dependency:tree ) and output as a file. Related term: lockfile . Dependency version conflict A dependency version conflict occurs when dependency version constraints cannot be satisfied. Consider the following: * Dependency X requires packageA at exactly version 1.0.0 * Dependency Y requires packageA version 1.0.1 or higher In this example, no version of packageA can satisfy both constraints, resulting in a dependency version conflict. Dependency version incompatibility A dependency version incompatibility occurs when a package s version does not satisfy a version constraint. Consider the following: * packageA has versions 1.0.0 and 1.0.1 * Dependency X requires packageA version 1.0.1 or higher In this example, packageA version 1.0.0 does not satisfy the version constraint, and so is incompatible. However, packageA version 1.0.1 does satisfy the constraint. Duplicate finding A legitimate finding that is reported multiple times. This can occur when different scanners discover the same finding, or when a single scan inadvertently reports the same finding more than once. False positive A finding that doesn t exist but is incorrectly reported as existing. Finding An asset that has the potential to be vulnerable, identified in a project by an analyzer. Assets include but are not restricted to source code, binary packages, containers, dependencies, networks, applications, and infrastructure. Findings are all potential vulnerability items scanners identify in MRs/feature branches. Only after merging to default does a finding become a vulnerability . You can interact with vulnerability findings in two ways. * You can open an issue or merge request for the vulnerability finding. * You can dismiss the vulnerability finding. Dismissing the finding hides it from the default views. Grouping A flexible and non-destructive way to visually organize vulnerabilities in groups when there are multiple findings that are likely related but do not qualify for deduplication. For example, you can include findings that should be evaluated together, would be fixed by the same action, or come from the same source. Identifier An identifier is an ID for the vulnerability from an external database, such as Common Vulnerabilities and Exposures (CVE) or Common Weakness Enumeration (CWE). A vulnerability may have multiple identifiers. An identifier is composed of a type (like CVE ) and an ID (like CVE-2021-44228 ). Insignificant finding A legitimate finding that a particular customer doesn t care about. Known affected component A component that matches the requirements for a vulnerability to be exploitable. For example, [email protected] matches the name, package type, and one of the affected versions or version ranges of FAKECVE-2023-0001 . Location fingerprint A finding s location fingerprint is a text value that s unique for each location on the attack surface. Each security product defines this according to its type of attack surface. For example, SAST incorporates file path and line number. Lockfile A file that lists the direct and indirect dependencies of an application and their version numbers. Its purpose is reproducibility, to ensure anyone installing the application s dependencies gets the exact same versions. Some lock files, like Gemfile.lock , also include dependency relationship information, but this is not a requirement. Related term: dependency graph export . Package managers and package types Package managers 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. Package types 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 Pipeline Security tab A page that displays findings discovered in the associated CI pipeline. Possibly affected component A software component that is possibly affected by a vulnerability. For example, when scanning a project for known vulnerabilities, components are first evaluated to see if they match the name and package type . During this stage, they re possibly affected by the vulnerability, and are only known to be affected after it s confirmed that they fall in the affected version range. Post-filter Post-filters help reduce noise in the scanner results and automate manual tasks. You can specify criteria that update or modify vulnerability data based on scanner results. For example, you can flag findings as likely false positives and automatically resolve vulnerabilities that are no longer detected. These are not permanent actions and can be changed. Support for automatically resolving findings is tracked in epic 7478 and support for cheap scan is proposed in epic 7886 . Pre-filter An irreversible action that is done to filter out targets before analysis occurs. This is usually provided to allow the user to reduce scope and noise and speed up the analysis. This should not be done if a record is needed as GitLab doesn t 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. Primary identifier The first identifier is the primary identifier. The primary identifier must be stable. Subsequent scans must return the same value for the same finding, even if the location of the vulnerability has changed. Processor Software that accepts an input and transforms it according to specified criteria, either by modifying the input data or by attaching additional metadata as an output. Processors exist to support scanner operations and are commonly used in pre-scan and post-scan phases. Unlike filters , processors do not have decision-making capabilities to control workflow continuation or termination based on business logic. Instead, they perform transformations and pass the results forward unconditionally. Pre-processor Pre-processors typically perform data preparation tasks such as normalizing input formats, enriching scan targets with additional context, applying target-specific transformations, or augmenting configuration parameters. They ensure that the scanner receives properly formatted and enhanced inputs optimized for the scanning operation. Post-processor Post-processors apply intelligent analysis to scan results after the scanner completes its operation. Post-processors enhance raw scanner output through operations like vulnerability classification, false positive filtering, severity adjustment, and contextual enrichment. Scanner results can pass through multiple post-processors in sequence before the processed results are returned to the analyzer . Reachability Reachability indicates whether a component listed as a dependency in a project is actually used in the codebase. Report finding 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 after it s imported into the database. Scan type (report type) Describes the type of scan. This must be one of the following: * api_fuzzing * container_scanning * coverage_fuzzing * dast * dependency_scanning * sast * secret_detection This list is subject to change as scanners are added. Scan target type A discrete unit of content or artifact that serves as the scope boundary for running the scan. Each scan target type represents a self-contained entity with defined scanning constraints. A specific instance of a scan target type (such as a particular Git repository or container image) is referred to as a scan target . Examples of scan target types include Git repositories, file systems, containers, and so on. Scanner Software that scans for security vulnerabilities in a scan target (an instance of a scan target type ). It is generally a stateless component that receives necessary scan configuration parameters and scan payloads from the analyzer. The resulting scan report is not necessarily in the Secure report format . A scanner can be a sophisticated component that wraps one or more scan engines with additional processors (for example, the secret detection scanner), or it can be as simple as a standalone scan engine (for example, Trivy). Secure product 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, static application security testing (SAST), and fuzz testing. Each of these products typically includes one or more analyzers. Secure report format A standard report format that Secure products comply with when creating JSON reports. The format is described by a JSON schema . Security dashboard Provides an overview of all the vulnerabilities for a project, group, or GitLab instance. Vulnerabilities are only created from findings discovered on the project s default branch. Seed corpus The set of test cases given as initial input to the fuzz target. This usually speeds up the fuzz target substantially. This can be either manually created test cases or auto-generated with the fuzz target itself from previous runs. Vendor The party maintaining an analyzer. As such, a vendor is responsible for integrating a scanner into GitLab and keeping it compatible as it evolves. A vendor isn t 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 subscription, the vendor is listed as GitLab. Vulnerability A flaw that has a negative impact on the security of its environment. Vulnerabilities describe the error or weakness, and don t describe where the error is located (see finding ). Each vulnerability maps to a unique finding. Vulnerabilities exist in the default branch. Findings (see finding ) are all potential vulnerability items scanners identify in MRs/feature branches. Only after merging to default does a finding become a vulnerability. Vulnerability finding When a report finding is stored to the database, it becomes a vulnerability finding . Vulnerability tracking Deals with the responsibility of matching findings across scans so that a finding s lifecycle can be understood. Engineers and security teams use this information to decide whether to merge code changes, and to see unresolved findings and when they were introduced. Vulnerabilities are tracked by comparing the location fingerprint, primary identifier, and report type. Vulnerability occurrence Deprecated, see finding . * Analyzer * Attack surface * Component * Corpus * CNA * CVE * CVSS * CWE * Deduplication * Dependency graph export * Dependency version conflict * Dependency version incompatibility * Duplicate finding * False positive * Finding * Grouping * Identifier * Insignificant finding * Known affected component * Location fingerprint * Lockfile * Package managers and package types * Package managers * Package types * Pipeline Security tab * Possibly affected component * Post-filter * Pre-filter * Primary identifier * Processor * Pre-processor * Post-processor * Reachability * Report finding * Scan type (report type) * Scan target type * Scanner * Secure product * Secure report format * Security dashboard * Seed corpus * Vendor * Vulnerability * Vulnerability finding * Vulnerability tracking * Vulnerability occurrence * Facebook * LinkedIn * Twitter * YouTube Company * About GitLab * View pricing * Try GitLab for free Feedback * View page source * Edit in Web IDE * Contribute to GitLab * Suggest updates Help & Community * Get certified * Get support * Post on the GitLab forum Resources * Terms * Privacy statement * Use of generative AI * Acceptable use of user licenses *