GitLab security scanning in Free vs Ultimate

GitLab security scanning in Free vs Ultimate: what you get without Ultimate

A self-managed GitLab team that has to decide whether Free scanning is enough should start by splitting the scanner list in two. SAST, secret detection and container scanning are the security testing this topic places on the Free side, so a team that only needs code analysis, credential checks and image scanning may not need to buy anything beyond Free for those controls. Dependency scanning, DAST, security policies, vulnerability management and SBOM export sit on the Ultimate side of the scope. Ultimate is custom priced, and it is available for self-managed installations, so the decision is a commercial one that needs a written quote before the architecture is settled.

Do not assume a Free-tier scanner covers everything its name suggests. Before you commit, confirm per-feature availability for your exact GitLab version in the current pricing and feature documentation, and check which analyzer jobs, report types and merge request widgets each tier exposes. The GitLab pricing page is the starting point for tier comparison, but it lists capabilities at a summary level, so the detailed analyzer behavior should be verified in a test project on an instance that matches your production setup, including any offline or air-gapped constraints.

Write the decision down as a short matrix your security and platform leads can sign off: each control you must have, the tier that provides it, the evidence it produces, and who owns the result. Ask the vendor or your partner to quote the Ultimate scope separately from the rest of the platform, because the cost is driven by the number of users or seats in scope and by which features are needed, and the quote should state what recurs annually and what is a one-time setup effort. Revisit the matrix at each required upgrade stop, since scanner availability and templates can change between releases.

GitLab security scanning by tier, side by side

This table compares which scanners and governance features each GitLab tier provides on self-managed instances. Read each row for the capability, then use the final row to match a tier to your team's needs. Premium's scanning coverage is not covered by the supplied pricing facts, so confirm those cells on the pricing page before you decide.

Capability	Free (0 US dollars)	Premium (29 US dollars per user per month, billed annually)	Ultimate (custom priced)
SAST	Included in Free	Confirm on the pricing page	Included under application security testing
Secret detection	Included in Free	Confirm on the pricing page	Included under application security testing
Container scanning	Included in Free	Confirm on the pricing page	Included under application security testing
Dependency scanning	Not included, Ultimate only	Confirm on the pricing page	Included, with SBOM-based scanning as the recommended method
DAST	Not included, Ultimate only	Confirm on the pricing page	Included under application security testing
Security policies and approvals	Not included, Ultimate only	Confirm on the pricing page	Included, as part of software supply chain security
Vulnerability management	Not included, Ultimate only	Confirm on the pricing page	Included, as part of vulnerability management
SBOM export	Not included, Ultimate only	Confirm on the pricing page	Included, confirm export formats on the pricing page
When this tier fits	Teams that want pipeline SAST, secret detection and container scanning at no license cost	Teams that mainly need advanced CI/CD and priority support, after confirming their scanner coverage	Teams that need dependency scanning, DAST, enforced policies, vulnerability management and SBOM export

Choosing Free or Ultimate by environment and risk

Teams on an internet-connected instance often start with scanning inside each project's pipeline. The usual goal is to catch vulnerable code, committed credentials and risky container images before they reach the default branch. Free covers the core of this work.

Static analysis (SAST): runs in merge request pipelines and reports findings against the change under review.
Secret detection: flags credentials in commits so they can be rotated before the branch is merged.
Container scanning: checks images built in pipelines and shows findings in the pipeline and merge request.
Coverage gaps: dependency scanning and DAST are Ultimate features, so teams without them need another control for third-party libraries and running web applications.
Consistency: pipeline templates should be pinned and reviewed so every project runs the same scanners.

Confirm which scanner results your chosen tier displays in merge requests and the security dashboard for your version before you commit to a standard template.

Setting up GitLab security scanning on Free first

This sequence turns on the scanners that GitLab Free includes, proves they run on a test project, and confirms that results and failures reach the people who review merge requests. Each step ends with a check you can record before you widen the rollout.

