A normal software release crosses several boundaries: a developer proposes code, a runner builds it, scanners inspect the inputs and image, and someone authorizes the change to proceed. The useful DevSecOps purchase connects those activities. Another scanner dashboard alone does not decide which checks must run or how their results affect a merge or build.
For a growing software team, shortlist GitLab Ultimate when you want security execution and merge approval policy inside the development platform. Compare Harness Security Testing Orchestration, or STO, when you want a configurable security stage around your selected scanners and build workflow. Choose according to the toolchain you intend to operate, rather than assuming either is universally the best DevSecOps software.
This guide primarily serves a platform or engineering lead supporting roughly twenty developers and several containerized services, with technical help available for CI configuration. It compares documented workflows and purchasing boundaries checked on 10 November 2026. No software was installed, pipelines run or detection results measured.
Follow an ordinary change from code to image
DevSecOps software brings security work into software development and operations. In this comparison, the job is to execute checks consistently and connect their output to a development decision. Static application security testing, or SAST, examines source code; dependency analysis examines third-party packages; container scanning examines the built image. A policy then determines the action required from those results.
Consider a hypothetical team shipping ten services. Each change needs source, dependency and container checks, but the developers should not have to reconstruct that requirement from three separate dashboards. The platform team needs to know which jobs ran, which code or image they inspected, and where the resulting decision appears. That is the purchase assessed here, rather than a ranking of scanner accuracy.
A solo developer with one maintained pipeline may not need a commercial orchestration layer. Keep existing CI, add an appropriate scanner such as the open-source Trivy for its supported vulnerability and configuration checks, and maintain the configuration. Trivy is not a substitute for every source-analysis requirement. The simpler route is sufficient only when the actual required checks and review process are covered.
If you are still choosing how to build and deploy software at all, PickMySoft's CI/CD tools guide addresses that earlier decision. Here, the buying trigger is inconsistent security execution across projects or a planned platform consolidation. Buying more scanners will not automatically resolve that problem.
GitLab Ultimate: make policy part of the development platform
GitLab is the first finalist for an organization already using its projects and merge requests, or deliberately consolidating onto them. Its Ultimate security policies distinguish requiring scans from requiring approvals based on results. That separation matters: executing a scanner and deciding whether a change needs approval are different controls.
The documented policy tutorial starts with permission to create projects in a group. A user creates a scan execution policy, configures it through a merge request and links another project to the resulting security policy project. The policy lives separately from the application projects, making the configuration reusable. For an existing estate, inventory projects and runners first, then apply the intended scope rather than creating a policy that nobody has linked.
During ordinary development, a merge request triggers the configured pipeline jobs. The application team examines the findings; the security team maintains the policy and approval criteria; the platform team maintains runner access and CI prerequisites. GitLab's approval documentation ties decisions to reports produced by completed jobs. It also states that approval policies do not authenticate the integrity of those reports. Protecting the pipeline and its credentials remains part of operating the system.
Choose GitLab over Harness when moving the workflow into GitLab is already desirable and reusable, centrally managed merge controls are the main reason to pay. Ultimate is the qualifying tier for these security policies; a lower-tier SAST capability is not equivalent to the governance described here. The policy documentation supports GitLab.com, Self-Managed and Dedicated offerings, but infrastructure responsibility differs by deployment.
There is also a technical dividing line within GitLab. Scan execution policies enforce standard security scans. For custom jobs, scripts or third-party scanners that need enforced CI jobs, GitLab directs readers toward pipeline execution policies. That can reverse the implementation choice even after the platform choice is settled. Keep the distinction in the design instead of trying to fit every scanner into the simplest policy form.
Skip a migration solely to obtain a security results page. Moving repository permissions, build configuration, secrets and developer review habits has a real operational cost. If those systems work today and consolidation has no separate value, compare a narrower orchestration project before moving them.
Harness STO: put security steps around the chosen toolchain
Harness STO is the other finalist when the team wants to select how scans enter the pipeline. Its documented modes are orchestration, ingestion and extraction. Orchestration runs a scan and imports results in one step. Ingestion accepts a results file, including one generated elsewhere. Extraction retrieves results from a supported scanner's API. These are different integration methods, not interchangeable promises of automatic compatibility.
The supported scanner documentation distinguishes Harness-developed scanners, third-party commercial or open-source scanners, and preconfigured open-source steps. Do not assume an STO subscription includes every commercial scanner listed as supported. Identify the actual scanner, integration mode and entitlement on the proposed order. Built-in open-source steps do not require an additional commercial scanner license, but compute and administration still have costs.
A useful example is Harness's documented build-scan-push workflow. It scans Python source with Bandit, builds a test image, scans that image with Trivy and conditionally continues to a production-image step. The example requires STO and CI module licenses, an appropriate security role, repository and registry connectors, access tokens stored as Harness secrets, and a Dockerfile. This is a documentation example, not a workflow we executed.
A platform engineer adapts that sequence to the real service, runner environment and registry. Developers work from findings associated with the pipeline, while security staff set the severity decision and review the chosen scanner configuration. Recurring work includes token rotation, connector permissions, scanner updates and ensuring the configured targets still refer to the intended source and image. A prebuilt step reduces integration code; it does not remove those responsibilities.
Choose Harness over a GitLab consolidation when the chosen scanner integrations and pipeline structure are the stronger fit, and the team accepts operating a Harness security workflow. Ingestion can preserve results from outside that workflow, but it is not evidence that an existing Jenkins or other pipeline becomes governed without integration work. Retain only the parts you have explicitly connected.
For the illustrated build workflow, compare an Essentials bundle that includes CI and STO with a modular Enterprise configuration containing the required modules. The current pricing page quotes both routes. It also says DevOps Essentials has no on-premises deployment support. Deploying applications to an on-premises environment is a different capability from self-hosting the management platform. A buyer requiring the latter should rule out Essentials and evaluate the appropriate Enterprise deployment separately.
Compare the work that each platform takes over
| Decision dimension | GitLab Ultimate | Harness STO configuration |
|---|---|---|
| Development decision | Merge request approval policies evaluate scan reports | Scanner steps and pipeline failure settings affect the configured workflow |
| Security execution | Standard scan policies; pipeline execution policies for custom jobs | Orchestration, file ingestion or API extraction by integration |
| Existing scanners | Custom enforced jobs need the appropriate policy design | Supported third-party integrations; commercial entitlements remain separate |
| Operating prerequisites | Linked policy projects, usable reports, runners and protected target branches | Licensed modules, scanner settings, connectors, secrets and execution infrastructure |
| Purchase boundary | Ultimate subscription and selected hosting model | Essentials bundle or qualifying Enterprise modules; scanner and compute components |
These are comparable operating requirements, not equal-feature checkmarks. For GitLab, the decisive benefit is placing the governance in the platform the team uses for development. For Harness, it is choosing the scan integration and pipeline arrangement. Neither documentation set establishes faster setup or superior detection on your code.
Translate the same release workload into each vendor's units
Use one hypothetical purchase specification: twenty developers, ten private services and 1,000 pipeline executions per month, each with three security-test executions. Require source, dependency and image checks plus an explicit development decision. Compare USD contracts over the same proposed twelve-month period, while asking each vendor to state its actual minimum commitment and seat minimum. Neither qualifying configuration has a verified public subscription total here.
For GitLab Ultimate, obtain the subscription quote for the full licensed population, not just people opening the security page. On GitLab.com, the current pricing page lists 50,000 included compute minutes monthly for Ultimate. As a planning illustration, three jobs taking two minutes each across 1,000 runs would consume 6,000 compute minutes at cost factor one. Two minutes is an assumption, not a measured scan time. Other build jobs, retries and larger runner factors consume additional capacity; included minutes do not prove this entire estate fits.
For Harness, the same workload means 3,000 security-test executions before retries. Its license definitions describe STO in Developer units with 100 security scans per developer per month. Twenty such entitlements represent 2,000 scans arithmetically; ask the order to establish allocation and pooling and cover the additional 1,000 executions. Do not treat 1,000 pipelines as 1,000 scans when three test steps execute in each one.
Request the Harness base subscription, scan allowance and excess-use terms, required CI execution capacity and any retained commercial scanner licenses. Its separately published Essentials usage terms have their own scope; an overage rate from that bundle must not be applied automatically to a modular Enterprise order. For both finalists, price storage, runner infrastructure, support, migration and continuing configuration work separately. Renewal, cancellation and data-retention terms belong in the actual agreement; none is inferred from a per-month usage unit.
For a larger organization, extend the same specification to identity integration, audit access, data location and support commitments. GitLab's Self-Managed option provides a different operating responsibility from SaaS. Harness Essentials' deployment restriction is already publicly answerable; remaining Enterprise hosting and contract details need a qualifying proposal. Do not award an enterprise winner before those requirements are met.
Spend on a maintainable release process
Use a purchasing worksheet with three columns: work retained, work retired and work newly introduced. Put current CI and scanner invoices under retained until a replacement actually permits cancellation. Under introduced, include policy design, integration upkeep and training. Record engineering time separately from expenditure; capacity released is not automatically a cash saving.
Pay for GitLab Ultimate when shared security policy and merge controls solve a recurring coordination problem in a GitLab-centered organization. Pay for Harness when its scanner execution and pipeline choices solve that problem in the toolchain you intend to keep. Stay with existing CI and maintained scanner jobs when the release requirements are already met. The immediate next step is a scoped implementation design and matching workload quote, with named jobs, modules and remaining responsibilities, rather than a platform migration justified by a feature list.
