Starting on September 11, 2026, many businesses that place software on the European Union (EU) market will have 24 hours to file a report once they learn that a vulnerability in one of their products is being actively exploited. This is a new requirement under the Cyber Resilience Act (CRA), the EU law that sets cybersecurity requirements for products with digital elements sold in Europe, put in place to ensure those products are secure by design and supported against new threats. The most stringent requirements under the CRA apply to the manufacturers that make those products, from large software vendors to companies shipping connected hardware.
The challenge a business faces to stay compliant is not the filing itself. It is finding out fast enough that a vulnerability in something you shipped is being actively exploited in your software supply chain. The 24-hour clock starts the moment you become aware, this is why detection is so important. Continuous detection is an engineering solution rather than a one-off compliance one. GitLab's software supply chain security capabilities are built to help you find active exploitation in what you shipped, automatically and continuously. This article walks through four questions you should ask yourself about your own pipeline’s continuous detection solution today.
Reporting requirement starts in September 2026Beginning September 11, 2026, manufacturers have to report an actively exploited vulnerability within 24 hours of becoming aware of it. The reporting runs in three stages each submitted simultaneously to the European Union Agency for Cybersecurity (ENISA) and to the Computer Security Incident Response Team (CSIRT) designated as coordinator.
- Early warning, within 24 hours of becoming aware of the actively exploited vulnerability. A short first alert that exploitation is happening. You are not expected to know the full scope of impact or the fix yet.
- Notification, within 72 hours. A fuller account, covering what is affected, what you know so far, and what you are doing about it.
- Final report. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available.
Deciding whether a vulnerability in your product is reportable is your call. Here are four questions you can ask yourself today to prepare for the CRA, and how GitLab can help you answer each one.
Spot active exploitation in what you already shipped
Is a component in something I shipped being actively exploited right now?
Continuous dependency scanning watches your SBOM and flags newly published advisories against it. KEV status and EPSS scores on each finding tell you which ones attackers are actually using, so you can prioritize the vulnerabilities with real risk. Container Scanning covers the images you ship, and Operational Container Scanning covers what is running in your clusters today.
Find every product and repository affected
Which of my products are impacted, and which repository?
One search in the group-level dependency list returns every project that ships that component. Security attributes tell you which of those are internet-facing or business-critical, so you know where to start. That list is fed from both sides, a CycloneDX SBOM from Dependency Scanning for what your code declares including transitive dependencies, and one from Container Scanning for the OS packages baked into the image. A single search reaches everything in your software supply chain—everything you actually shipped.
Document when a vulnerability was identified
Can I show when I found out?
The activity log on each vulnerability records when it was detected, in which pipeline, and every status change after it with the person and the time attached. The vulnerability events webhook pushes those same moments into whatever system runs your clock. When someone asks when you found out, the answer is already captured.
Show the fix shipped, and when
Did a fix ship, and when?
Dependency scanning auto-remediation opens the upgrade merge request for you. Merge request approval policies can gate on known-exploited status, so the rule holds without anyone relitigating it. Compliance frameworks define the controls behind all of this, the compliance status report tracks where every project stands against them, and the compliance violations report picks up anything that slipped.
Everything else you are already running
Much of the information you will need to assess your reporting obligations under the CRA is already in the GitLab platform your code lives in. The inventory, the exploitation signals, the continuous re-matching, the timestamps, and the policy gates are not five tools to evaluate, buy, and wire together. They are capabilities you turn on in the pipelines you already run, with no new agents and no new data plane.
GitLab's security scanning, including Static Application Security Testing (SAST), Secret Detection, Secret Push Protection, Infrastructure-as-Code (IaC) Scanning, and GitLab's security policies, might not be needed to answer these questions, however, they can help address the next phase of CRA requirements that will arrive in December 2027.
Looking ahead: Stop risky packages before they enter your supply chainGitLab's security capabilities help you respond fast. It is also worth setting your environment up so you have fewer vulnerabilities to report in the first place.
Not every supply chain risk arrives as a Common Vulnerabilities and Exposures (CVE) entry. A package published one character away from a library your team types every day never gets an advisory or a severity score, and neither does a package name that an AI assistant invented that somebody else then registered. There is nothing to patch, because the package itself is the attack.
Looking forward, GitLab will soon allow you to apply a preventative policy at the registry rather than detecting a vulnerability in a review three weeks later, so you can prevent harmful packages from entering into your supply chain before it reaches a build. To get information about the Dependency Firewall closed beta, coming soon, fill out our form.
For existing GitLab customers, try it on one component. Open your group-level dependency list, pick something you know ships in a product, and time how long it takes you to answer all four questions. If the answers come quickly, turn on continuous dependency scanning and add known-exploited status to a merge request approval policy.
If you are not on GitLab Ultimate yet, see if your shipped components carry vulnerabilities known to be exploited in the wild, in one view. Start a free trial.
If you'd like to continue your reading, check out the following: The European Commission's Cyber Resilience Act overview, its reporting obligations page, the summary of the legislative text, and the Commission's implementation guidance.