Security scanning and governance

Forge scans your code, dependencies, container images and deployed environments. It keeps a vulnerability report and records governance events in an audit trail that you can verify. Members read findings. Project administrators triage them and change security settings.

The built-in scanners run inside Forge, so you install nothing to use them.

Built-in scanners

Scanner	What it does
Secret detection	Finds AWS, GitHub, GitLab, Slack, Stripe and Google keys, private keys, Forge tokens, JWTs and hard-coded passwords. A finding names the rule, file and line. The value is never stored.
Pattern SAST	24 line-pattern rules with CWE identifiers for Go, JavaScript and TypeScript, Python, Ruby, Java and PHP. They flag risky calls such as shell commands, `eval`, SQL built by concatenation, disabled TLS checks, unsafe deserialization and weak hashes. Put `forge:ignore-sast` on a line to skip it.
Dependency scanning	Reads lockfiles (`go.mod`, `package-lock.json`, `npm-shrinkwrap.json`, `yarn.lock`, `requirements*.txt`, `Pipfile.lock`, `poetry.lock`, `Cargo.lock`, `Gemfile.lock`, `composer.lock`) and writes a CycloneDX 1.5 SBOM.
Container scanning	Reads the layers of images in the Forge registry, lists the operating system packages and matches them against Alpine and Debian advisories.
Passive DAST	Crawls up to 20 pages of one origin with GET requests only and submits nothing. It reports missing security headers, cookies without Secure, HttpOnly or SameSite, server version leaks, CORS that reflects any origin with credentials, directory listings and error pages that leak stack traces.

Each scan is bounded to 5,000 files, 1 MiB per file, 24 MiB and two minutes. SAST and dependency scans skip vendor/, node_modules/, third_party/ and dist/, and a repository can exclude more path prefixes.

Dependency and container scanning always produce an SBOM. Matching the components against advisories has been tested only against a test advisory source, not yet against a live advisory database. Dependency scanning sends only package names and versions to the advisory source.

Passive DAST targets must be the environment:url of an environment. Private, loopback and link-local addresses are refused.

Run scans

Members run a scan for a branch, a registry image or an environment from the repository’s Security tab. Administrators can turn on automatic scanning, which is off by default.

Committed events queue scans of the default branch and of the sources of open merge requests.
A pushed image tag queues a container scan.
With passive DAST enabled too, a successful deployment queues a scan of its environment.

CI security reports

Jobs can report results from other analyzers. artifacts:reports accepts sast, secret_detection, dependency_scanning, container_scanning and dast as GitLab security report JSON or SARIF 2.1.0, and cyclonedx as an SBOM.

scan:
  script: ./run-analyzer.sh
  artifacts:
    reports:
      sast: gl-sast-report.json

Your runner must support security reports, and a job that declares them needs such a runner. Each report becomes one scan named after its analyzer. Text from reports passes through the secret rules before it is stored, and an unreadable report becomes a failed scan that says why.

Vulnerabilities

Scans of the default branch, of registry images tagged latest and of environments maintain the vulnerability report. A finding is identified by its analyzer, identifier and location, so moving code keeps the same vulnerability.

State	How a vulnerability gets there
Needs triage	A scan detected it
Confirmed	An administrator confirmed it
Dismissed	An administrator dismissed it with a reason and a comment
Resolved	A later scan no longer finds a detected vulnerability. A scan that finds a resolved one again reopens it.

Administrators change states singly or up to 100 at once, and every change is kept in the vulnerability’s history. The report filters by state, severity, analyzer, scanner and text, and exports CSV. A scan of an older commit that finishes late does not undo a newer one.

A merge request shows, per analyzer, the new findings and the findings it fixes compared with the target branch. Every scan keeps its analyzer, version, commit or image digest, ref, pipeline and job. Scans are kept for 90 days, and longer while a report refers to them.

Audit trail

An append-only audit trail copies Forge’s committed events. They cover protections, push rules, approval settings, tokens, SSH keys, runners, CI secrets, merge requests, Git writes, pipelines, deployments, releases, packages, triage and security settings. Each project’s events form a SHA-256 chain, so an edited or removed event breaks verification at that event.

Administrators filter by category, actor, repository, kind, text and dates, export CSV and verify the chain.
Retention is forever by default, or 30 to 3,650 days.
Events can stream to HTTPS destinations. Each post carries X-Forge-Signature: sha256=<HMAC of the body>. A 2xx answer delivers, and 408, 429, 5xx and network errors retry for a day.

Compliance and policies as code

Project administrators use the repository’s Compliance tab.

Frameworks are sets of requirements built from a catalog of 20 controls that Forge evaluates live. Templates: GitLab standard, SOC 2 and Secure SDLC. The compliance status of every repository exports as CSV.
Policies live in a file on the default branch of a linked repository (default .forge/security-policies/policy.yml), so they are reviewed like code. A file with errors enforces nothing. approval_policy requires approvals when a scan finds new vulnerabilities and fails closed when a scanner has no result. approval_settings stop authors and committers approving. scan_execution_policy runs scans on pushes or a schedule.
Exceptions need a reason of at least 10 characters. They apply to one source commit and are audited.
Reports list separation-of-duties violations over a date range (90 days by default) and export the chain of custody of every merged merge request.

Not available

Active DAST Planned
Data-flow SAST Planned
Infrastructure-as-code scanning Planned
License scanning Planned

Also not available are fuzzing, scanning of clusters, work items created from findings, and advisory matching for distributions other than Alpine and Debian. The same goes for group or instance level frameworks, pipeline execution and license policies, custom roles, and audit streaming to cloud services.