GitLab Security Specialist key terms

Automated inspection of third-party libraries and their transitive dependencies to identify known vulnerabilities and license obligations before code ships. In GitLab it runs in CI pipelines and produces dependency findings tied to a project's manifest files.

Analysis of source code without executing it, looking for patterns that indicate security flaws such as injection, unsafe deserialization, or hardcoded credentials. GitLab runs analyzers in CI jobs and reports findings as merge request widgets and pipeline reports.

Black-box testing of a running application by sending crafted requests and observing responses, which surfaces runtime issues like misconfiguration and authentication flaws that static analysis misses. GitLab offers browser-based and API-focused DAST scanners configured through CI variables.

A CI-based job that inventories a project's open-source components and compares them against vulnerability databases. It requires a supported lockfile or manifest and fails or warns depending on configured severity thresholds.

Inspection of container images for vulnerable operating system packages and application libraries, typically run after a build job produces an image. Results appear as pipeline findings and can block promotion when policies require it.

Scanning commits, merge requests, and repository history for credentials such as API keys, tokens, and private keys so they can be revoked before misuse. GitLab supports pipeline-based scanning plus push protection that rejects commits containing detected secrets.

A pre-receive check that blocks a push when a commit contains a value matching a known secret pattern, preventing the credential from ever entering repository history. It complements post-commit scanning, which can only report leaks after they occur.

The practice of replacing a credential with a new value and revoking the old one after exposure or on a schedule. Rotation limits the useful lifetime of a leaked token, so detection without rotation leaves risk unresolved.

A GitLab feature that pulls secrets at job runtime from an external vault such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault instead of storing them in project settings. Secrets are injected as CI variables and never persisted in GitLab.

A setting that hides a variable's value in job logs, replacing it with a masked placeholder. Masking only applies to values meeting character and length rules, and it does not protect secrets that are transformed or split before printing.

A CI/CD variable that is only exposed to pipelines running on protected branches or protected tags. It reduces the blast radius of a compromised feature branch by keeping production credentials out of unreviewed code.

A branch with restrictions on who may push or merge to it, and often the gate that determines which pipelines receive protected variables and protected environment credentials. It is a core control for separating unreviewed work from deployable code.

A policy-as-code rule, stored in a security policy project, that forces specified scanners to run on matching projects, branches, or schedules regardless of what the application's own CI file contains. It enforces minimum testing coverage across a group.

A policy that blocks merging when specified vulnerability conditions are met, such as any critical finding or a newly detected high-severity issue in the diff. It converts scanner output into an enforceable gate rather than a warning.

A dedicated GitLab project that holds policy YAML files and is linked to one or more other projects or groups. Centralizing policies there lets security teams change enforcement without edit rights on every application repository.

A labeled set of compliance requirements attached to projects, which can enforce pipeline configuration, require specific policies, and drive reporting. Frameworks let an organization map GitLab controls to external standards without duplicating configuration per project.

A CI configuration file that a compliance framework injects into every pipeline of labeled projects, adding mandatory jobs such as license checks or custom scanners. It runs in addition to the project's own CI file and cannot be removed by project maintainers.

A record of security-relevant actions in GitLab, such as membership changes, permission grants, setting changes, and policy edits, with actor, timestamp, and target. They support investigations and evidence collection for audits.

Continuous delivery of audit event data to an external destination such as Amazon S3, Google Cloud Storage, or a SIEM endpoint. Streaming preserves evidence outside GitLab and enables correlation with other security telemetry.

The lifecycle of triaging scanner findings, assigning severity and status, tracking remediation, and closing records once fixed or dismissed. GitLab provides vulnerability records, dismissal reasons, and issue links to support this workflow.

The project- or group-level list of all detected vulnerabilities with filters for severity, scanner, status, and activity. It differs from the pipeline security tab, which shows only findings from one pipeline run.

An aggregated view of vulnerability counts and trends across projects in a group or instance, intended for security leadership rather than individual developers. It draws on the same vulnerability records that appear in project-level reports.

Background re-evaluation of a project's dependencies against updated advisory data, so a newly published CVE is flagged even when no new pipeline has run. It closes the gap between scheduled builds and the disclosure of a vulnerability.

A GitLab-side cache for packages and container images pulled from upstream registries, reducing external traffic and centralizing where dependencies are fetched from. It also limits exposure to upstream outages and can support availability-based control of packages.

A GitLab-hosted repository for language packages such as npm, Maven, NuGet, PyPI, and Composer artifacts, published and consumed through CI jobs. Hosting packages internally gives a controlled source of truth for internal libraries.

A GitLab-hosted store for container images built by CI pipelines, addressable per project and per group. Access controls, tag protection, and cleanup policies determine who can push, pull, or delete image tags.

Commits carrying a cryptographic signature from a GPG or SSH key, which GitLab can verify and display as verified. Signature checks help prove that code came from an authorized identity rather than a spoofed author field.

Git tags with a cryptographic signature, used to attest that a release point was created by a trusted maintainer. Verifying tags supports release integrity when artifacts are built from tagged commits.

A tag matching a pattern that only specified roles may create or delete, commonly used to guard version tags that trigger release pipelines. Combined with protected variables, it prevents unreviewed code from reaching production deployments.

A deployment target with restricted deploy access and optional required approvals, ensuring only authorized users or jobs can deploy to it. It is where production credentials and deployment permissions are scoped.

A user or group designated in a CODEOWNERS file as responsible for reviewing changes to matching paths. Code owner approval requirements make review mandatory for sensitive directories such as authentication or infrastructure code.

A control principle that no single person can both author and approve a change, or both configure and audit a control. GitLab supports it through approval rules, role restrictions, and audit review of permission changes.

Detection of the licenses declared by a project's dependencies so that incompatible or disallowed licenses are caught before distribution. Policy can allow or deny specific licenses and flag unknown ones for review.

Automated generation of malformed or unexpected requests against an API definition to find crashes, authorization bypasses, and input handling defects. It requires an API specification such as OpenAPI as input.

A fuzzing technique that mutates inputs while tracking code coverage, steering toward previously unexecuted paths. It finds deeper defects than random fuzzing but requires instrumented builds and longer runtimes.

A scan triggered manually against a branch or commit outside the normal pipeline schedule, useful for validating a fix or testing a release candidate. It runs the same analyzers but is initiated by a user rather than by CI rules.

A downloadable file of vulnerability records, in CSV or JSON, for offline analysis or ingestion into another system. Exports support metrics reporting and evidence retention when combined with scheduled delivery.

Quantitative measures such as mean time to remediate, vulnerability density, and scanner coverage used to judge whether a security program is improving. They are only meaningful when the underlying vulnerability records are triaged consistently.

A library pulled in indirectly because another dependency requires it, rather than one the project declares directly. Transitive dependencies often dominate the component inventory and are a common source of unnoticed vulnerabilities.