diff options
Diffstat (limited to 'doc/user/application_security/terminology/index.md')
-rw-r--r-- | doc/user/application_security/terminology/index.md | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/doc/user/application_security/terminology/index.md b/doc/user/application_security/terminology/index.md new file mode 100644 index 00000000000..8006a49ba35 --- /dev/null +++ b/doc/user/application_security/terminology/index.md @@ -0,0 +1,171 @@ +--- +stage: Secure +group: Static Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers +type: reference +--- + +# Secure and Defend terminology + +This terminology list for GitLab Secure and Defend aims to: + +- Promote a ubiquitous language for discussing application security. +- Improve the effectiveness of communication regarding GitLab's application security features. +- Get new contributors up to speed faster. + +NOTE: **Note:** +This document defines application security terms in the specific context of GitLab's Secure and +Defend products. Terms may therefore have different meanings outside of GitLab Secure and Defend. + +## Terms + +### Analyzer + +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](#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. GitLab ingests this report, allowing users to visualize and +manage found vulnerabilities. For more information, see [Security Scanner Integration](../../../development/integrations/secure.md). + +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`. You can optionally +use the [Common library](https://gitlab.com/gitlab-org/security-products/analyzers/common) +to assist in building an Analyzer. + +### 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. + +### 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](https://cve.mitre.org/). + +### 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. + +### 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. + +### Feedback + +Feedback the user provides about a finding. Types of feedback include dismissal, creating an issue, +or creating a merge request. + +### Finding + +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. + +### Insignificant finding + +A legitimate finding that a particular customer doesn't care about. + +### Location fingerprint + +A finding's location fingerprint is a text value that's unique for each location on the attack +surface. Each Secure product defines this according to its type of attack surface. For example, SAST +incorporates file path and line number. + +### Pipeline Security tab + +A page that displays findings discovered in the associated CI pipeline. + +### Primary identifier + +A finding's primary identifier is a value unique to that finding. The external type and external ID +of the finding's [first identifier](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/v2.4.0-rc1/dist/sast-report-format.json#L228) +combine 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. + +### Report finding + +A [finding](#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](#vulnerability-finding) +once it's imported into the database. + +### Scan type (report type) + +The type of scan. This must be one of the following: + +- `container_scanning` +- `dependency_scanning` +- `dast` +- `sast` + +### Scanner + +Software that can scan for vulnerabilities. The resulting scan report is typically not in the +[Secure report format](#secure-report-format). Examples include ESLint, Klar, and ZAP. + +### 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 include 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](https://gitlab.com/gitlab-org/security-products/security-report-schemas). + +### 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. + +### Vendor + +The party maintaining an analyzer. As such, a vendor is responsible for integrating a scanner into +GitLab and keeping it compatible as they evolve. 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](#finding)). +Each vulnerability maps to a unique finding. + +### Vulnerability finding + +When a [report finding](#report-finding) is stored to the database, it becomes a vulnerability +[finding](#finding). + +### Vulnerability tracking + +Deals with the responsibility of matching findings across scans so that a finding's life cycle 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](#finding). |