Confirm edition, license and offline status
The platform team checks the edition and tier on the instance from the Admin Area, and records whether the instance has internet access to GitLab's analyzer images and advisory data. Free covers SAST, secret detection and container scanning, so confirm that no Ultimate-only feature is expected in this first pass. If the instance is offline or air-gapped, stop here and follow the separate offline scanner guidance before the first run, because the analyzer images and vulnerability databases must be available inside your network. The step is complete when the edition, tier and connectivity answers are written down and shared with the security lead.
Create a test project with a known pipeline
Create a dedicated project in a sandbox group with a small, representative codebase and a basic .gitlab-ci.yml. Use a runner that your team controls, and confirm it is online in the project's CI/CD settings. This project exists only to prove the scanners work before they reach production repositories, so keep it free of real credentials. The step is complete when a manual pipeline runs to the end on that runner without configuration errors.
Include the Free scanner templates
Add the GitLab-maintained templates for SAST, secret detection and container scanning to the pipeline configuration through the include keyword, and place each scanner job in a stage that runs for merge requests. Pin the template references to the version your instance supports, and avoid copying template code into the project, so that updates arrive with the GitLab release. Open the pipeline editor and confirm that the merged configuration lists the expected scanner jobs. The step is complete when the editor shows every intended job and no unexpected overrides.
Run scanners on a merge request
Open a merge request in the test project that adds a deliberately vulnerable pattern and a fake secret in a throwaway file, so you can see detection in a controlled setting. Wait for the merge request pipeline to finish and confirm that each scanner job completes with a success or a reported finding, not a silent skip. Check the job logs for analyzer errors, missing images or network timeouts. The step is complete when all three scanner jobs have finished and the logs show the analyzers ran against the changed code.
Review where results appear
Open the merge request widget and the project's Security & Compliance vulnerability report, and compare what each view shows for the same finding. Confirm that the SAST, secret detection and container scanning results are listed with severity, location and status, and note any finding that appears in the job artifact but not in the report. Ask a second engineer to find the same results without help, which tests whether the output is understandable to people outside the pipeline's author group. The step is complete when both views match and the second reviewer can locate and describe each finding.
Check that failures block or warn reviewers
Verify how the pipeline behaves when a scanner fails or finds something. Test a job that fails because of an analyzer error and confirm that the merge request shows a failed pipeline rather than a passing one. Then confirm which findings, if any, your team has configured to fail the pipeline, and whether reviewers see them in the merge request before approval. Free does not give you centrally enforced policies across groups, so record that approvals rely on each project's own settings and reviewer discipline. The step is complete when a scanner failure is visible to the merge request author and reviewers, and the enforcement gap is written down for the Ultimate decision.
Document the baseline before wider rollout
Record the template versions, runner details, scanner job names, the test results and the reviewer checks in a short runbook kept with the platform documentation. Note which projects will receive the same include and which need separate review, such as projects with custom images or restricted runners. Confirm with the security lead which findings are triaged and by whom, so the first real results have an owner. The step is complete when the runbook is stored, reviewed, and linked from the rollout plan for the production groups.

Which capabilities need Ultimate, and what each one changes

The GitLab pricing page places application security testing, software supply chain security, vulnerability management and compliance features in Ultimate, while Free keeps SAST, secret detection and container scanning. Each card below names one Ultimate-gated capability, what the team gives up on Free, and the work needed to cover that gap. Confirm exact availability for your version before you design around it.

Dependency scanning

Dependency scanning checks third-party libraries in your lock files and build outputs against known vulnerability advisories. On Free, you lose automated findings for open-source components, so a vulnerable library can reach production without a pipeline warning. The usual replacement is a separate software composition analysis tool run in CI, with a named owner who reviews its output. Before you plan the gap, confirm which analyzers your Free version runs in pipelines and which languages they cover.

Dynamic application testing

DAST sends requests to a running web application and looks for flaws that static analysis cannot see, such as misconfigured headers or broken session handling. On Free, you lose browser-based dynamic scans launched from pipelines, so testing depends on people remembering to run it. The work becomes choosing a safe staging target, scheduling a scanner outside GitLab, and deciding who triages the results. Confirm that the target can be scanned without touching production data or live customer sessions.

Security policies and enforced approvals

Security policies require specific scanners to run and require named reviewers to approve merge requests that introduce serious findings. On Free, nothing stops a developer from merging a branch whose scan was skipped or ignored, so enforcement moves to people. Replacing it takes branch protection rules, code owner approvals and a periodic report showing which projects skipped required checks. Confirm how policy enforcement is licensed for groups and whether your version supports it at the level you need.

