diff options
Diffstat (limited to 'doc/user/application_security/terminology/index.md')
| -rw-r--r-- | doc/user/application_security/terminology/index.md | 70 |
1 files changed, 34 insertions, 36 deletions
diff --git a/doc/user/application_security/terminology/index.md b/doc/user/application_security/terminology/index.md index 772a7d17e1e..df103976901 100644 --- a/doc/user/application_security/terminology/index.md +++ b/doc/user/application_security/terminology/index.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# Secure and Govern terminology **(FREE)** +# Secure and Govern glossary **(FREE)** The glossary of terms aims to achieve the following: @@ -17,9 +17,7 @@ The glossary of terms aims to achieve the following: The definitions of the terms outlined in this document are in the context of the GitLab products. Therefore, a term may have a different meaning to users outside of GitLab. -## Terms - -### Analyzer +## 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). @@ -31,35 +29,35 @@ manage found vulnerabilities. For more information, see [Security Scanner Integr 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`. -### Attack surface +## 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. -### Corpus +## 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. It's advised to re-use the corpus and pass it to subsequent runs. -### CNA +## CNA [CVE](#cve) Numbering Authorities (CNAs) are organizations from around the world that are authorized by the [Mitre Corporation](https://cve.mitre.org/) to assign [CVE](#cve)s to vulnerabilities in products or services within their respective scope. [GitLab is a CNA](https://about.gitlab.com/security/cve/). -### CVE +## 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 +## CVSS The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. -### CWE +## 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, @@ -68,22 +66,22 @@ architecture. If left unaddressed, weaknesses could result in systems, networks, 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 +## 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](../vulnerability_report/pipeline.md#deduplication-process). -### Duplicate finding +## 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 +## False positive A finding that doesn't exist but is incorrectly reported as existing. -### Finding +## 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, @@ -96,32 +94,32 @@ You can interact with vulnerability findings in two ways. 1. You can open an issue or merge request for the vulnerability finding. 1. You can dismiss the vulnerability finding. Dismissing the finding hides it from the default views. -### Grouping +## 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. Grouping behavior for vulnerabilities is under development and tracked in issue [267588](https://gitlab.com/gitlab-org/gitlab/-/issues/267588). -### Insignificant finding +## Insignificant finding A legitimate finding that a particular customer doesn't care about. -### Location fingerprint +## 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. -### Package managers and package types +## Package managers and package types -#### Package managers +### 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 +### Package types Each package manager, platform, type, or ecosystem has its own conventions and protocols to identify, locate, and provision software packages. @@ -215,11 +213,11 @@ table.package-managers-and-types ul { </tbody> </table> -### Pipeline Security tab +## Pipeline Security tab A page that displays findings discovered in the associated CI pipeline. -### Post-filter +## Post-filter Post-filters help reduce noise in the scanner results and automate manual tasks. You can specify criteria that updates or modifies vulnerability data based on scanner results. For example, you can flag findings as likely False Positives @@ -228,7 +226,7 @@ and automatically resolve vulnerabilities that are no longer detected. These are Support for automatically resolving findings is tracked in epic [7478](https://gitlab.com/groups/gitlab-org/-/epics/7478) and support for cheap scan is proposed in issue [349926](https://gitlab.com/gitlab-org/gitlab/-/issues/349926). -### Pre-filter +## 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 as well as speed up the analysis. This should not be done if a record is needed as @@ -236,7 +234,7 @@ we currently do not store anything related to the skipped/excluded code or asset Examples: `DS_EXCLUDED_PATHS` should `Exclude files and directories from the scan based on the paths provided.` -### Primary identifier +## Primary identifier A finding's primary identifier is a value that is unique to each 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) @@ -246,13 +244,13 @@ Examples of primary identifiers include `PluginID` for OWASP Zed Attack Proxy (Z Trivy. 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 +## 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) +## Scan type (report type) Describes the type of scan. This must be one of the following: @@ -266,12 +264,12 @@ Describes the type of scan. This must be one of the following: This list is subject to change as scanners are added. -### Scanner +## 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, Trivy, and ZAP. -### Secure product +## Secure product A group of features related to a specific area of application security with first-class support by GitLab. @@ -281,23 +279,23 @@ Testing (DAST), Secret Detection, Static Application Security Testing (SAST), an Each of these products typically include one or more analyzers. -### Secure report format +## 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 +## 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 +## 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 +## 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 @@ -305,7 +303,7 @@ of the scanner, as in the case of using an open core or OSS project as a base so offering. For scanners included as part of a GitLab distribution or GitLab subscription, the vendor is listed as GitLab. -### Vulnerability +## 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)). @@ -314,12 +312,12 @@ Each vulnerability maps to a unique finding. Vulnerabilities exist in the default branch. Findings (see [finding](#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 +## Vulnerability finding When a [report finding](#report-finding) is stored to the database, it becomes a vulnerability [finding](#finding). -### Vulnerability tracking +## 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 @@ -327,6 +325,6 @@ 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 +## Vulnerability occurrence Deprecated, see [finding](#finding). |