GitLab Security Specialist cheat sheet

SAST runs on source code with no running app; GitLab SAST is language-specific and uses analyzers (Semgrep-based, SpotBugs, etc.) triggered in CI via the SAST template.

DAST analyzes a running application via HTTP; GitLab DAST requires a deployed target URL and runs as a CI job using the DAST template or on-demand DAST scans.

Dependency Scanning inspects project dependencies for known CVEs; results come from the GitLab Advisory Database and are reported per dependency, not per source file.

Container Scanning checks container images for OS packages and language libraries; it runs after the image is built and can be configured to scan the registry image.

Secret Detection scans repository history and commits for credentials using regex and entropy rules; detected secrets are reported as vulnerabilities and can block pushes via push rules or Secret Push Protection.

License Scanning (License Compliance) identifies dependency licenses and compares them against an allow/deny policy; a denied license produces a policy violation, not a vulnerability.

Coverage-guided fuzzing (API Fuzzing) sends generated requests to API endpoints to find crashes; it requires an OpenAPI/Swagger or HAR specification and a target.

Security scan results appear in the merge request widget, pipeline security tab, and vulnerability report; severity levels are Critical, High, Medium, Low, Info, Unknown.

A scan execution policy (governance) can enforce SAST/DAST/Secret Detection on scheduled or pipeline triggers without editing .gitlab-ci.yml.

Compliance frameworks map controls to GitLab features; a framework is attached to a project or group to produce compliance status and audit evidence.

Compliance pipelines are enforced via compliance frameworks and scan/merge request approval policies in the policy management area.

Merge request approval policies can require approvals based on scan findings (e.g., any Critical vulnerability) and are evaluated at MR creation and on new commits.

Audit events record actions such as project changes, permission changes, and policy edits; they are retained per tier and can be streamed to external destinations.

Separation of duties is implemented via protected branches, protected environments, and approval rules that prevent the author from approving their own MR.

Compliance status is pass/fail per control; failed controls link to the specific project or setting that must be remediated.

Audit event streaming sends events to an external HTTP endpoint or cloud storage; it requires an Ultimate license and a destination configured at group or instance level.

Scan result policies (now merge request approval policies) can block merging when a vulnerability of a defined severity is detected in the MR.

CI/CD variables can be masked, protected, and scoped to environments; masked variables hide values in job logs but do not prevent exfiltration by job code.

Protected variables are only exposed to pipelines running on protected branches or tags; they are not available to feature-branch pipelines.

External secrets integration (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) injects secrets at job runtime via CI/CD components or the secrets keyword.

Secret Detection scans commits and merge requests; Secret Push Protection blocks pushes containing detected secrets before they reach the remote when enabled.

A leaked secret must be revoked/rotated at the source; deleting the commit or file does not remove it from Git history or caches.

Variable precedence: instance < group < project < pipeline < manual job; the most specific scope wins.

Masked variable requirements: value must be at least 8 characters and consist of Base64-compatible characters; otherwise masking is rejected.

ID tokens (OIDC) allow jobs to authenticate to cloud providers without storing long-lived credentials; configure the id_tokens keyword and trust policy on the provider.

The dependency list and dependency graph show direct and transitive dependencies; SBOM export produces CycloneDX JSON for a project or group.

SBOM generation can run in CI via the dependency scanning analyzer or the SBOM API; the output format is CycloneDX, not SPDX, in GitLab.

Dependency Scanning compares component versions against the GitLab Advisory Database and reports CVEs with severity and solution.

Container Scanning uses Trivy-based scanning and reports OS and language package vulnerabilities in the image.

Signed commits and signed tags provide provenance; GitLab verifies GPG/SSH signatures and shows a verified badge.

A merge request approval policy can require approval when a new dependency introduces a vulnerability above a threshold.

License approval policies define allowed and denied licenses; denied licenses block the merge request when the policy is enforced.

Pipeline composition analysis (Ultimate) shows the components and dependencies used in a pipeline, including container images and CI/CD components.

The Vulnerability Report lists findings per project/group with severity, status, and scanner; statuses include Detected, Confirmed, Dismissed, Resolved.

The Security Dashboard summarizes vulnerability trends across projects; it requires at least Developer role for project-level and Reporter for group-level visibility depending on tier.

Vulnerability management allows creating issues from findings, linking them, and tracking remediation status.

Security metrics include vulnerability over time, mean time to detect (MTTD), and mean time to remediate (MTTR); these are derived from finding creation and resolution timestamps.

Scan result policies and approval policies generate audit evidence in the policy management and compliance centers.

The dependency list and SBOM provide inventory visibility; the license list shows license usage per project.

Pipeline security tab shows per-job scan results and allows downloading JSON artifacts for external reporting.

Audit events and compliance reports provide evidence for audits; they can be filtered by entity type, author, and date.