Vulnerability management

Vulnerability management tracks each finding from detection through triage, assignment, fix and closure, with dashboards across projects. On Free, findings still appear in pipeline output, but you lose a central place to assign, track and report on them over time. The replacement is a defined triage workflow in your issue tracker, with severity thresholds, service-level targets agreed internally, and a regular review of open items. Decide who owns the queue before the first scan runs, because unowned findings accumulate quickly.

SBOM export

An SBOM lists the components in a software release, and customers or regulators may ask for it in a standard format such as CycloneDX. On Free, you do not get the dependency list export built into GitLab, so the SBOM must come from a generation step in your pipeline. That step needs a maintained open-source generator, version pinning, storage of each release's SBOM, and a check that it covers the same components your scanners see. Confirm what your version exports before promising SBOMs to a customer.

Compliance features and evidence

Compliance features in Ultimate help teams define framework requirements, track adherence and collect evidence for audits. On Free, that evidence has to be assembled from pipeline logs, approval records and exports, which takes planning. The work is mapping each control to a specific GitLab setting or artifact, documenting where evidence lives, and testing that it can be retrieved. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any attestation. Check the GitLab pricing page for current tier contents.

Why Free scanning is a baseline, not a finished program

Free scanning gives you a consistent check in every pipeline, but it does not enforce that every merge request runs the scanners. A developer can edit a job definition, remove an include or branch around the template, and nothing in Free blocks the merge because a scanner never ran. Treat SAST, secret detection and container scanning in Free as a floor. Before go-live, decide who owns the pipeline template, confirm that every project includes it from one reviewed source, and test in your own instance whether a merge request that drops the scanner job can still merge. Free also does not track findings across releases on its own, so a finding raised last quarter is not automatically linked to the same issue in today's report.

The gap is filled by people. In Free, your team reviews results from each pipeline, decides which findings are false positives, and records accepted risk with a named owner and a review date. Someone has to re-check those decisions when the code or the scanner changes. Teams also build their own evidence: exported reports, pipeline logs and a record showing which scanners ran against which commit and when. Illustrative example: a security engineer spends part of each week matching new container scan results against last month's accepted risks in a spreadsheet. Estimate that effort with your own pilot data, and agree with your owners where the triage record will live before the first audit cycle starts.

DeployOpen prepares controls and evidence for compliance assessments. We can define the pipeline and policy controls, set up where evidence is stored and document how each control operates in your environment. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Before you decide between Free and Ultimate, ask your auditor which evidence they expect for scanning, approvals and vulnerability tracking, and compare that list with the features in the GitLab pricing page. Confirm the current tier details with GitLab, since features move between tiers over time.

Security and operational risks of a Free-only scanning program

A Free-only program can run useful scanners, but the gaps tend to sit around them: pipelines that do not enforce results, findings nobody owns, and exceptions recorded in places no one audits. The cards below cover the risks we see most often and a concrete check for each, drawn from GitLab's hardening guidance.

Scanners configured but not required

A scanner template in .gitlab-ci.yml proves little on its own. A developer can remove the include, a pipeline can be edited on a branch, or the job can be allowed to fail silently. Check that every production project runs the scanner jobs on the default branch and that failures block the merge. Review the pipeline configuration as part of your change control, and confirm which controls GitLab enforces on your tier before you rely on them.

Findings that accumulate without an owner

Free shows vulnerability findings from SAST, secret detection and container scanning, but triage and assignment depend on your own process. Findings left in the report without an owner, due date or status turn into a backlog that nobody reviews. Assign a named owner and a review cadence for each scanner's findings before the first scan runs in production. Decide who closes findings, who accepts risk and where that decision is recorded.

Exceptions handled in comments

Teams often accept a finding by typing a reason into a merge request comment or a chat thread. That record is hard to search, easy to lose and rarely re-reviewed when the code changes. Keep each accepted risk in a versioned file or ticket that names the finding, the justification, the approver and an expiry date. Ask your auditors early which exception evidence they will expect to see, since this is a common point of challenge.

