--- title: "CRA: automating monitoring in cloud-native pipelines" url: "https://www.sparkfabrik.com/en/blog/cra-compliance-automation-cloud-native-pipelines/" lang: "en" type: "blog-post" date: "2026-07-09" lastmod: "2026-07-09" author: "SparkFabrik Team" description: "The Cyber Resilience Act transforms compliance into a continuous process integrated into pipelines. Learn how to manage the 24-hour vulnerability notification requirement and five-year support through automation." tags: ["Cloud Native","DevOps","Security"] schema: "@context": "https://schema.org" "@type": "BlogPosting" "headline": "CRA: automating monitoring in cloud-native pipelines" "description": "The Cyber Resilience Act transforms compliance into a continuous process integrated into pipelines. Learn how to manage the 24-hour vulnerability notification requirement and five-year support through automation." "url": "https://www.sparkfabrik.com/en/blog/cra-compliance-automation-cloud-native-pipelines/" "datePublished": "2026-07-09T00:00:00+00:00" "dateModified": "2026-07-09T00:00:00+00:00" "author": "@type": "Person" "name": "SparkFabrik Team" "image": "https://www.sparkfabrik.com/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/featured-en.webp" "publisher": "@type": "Organization" "name": "SparkFabrik" "url": "https://www.sparkfabrik.com" "logo": "https://www.sparkfabrik.com/images/logo.svg" --- # CRA: automating monitoring in cloud-native pipelines **Author:** SparkFabrik Team **Published:** 9 July 2026 **Tags:** Cloud Native, DevOps, Security --- {{% tldr %}}With the Cyber Resilience Act, compliance is no longer an annual audit: it becomes a continuous process that lives within pipelines, with obligations such as notifying exploited vulnerabilities within 24 hours and guaranteed updates for five years. However, automating scanners and artifact signing is not enough: legal liability remains with the manufacturer, with fines of up to 15 million euros. The difference between automation that protects and automation that just creates noise lies in signed and versioned evidence.{{% /tldr %}} _Software supply chain security is at the top of security priorities for 2026, and analysts like Gartner and specialized vendors like Chainguard converge on one point: supply chain attacks are no longer a remote possibility, but the preferred entry vector. The problem is no longer knowing what to protect, but how to make it automatic and demonstrable._ With the **Cyber Resilience Act**[^1], compliance stops being an annual audit and becomes a continuous process that lives inside pipelines. The EU regulation imposes security updates for at least five years and the notification of exploited vulnerabilities within 24 hours (as provided for in Article 14)[^2], obligations that are incompatible with sporadic manual checks. It is no coincidence that the European legislator acted after cybercrime exceeded a global cost of 5.5 trillion euros per year as early as 2021[^3], with projections estimating 10.5 trillion dollars in 2025 and 15.63 trillion in 2029[^4]. The scale of technical debt makes the problem concrete. The **2024 OSSRA report** found that 91% of the codebases examined contained components that were ten versions or more behind[^5]. **In the 2026 edition of the OSSRA report, the debt remains real**: 41% of components in codebases are ten versions or more behind, 22% are six to ten versions behind, and 18% are three to five (only 7% are on the latest version). This data must be read in a context where codebase complexity is increasing (+35% file count YoY), the number of components is increasing (+30% YoY), and the number of vulnerabilities per single codebase has more than doubled (+107% YoY).[^6] It is therefore clear that **repeating a manual check of this technical debt for every release, multiplied by five years of mandatory support, is simply unsustainable**. Automating scanners and policies is not enough. Legal responsibility remains with the manufacturer even when a pipeline performs the check. An architecturally correct and **auditable** automation requires rigorous tool selection criteria, native integration into development processes, and the awareness that technical delegation does not transfer the legal burden. ## What does automating Cyber Resilience Act compliance in a cloud-native pipeline mean? Automating CRA compliance means transforming regulatory obligations (SBOM generation, vulnerability scanning, artifact signing, and blocking non-compliant releases) into checks performed automatically at every commit and deployment, integrating them into the software lifecycle rather than applying them downstream as a documentary check. ![Continuous Compliance cycle for the CRA](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-0-en.webp) The methodological foundation lies in the evolution of operational practices, where **security checks anticipate the release phase to integrate directly into the pipeline**. This approach, known as **DevSecOps**, translates the regulatory principle of **security-by-design** into practice. We have described in detail how this model integrates security into the software lifecycle in a [dedicated analysis of DevSecOps applied to the cloud](/en/blog/cloud-devsecops/), which clarifies why automated checks increase release speed instead of slowing it down. The second key concept is **continuous compliance**. The CRA imposes support and security updates for at least five years or for the product's useful life. **Compliance therefore becomes a state to be maintained, not a goal to be reached once.** A secure library today can host a critical CVE tomorrow. Pipelines become the operational arm that re-evaluates compliance at every build, intercepting drift before it reaches production. In practice, four regulatory obligations translate into operational mechanisms. SBOM generation occurs at every build, producing a versioned and machine-readable format. Simultaneously, known vulnerability scanning crosses components with CVE databases. The process then requires signing and verifying the provenance of artifacts placed on the market, culminating in the enforcement of deployment policies to block releases that violate requirements. The operational impact is measurable. According to our experience, a structured approach with integration into CI/CD pipelines, identification of direct and transitive dependencies, crossing with vulnerability databases, and continuous validation, reduces the mean time to remediation (MTTR) of vulnerabilities by up to 80%[^7]. ## Which tools to choose for automated compliance monitoring? The key tools for CRA monitoring in a cloud-native environment are **Syft** for SBOM generation, **Trivy** or **Grype** for vulnerability scanning, **Cosign** and **Sigstore** for signing and verifying artifact provenance, and **OPA Gatekeeper** or **Kyverno** to block non-compliant deployments on **Kubernetes**. ![Map of Cloud Native tools for CRA compliance](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-1-en.webp) Tool selection requires rigorous architectural criteria. Adopting a solution just for its popularity quickly generates operational debt. The parameters we evaluate in our projects are five: native integration with the existing CI/CD pipeline, support for **standard SBOM formats** such as **SPDX** and **CycloneDX**, verifiable signing capability, enforcement model (admission control in production versus scanning at build time) and, above all, the generation of persistent auditable evidence. | Category | Tool | CRA function covered | | ----------------------- | ----------------------- | -------------------------------------------- | | SBOM Generation | Syft | Component inventory in SPDX/CycloneDX | | Vulnerability scanning | Trivy, Grype | Crossing components with CVE databases | | Signing and provenance | Cosign, Sigstore | Integrity and chain of custody of artifacts | | Policy enforcement | OPA Gatekeeper, Kyverno | Blocking non-compliant deployments on Kubernetes | ### SBOM generation and vulnerability scanning Syft[^8], developed by Anchore, **produces SBOMs in standard formats** from container images and filesystems, keeping the moment of inventory separate from the moment of analysis. The actual scanning is done by Aqua Security's Trivy[^9] or Grype, which **cross-reference the detected components with CVE databases**. The relevant operational distinction is between scanning the filesystem, container images, and transitive dependencies. The latter is often the most insidious, because a vulnerable component enters through a third-level dependency that no one explicitly declared. The trade-off to manage is noise: a threshold that is too aggressive generates false positives that paralyze delivery, one that is too permissive nullifies coverage. Prioritization by severity and context is the lever to keep the signal reliable. ### Artifact signing and provenance Cosign, part of the Sigstore project[^10], signs container images and guarantees integrity and provenance, with both key-based and keyless workflows based on ephemeral keys and a tamper-proof transparency log. This aligns the pipeline with the **SLSA** framework for artifact integrity. For the CRA, **signing is central because it demonstrates the chain of custody of artifacts placed on the market**. A signed and verifiable image is the technical proof that the distributed product is the one built by the pipeline, not a binary altered downstream. As members of CNCF and OpenSSF, we have built direct expertise on these tools, also shared in a [vertical technical event on software supply chain security](/it/eventi/tomm-supply-chain-security/) dedicated to the operational use of Sigstore and Kyverno. ### Policy enforcement on Kubernetes OPA Gatekeeper and Kyverno operate as admission controllers. They intercept deployment requests and **block containers without a valid signature or with critical vulnerabilities in real time**, before they reach the cluster. This is the point where policy stops being a recommendation and becomes an applied constraint. The choice between the two depends on who manages the policies. OPA Gatekeeper uses Rego, an expressive language but with a steep learning curve. Kyverno, a CNCF graduated policy engine, defines native Kubernetes policies in YAML, making it more readable for compliance teams not specialized in policy languages. The decision criterion is based on how much the policies must remain inspectable by those responsible for the audit. ## How to integrate policy-as-code controls into DevSecOps pipelines Controls are integrated by defining **policy as code** versioned in the same repository as the code, executing them as blocking gates in CI/CD pipelines, and applying them in production via admission controllers on Kubernetes. This **GitOps** approach makes every change traceable and demonstrable to certification bodies. ![End-to-end flow of the GitOps pipeline with compliance gates](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-2-en.webp) The end-to-end flow passes through precise stages, producing persistent evidence for each. The code commit triggers the pipeline, starting SBOM generation with Syft on the newly built artifact. Immediately after, Trivy or Grype perform the vulnerability scan against CVE databases. If the checks pass, the image is signed with Cosign and recorded in the Sigstore transparency log. A policy gate in CI evaluates the overall results to decide whether to authorize continuation, finally leaving the task of verifying signature and compliance before actual entry into the cluster to the deployment admission control, managed by Kyverno or OPA Gatekeeper. **The GitOps approach ensures that compliance is repeatable.** Policies live in a versioned repository, every change goes through pull requests and reviews, every decision leaves a signed trace. This is exactly the level of rigor required for products that the CRA classifies as critical: container runtimes and hypervisors fall under Annex III as Class II high-risk products[^11], subject to mandatory audit by independent certification bodies. The reference architectural model for setting up these controls is described in the [CNCF white paper on cloud-native security](/en/landing/guida-security-cncf/), which provides the high-level framework on which to build concrete policies. **The most delicate operational trade-off is between blocking gates and informative gates.** Blocking every single vulnerability stops delivery and pushes teams to bypass controls; only informing, without blocking, nullifies compliance because no one acts on the reports. The strategy we adopt is **selective blocking** by severity and context: critical vulnerabilities with known exploits and unsigned artifacts are blocked, others are reported with remediation SLAs. Platform engineering reduces the cognitive load by providing pre-configured pipelines that make compliance the default state. ## Why automation does not transfer CRA legal liability? Automating scanners and policies in pipelines does not shift legal responsibility from the manufacturer to the tool. The CRA attributes responsibility to whoever places the product on the market: even if a pipeline performs the check, it is the company that answers for vulnerabilities and risks sanctions. ![The pillars of auditable automation for legal due diligence](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-3-en.webp) The regulatory principle establishes that the **manufacturer remains responsible** for compliance even when the control is delegated to an automatic system or an AI model. The sanctions, defined in Article 64, make the risk concrete, up to 15 million euros or 2.5% of global annual turnover, whichever is higher, in addition to the possibility for authorities to impose the withdrawal of the product from the market[^12]. Understanding if your software falls into the most severe risk classes is the prerequisite for any automation strategy. We have dedicated an analysis to [CRA risk classes and manufacturer responsibilities](/en/blog/understanding-cyber-resilience-act-compliance/) that frames where each product falls. The architectural consequence dictates that **automation must be auditable**. It is not enough for the pipeline to perform the checks; it must **produce immutable and traceable evidence** that demonstrates due diligence in the event of an incident or audit. In enterprise projects, this means keeping: * **Versioned SBOMs** for each release, traceable to the commit that generated them. * **Archived scan reports** with timestamps and reference CVE databases. * **Sigstore signatures and transparency logs** attesting to the provenance of artifacts. * **Signed policy decision logs** documenting what was blocked and why. **This evidence allows responding to CRA obligations to notify** exploited vulnerabilities within the tight timeframes provided by the regulation, demonstrating that you have acted with diligence. There is also the theme of **shared responsibility** in a cloud-native environment, where those who develop the code, those who manage the platform, and those who operate in production coexist. Policy as code and admission control define explicit boundaries between these roles and reduce human error, because the constraint is codified and not entrusted to the discipline of the individual. Our CTO, Paolo Mainardi[^13], is an Advisory Member of Linux Foundation Europe and has contributed to the #FixTheCRA initiative, created to reconcile the security requirements of the regulation with the sustainability of the open-source ecosystem[^14]. ## Conclusion Automated CRA compliance is not a cost, but a quality accelerator that reduces technical debt and lowers the mean time to remediation of vulnerabilities. The common thread requires adequate tools, native integration into pipelines, and auditable evidence. Detaching one of these three elements compromises the entire system. **If your pipeline runs scanners but does not keep signed and versioned evidence, you are not ready for a CRA audit**, regardless of how many tools you have integrated. The difference between automation that protects the company and one that only generates noise lies in the persistent traceability of every decision. Translating these criteria into a reliable technical strategy requires cross-functional skills across cloud native, security, and compliance, a profile we have summarized in the [requirements for choosing a technology partner in the cloud-native transition](/en/blog/4-requirements-technology-partner-cloud-native-transition/). If you want to evaluate the maturity of your pipeline against CRA obligations, the SparkFabrik team can help you identify architectural gaps before the 2027 deadlines: discover our [supply chain security](/it/servizi/cloud-native-services/supply-chain-security/) services or [contact our experts](/it/contatti/). In the next article in the series, dedicated to the distinction between open-source contributors and commercial manufacturers according to the CRA, we will analyze how responsibility is distributed along the component chain and why the difference between contributing and placing on the market radically changes obligations: from the estimated 90% of products in self-assessment to scenarios where a single upstream contributor risks being called to answer for a completely unexpected use of their code[^15]. ## Notes and sources [^1]: **Cyber Resilience Act**, The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, establishes mandatory cybersecurity requirements for hardware and software products with digital elements placed on the EU market. (source: ) [^2]: **the notification of exploited vulnerabilities within 24 hours (as provided for in Article 14)**, Official text: Article 14 confirms the early warning within 24 hours. (source: ) [^3]: **cybercrime exceeded a global cost of 5.5 trillion euros per year as early as 2021**, CRA documentation explicitly confirms the cost of 5.5 trillion euros reached in 2021. (source: ) [^4]: **projections estimating 10.5 trillion dollars in 2025 and 15.63 trillion dollars in 2029**, confirm the trend of increasing costs of cybercrime. (source: ) [^5]: The 2024 OSSRA report reveals that 91% of the code repositories examined include components that are 10 versions or more behind, highlighting the depth of technical debt accumulated in software dependency management. (source: [SBOM and Cyber Resilience Act: mapping dependency risks](/en/blog/sbom-cyber-resilience-act-dependency-mapping/)) [^6]: **Open Source Security and Risk Analysis (OSSRA)**, The annual Black Duck Open Source Security and Risk Analysis report analyzes the security, license, and operational risks of open-source components in the commercial codebases examined. (source: ) [^7]: The structured approach to SBOM management with integration into CI/CD pipelines, which includes direct and transitive dependency identification, crossing with vulnerability databases, and continuous validation with selective blocking, allows SparkFabrik to reduce the mean time to remediation of vulnerabilities by up to 80%. (source: [SBOM and Cyber Resilience Act: mapping dependency risks](/en/blog/sbom-cyber-resilience-act-dependency-mapping/)) [^8]: **Syft**, Syft is an open-source CLI tool and Go library by Anchore used to generate a Software Bill of Materials (SBOM) from container images and filesystems. (source: ) [^9]: **Trivy**, Trivy is an open-source vulnerability and misconfiguration scanner by Aqua Security. It analyzes container images, filesystems, repositories, and Kubernetes clusters for security issues. (source: ) [^10]: **Sigstore**, Sigstore is an open-source framework by the OpenSSF that enables developers to securely sign and verify software artifacts using ephemeral keys and a tamper-resistant public transparency log. (source: ) [^11]: The Cyber Resilience Act classifies fundamental open-source technologies such as operating systems for servers, desktops, and mobile devices, hypervisors, and container runtimes in Class II of critical products, the one subject to the strictest cybersecurity requirements. (source: [The Cyber Resilience Act, European competitiveness and EU digital sovereignty](/en/blog/cra-updates-open-source-community-listened/)) [^12]: The CRA (Article 64) provides for sanctions up to millions of euros or a percentage of global annual turnover for the most serious violations, with the possibility for national authorities to impose withdrawal or recall of products, prohibition of placement on the market, and the obligation to notify vulnerabilities or incidents within very tight timeframes. (source: [Cyber Resilience Act (CRA)](/en/resources/hot-topics/cra-cyber-resilience-act/)) [^13]: **Paolo Mainardi, Linux Foundation Europe**, Paolo Mainardi is the CTO and co-founder of SparkFabrik and serves on the Advisory Board of Linux Foundation Europe. He specializes in cloud-native technologies and open-source advocacy. (source: ) [^14]: SparkFabrik CTO Paolo Mainardi is an Advisory Member of Linux Foundation Europe and contributes to the #FixTheCRA initiative, created to reconcile the security requirements of the Cyber Resilience Act with the sustainability of the open-source ecosystem. (source: [Cyber Resilience Act (CRA)](/en/resources/hot-topics/cra-cyber-resilience-act/)) [^15]: The Cyber Resilience Act does not distinguish between upstream collaborative development and introduction to the market, and does not limit responsibility to the use intended by the manufacturer: this risks making upstream open-source contributors responsible for vulnerabilities even in completely unexpected contexts of use, as illustrated by Mirko Boehm of Linux Foundation Europe with the example of a contributor who would become responsible if their code were used downstream to control a nuclear power plant. (source: [The Cyber Resilience Act and Concerns for Open Source](/en/blog/cra-and-open-source/)) [^16]: **The CRA attributes responsibility to whoever places the product on the market, with sanctions up to 15 million…**, Official text of the regulation confirming sanctions and manufacturers' responsibilities. (source: ) --- ## Frequently Asked Questions ### What does DevSecOps mean in the context of the Cyber Resilience Act? DevSecOps means integrating security controls as automated gates in CI/CD pipelines, shifting them left in the development cycle. In the context of the CRA, it is the operational model that satisfies the security-by-design requirement because it verifies SBOMs, vulnerabilities, and signatures at every commit instead of during a final inspection. ### What tools are needed to automate CRA compliance in a cloud-native environment? The main tools are Syft for generating the SBOM, Trivy or Grype for vulnerability scanning, Cosign with Sigstore for signing and verifying artifact provenance, and OPA Gatekeeper or Kyverno as admission controllers on Kubernetes to block non-compliant deployments. Together they cover the four automatable CRA obligations. ### Does automating security checks transfer CRA legal responsibility? No. The manufacturer remains responsible for compliance even when the check is performed by a pipeline or an AI model. The CRA attributes responsibility to whoever places the product on the market, with sanctions up to 15 million euros or 2.5% of global annual turnover.[^16] Automation must therefore be auditable. ### What is the difference between OPA Gatekeeper and Kyverno for policy enforcement? OPA Gatekeeper uses Rego, an expressive language but with a steep learning curve. Kyverno defines native Kubernetes policies in YAML, which is more readable for compliance teams. The choice depends on who manages the policies and how much they need to remain inspectable by those responsible for the audit. ### Does the Cyber Resilience Act require the SBOM continuously or as a one-off? Continuously. The SBOM must be generated and updated automatically at every build, because the CRA imposes support and security updates for at least five years or for the product's useful life. A static SBOM drafted at the end of a project does not cover vulnerabilities that emerge during the entire support cycle. --- ## Related Articles - [AgentOps: governing and monitoring AI agents in production](https://www.sparkfabrik.com/en/blog/agentops-governing-monitoring-ai-agents/) - Systems based on probabilistic models require a paradigm shift compared to traditional deterministic … - [AI agent harnesses: the great pricing divergence](https://www.sparkfabrik.com/en/blog/ai-agent-harness-pricing-divergence/) - The real value of artificial intelligence no longer lies solely in the model, but in the … - [Why CTOs choose Drupal: AI, sovereignty, and platform engineering](https://www.sparkfabrik.com/en/blog/why-ctos-choose-drupal-enterprise/) - Modern enterprise architectures require solid foundations to manage critical data and complex … --- *This is a Markdown version of the blog post to facilitate reading by AI and crawlers.* *Visit [https://www.sparkfabrik.com/en/blog/cra-compliance-automation-cloud-native-pipelines/](https://www.sparkfabrik.com/en/blog/cra-compliance-automation-cloud-native-pipelines/) for the full version with images and formatting.*