Preparing for the EU Cyber Resilience Act: Why DevSecOps maturity matters
Manuel Schuller, DEVOPS INSTITUTE Ambassador
The EU Cyber Resilience Act introduces stricter expectations for software security, prompting organizations to rethink how security is embedded throughout the software development lifecycle. For Manuel Schuller, a DEVOPS INSTITUTE Ambassador and long-time DevOps practitioner, the legislation marks a broader shift towards continuous security, shared accountability, and more mature DevSecOps practices.
Drawing on his extensive experience implementing continuous compliance initiatives within large enterprises, Schuller explains why software bills of materials, CI/CD pipeline security, and cultural transformation will become increasingly important as organizations prepare for the Act's enforcement in December 2027.
One of the most significant changes introduced by the Cyber Resilience Act is the expectation that software products will be secure by design. This will require organizations to strengthen their long-term DevSecOps capabilities, moving away from treating compliance as a standalone activity.
A central requirement of the Act will be the publication of software bills of materials (SBOMs), which provide a detailed inventory of the components used in software applications. Although SBOMs have existed for years in areas such as hardware and Unix environments, many modern software engineers have had limited exposure to the practice. Indeed, developing an SBOM may prove to be one of the biggest challenges in complying with the Act.
The requirement is not entirely new; SBOMs were previously highlighted in the U.S. through the 2021 executive order aimed at improving national cybersecurity, and similar principles were already emerging within the EU. However, the Act formalizes these expectations and places greater pressure on organizations to implement them at scale. For DevSecOps teams, this means that software composition, dependency tracking, and security validation must become integrated parts of the software delivery process.
Why CI/CD pipelines are becoming central to compliance
Continuous integration/continuous delivery (CI/CD) pipelines are essential for organizations to meet the requirements of the Act. Many organizations already incorporate testing and security checks into their continuous integration processes, and generating SBOMs is likely to become another core pipeline function. In fact, given the current state of technology, the only effective way to enforce security checks is through CI/CD pipelines.
This aligns with one of the core principles of DevSecOps: integrating security into development workflows rather than applying it later in the development lifecycle. By automating security validation within CI/CD environments, organizations can improve consistency, reduce manual efforts, and create audit trails that support compliance requirements.
However, technology alone is insufficient. The effectiveness of these security controls largely depends on how organizations define responsibilities and collaboration among teams.
The cultural barriers to DevSecOps adoption
Although DevSecOps promotes shared ownership among development, operations, and security teams, organizational culture remains a major obstacle to successful implementation. There is a longstanding “wall of confusion” between development and operations teams – the very challenge DevOps was originally designed to address. Similar barriers often persist regarding security ownership.
For example, in one large banking organization, I observed that security teams were hesitant to delegate responsibility for security checks to development teams, even though automated controls were already integrated into the CI/CD pipelines. This reluctance can hinder the effectiveness of DevSecOps initiatives by slowing down collaboration and preventing development teams from taking ownership of security earlier in the lifecycle.
The solution lies in further embracing “shift left” practices. By embedding security testing and validation directly into development processes, organizations can ensure that security becomes a shared responsibility rather than a separate gatekeeping function. This means that, before work is sent over the wall, development teams should already be responsible for performing key checks.
Continuous compliance and the importance of traceability
The Act also sets strong expectations for accountability and traceability, areas where continuous compliance practices are becoming increasingly important. In mature DevSecOps environments, continuous compliance allows organizations to automate evidence collection, monitor controls in real time, and maintain visibility throughout the software delivery lifecycle. This approach reduces the burden of manual audits while improving operational resilience and governance.
For example, I recently worked on a large-scale project to implement continuous compliance during a migration to ServiceNow. The organization wanted ServiceNow to serve as a single source of truth for software checks, testing outcomes, and compliance data throughout the software lifecycle. This approach allowed the organization to consolidate information on software components, testing activities, and validation processes into a centralized system that supported both compliance reporting and SBOM creation.
By striving for continuous compliance, organizations can better meet the requirements of the Act.
Closing the gap: Why culture matters more than skills
Despite the extensive changes introduced by the Act, I believe that most organizations do not face significant shortages in technology or skills. Instead, I see the bigger challenge as being organizational culture and the willingness to redefine security ownership models.
Teams already possess the necessary skills and are convinced of the benefits of DevOps and DevSecOps. However, many organizations still lack a shared understanding of how security responsibilities should be distributed across teams. This is why I believe that education and foundational DevSecOps knowledge are essential before embarking on large-scale transformation initiatives. This includes a grasp of the broader DevSecOps ecosystem, the capabilities already available in existing toolchains, and the level of automation needed to support secure modern software delivery.
What successful organizations do differently
Organizations that successfully implement DevSecOps at scale typically demonstrate a strong understanding of their software delivery lifecycle and maintain highly automated delivery pipelines. Equally important are effective monitoring practices.
Mature DevOps and DevSecOps teams continuously measure the effectiveness of their processes using KPIs and operational metrics. This helps ensure that delivery pipelines remain reliable, secure, and adaptable. As regulatory requirements evolve and software supply chains become more complex, operational visibility becomes increasingly critical.
Preparing for 2027: Securing the software delivery pipeline
Looking ahead, I believe organizations should prioritize strengthening and securing their CI/CD pipelines. Those with flexible, well-automated pipelines will be best positioned to meet the requirements of the Cyber Resilience Act. This includes implementing stronger security checks, automating SBOM generation, and establishing the traceability mechanisms needed to support continuous compliance.
Ultimately, the Act should serve as a catalyst for broader DevSecOps maturity. While compliance may be the initial driver, the organizations that benefit most will be those that use this legislation as an opportunity to strengthen automation, collaboration, accountability, and security throughout the software delivery lifecycle.
It’s important to note that the Act will take effect in December 2027. At the pace most organizations are evolving, that timeframe is effectively tomorrow morning.