Secret exposure outside detection coverage

Secret detection flags patterns it recognizes, so credentials in unusual formats, in binary files or in artifacts created outside the scanned branches can pass through. Logs, job variables and runner caches are also common places for leaked values. Restrict who can read CI/CD variables, mask and protect sensitive values, and treat secret detection as one layer. Plan rotation for any credential that appears in a repository, whether or not a scanner reported it.

Stale scanner images and advisory data offline

On an air-gapped instance, analyzer images and vulnerability databases stop updating unless you mirror them on a schedule. A scanner can run cleanly while checking against advisories that are months old. Record the date of each mirrored image and database, and alert when the newest copy exceeds the interval you set in your mirror process. Confirm the mirror steps for your analyzers in GitLab's offline documentation before go-live.

Runner isolation for scan jobs

Scan jobs pull images, read source code and often run with broad permissions, so they share the same risk profile as other CI jobs. A shared runner that also builds untrusted merge requests can expose credentials or other projects' code. Run scan jobs on runners dedicated to trusted pipelines, use ephemeral executors where possible, and review which projects can use each runner. Keep Runner versions aligned with your GitLab instance, as the Runner documentation advises.

GitLab security scanning cost, effort and what to ask before hiring help

How much does GitLab Ultimate cost compared with Free and Premium?

GitLab Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually according to the GitLab pricing page, and Ultimate is custom priced. Ultimate is the only tier that includes application security testing such as dependency scanning and DAST, along with software supply chain security, vulnerability management and compliance features, so the price gap is the main cost question. Ask your GitLab account contact for a written Ultimate quote based on your user count and deployment, and compare it with the effort your team would spend building equivalent controls in Free. Premium does not list the Ultimate security features, so confirm each feature against the pricing page before you budget.

What drives the effort to move from Free scanning to Ultimate?

The effort depends on how many projects you need to cover and how much of the security workflow you want enforced rather than advisory. The main drivers are:

The number of groups, projects and pipeline templates that must be updated to include the Ultimate scanners.
Whether you need policies that force scanners to run and require approvals, which adds design and testing work.
How findings feed your vulnerability process, including triage rules, ownership and reporting.
Whether the instance runs offline, which adds mirroring of analyzer images and vulnerability data.

Each driver grows with the number of teams involved, so a scoped plan should count projects and workflows instead of assuming a fixed effort.

How long does it take to set up Ultimate security scanning?

The duration depends on scope, and no fixed timeline is supplied for this work. A reliable estimate comes from a written plan that lists the projects, scanners, policies, integrations and environments in scope, then sequences them with your change calendar. Ask the partner to show which tasks are one-time, such as template design and policy setup, and which are ongoing, such as rescans, tuning and triage. Pilot one or two representative projects before rolling out to the rest, because the pilot reveals false positives, runner constraints and approval conflicts that change the schedule.

What does the work need from our own team?

Most of the work needs people who know your delivery process and can make decisions quickly. Plan for named contributors in these roles:

A GitLab administrator who can change instance settings and approve runner and analyzer configuration.
Security staff who define severity thresholds, accepted-risk rules and who signs off on policy behavior.
Development leads who own the projects being scanned and will triage findings.
A platform or network contact if analyzers must pull images or data from a restricted network.

Ask the partner to list these roles in the plan with the time each one is expected to give, so your team can schedule them before work starts.

Can our team set up Free scanning without outside help?

Yes, a team with GitLab administration and CI/CD experience can enable the Free scanners such as SAST, secret detection and container scanning by adding the documented templates to pipelines. The harder parts are consistency and evidence: applying the templates to every project, deciding how findings are triaged, and keeping the setup working through GitLab upgrades and runner changes. Outside help is most useful for designing the rollout pattern, reviewing the configuration against your risk process, and documenting it for auditors. Whether to hire depends on how many projects you have and how many engineers can give time to the work.

What should a partner deliver in writing before we hire them?

A partner should give you a written scope before work begins, with the following items:

A list of projects, groups, scanners and policies in scope, and what is excluded.
The deliverables, such as configuration as code, pipeline templates, policy definitions, runbooks and a handover session.
The acceptance criteria that show each scanner runs and each policy blocks or requires approval as agreed.
The client responsibilities and dates on which they are needed.
A quote that separates one-time setup from any recurring support or retainer.

