How GitLab supports EU Cyber Resilience Act SBOM and vulnerability evidence
If you are a manufacturer placing a product with digital elements on the EU market, GitLab pipelines can produce component inventories, dependency vulnerability lists and build provenance records that feed your Cyber Resilience Act evidence. Conformity assessment, reporting to authorities and the technical file sit outside the platform and must be owned by your compliance and product teams. The dates that matter are set in the regulation: under Article 71(2), the Article 14 reporting obligations apply from 11 September 2026, and the regulation applies in full from 11 December 2027. Under Article 69(2) and (3), products already on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, but reporting obligations apply to all in-scope products whenever they were placed on the market. Confirm these dates against the EUR-Lex text of Regulation (EU) 2024/2847 before you plan around them.
GitLab's dependency list is an Ultimate feature that exports CycloneDX for projects, with licenses and detected or confirmed vulnerabilities per dependency. GitLab Runner can generate SLSA 1.0 provenance in in-toto statement format when RUNNER_GENERATE_ARTIFACTS_METADATA is set to true. Decide which products, repositories and release pipelines must emit these records, then confirm that the exported SBOM format, component identifiers and provenance fields meet what your market surveillance and reporting process needs. Check the exact wording of Annex I, Part II, which lists the vulnerability handling requirements for manufacturers, before mapping any GitLab feature to a requirement. Map each item in your own words, and record which items GitLab covers, which need a separate process such as a vulnerability intake form or a coordinated disclosure policy, and which need a named owner outside the platform.
Keep the SBOM and provenance outputs in the same retention and access controls as your release artifacts, so you can show what shipped in each version. Expect the work to be configuration and pipeline design in your own environment, with a one-time effort to standardize jobs across repositories and a recurring effort to keep scanners, Runner versions and GitLab releases current. Ask any implementation partner for a written scope that names the repositories, pipelines, tier and export format included, and which Cyber Resilience Act obligations are explicitly out of scope.
Mapping CRA requirements to GitLab capabilities and configuration
This table maps Cyber Resilience Act obligations to the GitLab capabilities, configuration and tier that can support them, and marks where GitLab stops and your own processes start. Read each row as a starting point: confirm every requirement against the text of Annex I and the Article it cites, and treat the tier column as the minimum edition to check against the current pricing page. The main takeaway is that GitLab can produce SBOM and vulnerability evidence for your product, but it does not make the product compliant, and reporting and conformity assessment sit outside the platform.
| Requirement | Platform capability | Configuration | Tier |
|---|---|---|---|
| Annex I Part II vulnerability handling (eight requirements, grouped): identify and document vulnerabilities and components, remediate without delay, test and review security, publish fixes and advisories, coordinate disclosure | Dependency list, security scanning, vulnerability management and merge request security reports | Enable dependency and SAST scanning in every product pipeline, set a triage owner for findings, and record remediation in issues linked to merge requests. Confirm each sub-requirement against the Annex text before mapping. | Ultimate for dependency list and vulnerability management |
| Component inventory and SBOM production | Dependency list export as CycloneDX for projects, with licenses and detected or confirmed vulnerabilities per dependency | Generate the CycloneDX export in the release pipeline and store it as a versioned artifact tied to each release tag. Check that the export covers every component your product ships, including container and build-time components where applicable. | Ultimate |
| Build provenance supporting integrity of release artifacts | GitLab Runner SLSA 1.0 provenance in in-toto statement format for build artifacts | Set RUNNER_GENERATE_ARTIFACTS_METADATA to true on runners that build release artifacts, and keep Runner versions aligned with GitLab. Confirm the provenance meets the evidence your assessor expects. | Runner feature; confirm tier needs against the pricing page |
| Annex I Part I product properties (secure by design and default, general requirement and points (2)(a) to (m)) | Not provided by GitLab for the product itself | GitLab hardening covers the build platform, not the product. Use hardening guidance for the GitLab instance and runners, and design product security controls in your own engineering process, documented separately. | Not applicable to the product; confirm your own tooling |
| Article 14 reporting of actively exploited vulnerabilities and severe incidents | Outside GitLab | Define a reporting procedure with named roles and use the ENISA CRA Single Reporting Platform for notifications. GitLab issues can record internal triage timestamps as supporting evidence. | Not applicable to GitLab |
| Article 32 conformity route (self-assessment under module A for most products, notified body for some classes) | Outside GitLab; GitLab records supply evidence for the technical file | Confirm your product class against Annexes III and IV and the Commission FAQ before choosing a route. Keep the SBOM, scan results and provenance in a retained location so the technical file can reference them. | Not applicable to GitLab; a notified body or your own process decides the route |
Evidence GitLab produces and how to keep it for auditors
A GitLab pipeline produces several separate records that support Cyber Resilience Act work: component inventories, build provenance, job logs and review records. Each has its own export path, retention behavior and failure mode, so each needs an owner and a check before an assessment or a reporting event.
CycloneDX dependency list export
The dependency list shows each component a project uses, its licenses, and any detected or confirmed vulnerabilities attached to it. It is an Ultimate feature and can be exported as CycloneDX for projects, alongside JSON and CSV. Export it from each release pipeline so the inventory matches the shipped version, not the default branch on the day you look. Confirm that the export covers the components your product actually ships, including those pulled in at build time, and that the vulnerability status is current when you generate it.
SLSA 1.0 build provenance
When RUNNER_GENERATE_ARTIFACTS_METADATA is set to true, GitLab Runner can generate SLSA 1.0 provenance in in-toto statement format for build artifacts. This record ties an artifact to the repository, commit, pipeline and runner that built it, which is the link auditors and your own team need when they ask where a shipped binary came from. Check that the setting is enabled on every runner that builds release artifacts, that the statements are stored with the artifacts they describe, and that you can verify them outside GitLab.
Pipeline job logs and artifacts
Job logs record what ran, which scanners executed and what they reported, while retained artifacts hold the files produced by a build. Both are subject to expiry settings that can remove them before a vulnerability handling case closes. Review the artifact and log retention values for release projects, keep them longer than your support period for each product, and confirm that they are included in your instance backup scope, since a pipeline record that has expired cannot be recovered from the source repository.
Merge request and approval records
Merge requests show who proposed a change, what was reviewed, which approvals were required and when the change was merged. For vulnerability handling, these records show how a fix moved from a finding to a release. Confirm that approval rules and protected branches were in force during the period you need to evidence, and that audit events are retained outside the default window if your assessor requires a longer history. Ask whether audit events are exported to your own log store.
Backup coverage for the evidence store
Evidence stored in GitLab is only as durable as its backup. Confirm that your backup procedure captures the database, repositories, uploaded files and object storage that hold job artifacts, and that you have also backed up the secrets file needed to read encrypted data after a restore. Test a restore into a separate environment and confirm that the dependency reports, provenance statements and logs you need can be retrieved from it, since an untested backup is not evidence.
Vulnerability records and release tracking
Vulnerability records track each detected or confirmed finding through triage, status change and resolution. Pair them with release versions so you can show which shipped version was affected and when a fix was published. Check that dismissals carry a written reason, that status changes are attributable to a named person, and that the release record names the versions in support. Upgrade GitLab on its documented required stops so the evidence format and features you rely on remain available.
Configuring pipelines that emit SBOM, provenance and vulnerability records
This sequence takes a self-managed GitLab instance from tier selection to a tested release that produces a CycloneDX dependency list, build provenance and a triaged vulnerability record for each build. Each step names the output a reviewer can check before the next step starts.
Confirm the tier for dependency lists
The platform team checks the GitLab pricing page against the scope of the product, because the dependency list is an Ultimate feature. Premium and Free do not include it, so the team confirms the tier with GitLab before any build work starts. Ultimate pricing is custom, so the request for a quote should name the dependency list, vulnerability management and the self-managed deployment model. The step is done when the tier is written into the project plan and the procurement record.
Install GitLab and align runner versions
The infrastructure team installs self-managed GitLab on infrastructure the company controls, using an installation method its operators can maintain. The team then installs GitLab Runner and keeps its major and minor versions aligned with the GitLab instance, as the runner documentation advises. Before continuing, the team checks the instance against the upgrade paths and the maintenance policy so the version chosen is one GitLab still maintains. The step is done when the instance and the runner report matching major and minor versions.
Configure runners for product builds
The build engineers register runners that execute the jobs that compile and package the product, using an executor that suits the build environment. Runners used for release builds should be separate from those running untrusted merge request pipelines, and the team should confirm that protected variables and protected runners restrict them to release branches. The output is a list of runner tags that each release pipeline references explicitly. The step is done when a sample build runs on the intended runner and the job log shows the expected tags.
Enable artifact provenance metadata
The pipeline owners set RUNNER_GENERATE_ARTIFACTS_METADATA to true for the runners that build release artifacts. The runner then produces SLSA 1.0 provenance in in-toto statement format for those artifacts. Engineers should confirm that the variable is set on the runner that builds the release, not only on a test runner. The step is done when a release build's artifacts include a provenance file and the file names the expected project, commit and job.
Export CycloneDX dependency lists per project
The security engineers enable the dependency scanning job in each product project's pipeline and generate the dependency list in CycloneDX format. Each product project gets its own list, because the list reflects the dependencies of that project. The team downloads or exports the file from the pipeline artifacts and stores it alongside the release. The step is done when each project's latest pipeline produces a CycloneDX file that lists the components and the licenses for that build.
Define the vulnerability triage workflow
The product security lead writes a triage procedure that states who reviews new findings, who confirms a vulnerability, who assigns a fix and how a confirmed issue is linked to the release it affects. The procedure should name owners for each role by title, and it should cover the cases where a finding is dismissed with a recorded reason. Engineers configure vulnerability management in GitLab so the owners see the findings they are responsible for. The step is done when the procedure is approved and a test finding moves through each state with the named owner.
Set retention and backup coverage for evidence
The compliance lead decides how long SBOM files, provenance files, dependency lists and triage decisions must be kept, and checks that the chosen retention settings in GitLab meet that decision. Backups of the GitLab instance and its object storage must cover the artifacts and the vulnerability records, and the team should confirm the restore procedure with the backup documentation. Retention periods should come from the organization's legal and regulatory review, not from this guide. The step is done when a restore test returns a previously generated SBOM and provenance file.
Run a test release and check every record
The release manager runs a test release through the full pipeline for one build and checks that each record appears for that build: the CycloneDX dependency list, the provenance file, the vulnerability findings and their triage status. The team compares the build identifier across all records to confirm they point to the same commit and artifact. Any missing record is traced back to the step that produces it before the process is accepted. The step is done when one build carries all four records and the team signs off the checklist.
Keeping vulnerability handling current through GitLab upgrades
A manufacturer's vulnerability handling depends on the GitLab instance it runs on staying on a release line that still receives security fixes. Under the GitLab maintenance policy, bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases. The currently maintained releases are 19.5, 19.4 and 19.3. An instance on any other line will not receive backported security fixes, so the CRA vulnerability handling process that depends on that instance inherits the gap. Confirm the current list against the maintenance policy on the day you plan each upgrade, because the maintained set moves with every monthly release.
Upgrade planning has to respect required upgrade stops. Since GitLab 17.5, these fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11, according to the GitLab upgrade paths documentation. A team that falls behind cannot jump straight to the newest release and must step through each required stop in order. Set a recurring review that compares the running version with the maintained releases and the next required stop, and decide in advance who approves each step, how long a stop-to-stop sequence will take in your environment, and which test instance will rehearse it before production. Treat the upgrade path as a dependency of your security response, not as an optional maintenance task.
Record every upgrade as evidence. For each change, keep the date, the source version, the target version, the stop sequence used, the backup taken beforehand, and the result of post-upgrade checks, and store these records in the same system of record as your merge request and pipeline history. These records show an assessor or market surveillance authority that the instance stayed within a supported security line and that changes to the tooling were controlled. Ask your implementation partner or internal team to confirm how the upgrade log will be generated and retained, and check the upgrade paths documentation before each step rather than relying on memory of past releases.
What GitLab does not cover under the CRA
GitLab can produce evidence from your build and dependency data, but the CRA also asks for conformity processes, documents, reporting and customer communication that sit outside any pipeline. Each card below names who owns the gap and what to confirm before you rely on pipeline output as compliance evidence.
Conformity assessment and notified bodies
Most products follow self-assessment under module A, but class I important products, class II products and critical products can require a notified body depending on which standards you apply in full. GitLab stores test and scan results, but it does not decide whether a conformity assessment is needed or pass one. Your compliance lead owns the classification decision. Confirm your Annex III or Annex IV category and whether harmonized standards will be applied in full before scoping the pipeline evidence.
Technical documentation and EU declaration
The CRA requires technical documentation and an EU declaration of conformity that the manufacturer keeps and makes available to authorities. A GitLab project can hold design records, merge request history and release notes, but it does not generate the declaration or decide what the file must contain. Your regulatory owner writes the file structure and signs the declaration. Confirm with counsel which records must be retained and for how long before setting artifact retention in GitLab.
Reporting to the CSIRT and ENISA
Manufacturers must report actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform, and notifications go to the designated CSIRT and become available to ENISA at the same time. GitLab issues and vulnerability records can feed your triage, but the submission itself is made outside the pipeline by your security response team. Confirm the reporting contacts, the designated CSIRT for your Member State and the internal approval steps before the reporting date.
Support periods communicated to customers
Manufacturers must define how long they will provide security updates and must tell customers about that period. GitLab can show which releases you shipped and which dependencies remain vulnerable, but it does not set the support commitment or notify buyers. Product management owns the period, and legal owns the notice. Confirm the period against the Commission guidance on support periods and record it in your release process so pipeline evidence matches what you promised.
SBOM gaps in binaries and vendored code
A dependency list built from package manager lockfiles misses libraries that are copied into the source tree, linked as prebuilt binaries or bundled into firmware images. GitLab's dependency list can only report components it can detect, and it is an Ultimate feature. Your engineering team owns the inventory of vendored and binary components. Confirm with each component owner how it is declared, and compare the CycloneDX output against a known build before treating it as complete.
Products built outside GitLab
If firmware, embedded images or hardware-adjacent software is built on a separate toolchain, pipeline provenance and SBOM generation in GitLab will not describe those artifacts. The build provenance that GitLab Runner can generate only covers jobs it runs. Your build engineering lead owns the boundary between GitLab and the external build. Confirm which artifacts are produced outside GitLab, and whether their provenance and SBOMs can be generated and attached in a GitLab job.
Which conformity route changes the evidence you need
Most products with digital elements follow self-assessment under module A. The manufacturer checks the product against the essential cybersecurity requirements in Annex I, prepares the technical documentation and issues the EU declaration of conformity without an external body reviewing it. The evidence set is therefore owned in-house and must be complete enough to stand up to a market surveillance authority on request.
- Technical documentation: Keep the SBOM, dependency vulnerability list and build provenance for each release in a form you can produce on request.
- Vulnerability handling records: Show how components are monitored, how vulnerabilities are triaged and how fixes reach customers.
- Declaration and CE marking: The manufacturer signs the declaration of conformity and affixes the CE marking.
- Risk assessment file: Record the cybersecurity risk assessment that drove the design and support period decisions.
Confirm with your legal or product compliance team which category your product falls under before assuming module A applies.
Class I important products listed in Annex III can still use self-assessment, but only when harmonized standards, common specifications or certification schemes are applied in full. Where they are not applied in full, a notified body must assess the product. The evidence then has to satisfy a third party, so gaps in SBOM depth, vulnerability records or provenance are more likely to be questioned.
- Route trigger: Whether you apply the relevant harmonized standards or common specifications in full decides if a notified body is needed.
- Standards mapping: Document which standard clauses your pipelines and processes satisfy and where they fall short.
- Third-party review: Expect the notified body to sample SBOMs, scan results and provenance statements from real release pipelines.
- Standards timing: The Commission's standardization request M/606 sets due dates for the harmonized standards, so track which are published before you commit to a route.
Confirm the category in Annex III and the current state of the standards with your conformity assessment advisor before you plan the notified body engagement.
Class II important products in Annex III and the critical products in Annex IV need a notified body. The notified body assesses the product and the manufacturer's processes against the regulation, so the evidence must be traceable from the product back to the build that produced it. Critical products carry the most demanding route, and the evidence set has to show control over every release.
- Build traceability: Link each released artifact to its pipeline, commit, SBOM and provenance attestation.
- Process evidence: Show that vulnerability handling, triage and disclosure run as defined processes with records.
- Scope of review: Ask the notified body which parts of the technical file it will sample and in what depth.
- Retained records: Keep pipeline logs, scan outputs and approvals for the period the notified body and authorities require.
Confirm with the notified body which evidence formats it accepts before you configure GitLab reporting, since scope and format are set in that engagement.
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. However, the Article 14 reporting obligations apply to all in-scope products whenever they were placed on the market. A product you already sell can therefore carry reporting duties even if its conformity route does not change yet.
- Substantial modification: Decide whether planned changes after the date count as substantial modification, since that brings the full regime into play.
- Reporting readiness: Keep a way to identify affected products and notify actively exploited vulnerabilities and severe incidents.
- Inventory: Maintain a current component and version inventory per product so reports can be scoped quickly.
- Release history: Retain SBOMs and provenance for past releases where possible to support investigations.
Confirm the modification and reporting dates with legal counsel, since they depend on your specific products and release history.
What buyers ask before paying for CRA SBOM and vulnerability setup
Which GitLab tier do I need for CycloneDX dependency lists?
The GitLab dependency list, which exports CycloneDX for projects along with JSON or CSV and shows licenses and detected or confirmed vulnerabilities per dependency, is an Ultimate feature. GitLab Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced, so a quote from GitLab is the only way to confirm Ultimate cost for your user count. Premium covers advanced CI/CD and priority support, but the dependency list itself is not in that tier. Ask your GitLab partner or account team to confirm which features apply to your deployment model, since self-managed availability and pricing can change. Plan the tier decision before building pipelines, because the SBOM and provenance steps depend on which scanners and reports you can use.
How long does CRA SBOM and vulnerability setup take?
No fixed duration applies to every product, so the timeline depends on scope. The main drivers are how many products and projects need SBOMs, how many build pipelines and runners must produce artifacts and provenance, how clean the existing dependency data is, and which conformity route applies. Most products follow self-assessment under module A, while class I important products, class II products and critical products may need a notified body, which adds an external step with its own schedule. Ask for a written scope that lists each product, repository and pipeline, and agree on the deliverables before work starts. Timelines should follow from that scope, not from a generic estimate.
What does the manufacturer need to provide before setup starts?
The manufacturer needs to supply a product inventory, a named build owner for each product or pipeline, and a triage owner who decides what happens to vulnerability findings. Without the product inventory, the SBOM scope is guesswork. Build owners provide access to repositories, runners and existing CI configuration, and they confirm which artifacts ship to customers. The triage owner sets severity handling, approval paths and the process for confirming or dismissing findings. Also prepare a list of third-party components you ship and any open-source software you modify, because these affect the SBOM and the vulnerability handling records. These inputs are often the slowest part of the work, so assign owners early.
Can our own team build this without a partner?
Yes, a capable internal team can build CycloneDX generation, dependency scanning and provenance metadata in GitLab, especially if it already runs GitLab CI/CD and has a security function. The work includes configuring the Ultimate dependency list, enabling runner artifact metadata with RUNNER_GENERATE_ARTIFACTS_METADATA set to true for SLSA 1.0 provenance in in-toto format, and writing the vulnerability handling process. The harder parts are usually the process and evidence: defining who triages findings, documenting how you handle vulnerabilities across the support period, and keeping records that a conformity assessment will accept. Decide early which parts your team will own and which you will outsource, and ask any partner for a fixed-scope written proposal that names each deliverable.
What are the CRA fines, and why plan setup early?
Article 64 of the Cyber Resilience Act sets the maximum administrative fine for breaches of Annex I essential cybersecurity requirements and Articles 13 and 14 at EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other listed obligations carry a maximum of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries EUR 5 million or 1%. Reporting obligations under Article 14 apply from 11 September 2026, earlier than the general application date of 11 December 2027. Products already on the market are only in scope after a substantial modification, but Article 14 reporting applies to all in-scope products. Planning early reduces the risk that you cannot produce SBOMs or report a vulnerability on time.
Does DeployOpen certify that our products comply with the CRA?
No. DeployOpen does not issue audit reports, attestations or certifications. It can plan, implement and document the GitLab pipelines, SBOM generation, dependency vulnerability records and provenance metadata that support your technical file, and it can prepare evidence for a compliance assessment. Conformity assessment is carried out by you under self-assessment for most products, or by a notified body where the regulation requires one. Independent auditors and certification bodies make the compliance determination. Ask any provider to put in writing what they deliver and what remains your responsibility, including the legal conformity decision.
How DeployOpen scopes and delivers CRA evidence configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including self-managed GitLab pipelines that produce SBOMs, dependency vulnerability lists and build provenance. We prepare the systems and evidence for Cyber Resilience Act obligations, and independent assessment bodies make the compliance determination.
How we scope
- Written scope names the products with digital elements, the repositories and pipelines in scope, and the CycloneDX output expected.
- We confirm which GitLab tier supplies the dependency list and scanning features your team will rely on.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- We configure pipelines to generate CycloneDX SBOMs and dependency lists for each build of the product.
- We set up Runner provenance metadata so build artifacts carry SLSA-format attestations tied to the pipeline.
- We test that SBOM, vulnerability and provenance outputs are produced, stored and retrievable for a sample release.
How we hand over
- You receive pipeline configuration, runbooks for vulnerability triage and documented evidence locations.
- Documentation maps each CRA-related artifact to its source job, retention location and owner in your organization.
- We walk your security and release teams through the evidence trail so they can run it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering GitLab upgrade stops and Runner version alignment.
- Retainers can cover updates to the configuration as the Commission publishes further guidance and harmonized standards.
- Ask us to confirm in writing which obligations remain with your organization, since legal and conformity decisions stay with you and your assessor.
