170 lines
7.1 KiB
Markdown
170 lines
7.1 KiB
Markdown
---
|
|
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.
|
|
|
|
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).
|