DeployOpen works on fixed-scope engagements agreed in writing before work starts, and ongoing support is available as a retainer.

Do Free scanners and Ultimate scanners need the same planning?

No. Free scanning mostly needs template choices, runner capacity and triage rules, while Ultimate scanning adds policy design, approval workflows, vulnerability management and SBOM-related output. Ultimate also changes who must be consulted, because security and compliance owners usually define the policies that block merges. Plan the two as one program with a staged scope so that Free checks reach every project first and Ultimate controls are added where your risk process needs them. Confirm each feature's availability with GitLab's pricing page and documentation before you finalize the design.

Limits to confirm in your environment before you commit

Scanner availability in GitLab depends on your tier, your license settings, your version and how your instance is deployed. The cards below list the limits to confirm before you commit to a scanning design, each checked against GitLab documentation or with your GitLab account team.

Feature availability for your version

Tier placement of scanners, policies and vulnerability management can change between releases, so the feature matrix that applies to Free and Ultimate is the one for your installed version. Confirm for each scanner you plan to run whether it is available in Free, requires Ultimate, or depends on a specific minimum version. Record the version and the date you checked, and repeat the check before each upgrade.

License and cloud licensing settings

A Free or Ultimate license determines which scanning features your instance can use, and some scanners depend on connections to GitLab-hosted services. Confirm that your license covers every tier-restricted feature in your plan and that your cloud licensing settings permit the scanners you intend to use. Ask your account team whether any setting needs to change before the scanners are enabled.

Required upgrade stops and maintenance timing

GitLab requires upgrades to pass through required stops, and scanner behavior can change between releases. Map your current version to the next required stop and plan scanner testing against that release, not the latest one. Also confirm how long your version receives security backports, because a scanner fix may reach only the newest stable release.

Offline mirror readiness

On an air-gapped instance, scanners need analyzer images and vulnerability databases mirrored from outside the network, and those mirrors go stale without a refresh process. Confirm which analyzers your offline plan needs, who owns the transfer pipeline, and how often advisory data will be refreshed. Check the offline guidance for scanners before you assume any scanner works without a connection.

Geo and high availability scope

A Geo secondary site or a high availability design changes where scanner jobs, databases and runners run, and it can change which features apply. Confirm whether your instance is in scope for Geo or a high availability strategy, and whether scan results and vulnerability data replicate to the secondary. Ask the account team how failover affects in-progress scans and stored findings.

How DeployOpen scopes GitLab security scanning work

DeployOpen starts by mapping which scanners your projects need and which GitLab tier covers each one, before any pipeline changes. We then build, test and document the scanning setup inside infrastructure you control, including offline instances where your network requires it.

How we scope

Inventory which projects, languages and container images need SAST, secret detection and container scanning in Free
Identify which Ultimate-only features, such as dependency scanning, DAST and policies, your organization needs and why
Confirm your GitLab edition, network constraints and whether scanner images must be mirrored for an offline instance
Agree the written, fixed scope with deliverables and timelines before any work starts

How we build

Add scanner templates to pipelines in a test group first, then roll them out to production projects in stages
Tune scanner configuration and allowlists so findings reflect real risk and do not block unrelated merge requests
Test results in a staging instance, including failing builds, false positive handling and scan job runtimes on your runners
Document each scanner's tier requirement so later changes to the edition do not break the scanning setup unnoticed

How we hand over

Deliver version-controlled pipeline configuration, scanner settings and a record of what was tested and how
Provide runbooks covering scanner updates, vulnerability database refresh, triage ownership and escalation paths
Walk your security and platform teams through the vulnerability report, dashboards and approval workflow they will own
Document the offline or mirrored setup, if used, so updates can be repeated without the original engineers

How we support

Ongoing support, scanner upgrades and continuous testing are available as a retainer alongside the GitLab instance
Review scanner version changes and GitLab release updates against your pipelines before they reach production
Re-check tier coverage when you change edition, since Ultimate features such as DAST and policies depend on the license
Ask any retainer provider to confirm response scope and update cadence in writing before you sign