An agile culture in service of security
DevSecOps builds on DevOps by embedding security into all phases of the embedded systems development and operations, making security an integral, automated part of the lifecycle from design through deployment and maintenance. DevSecOps thereby gives every project stakeholder a responsibility for security, which they must integrate into their processes. The main goal is to achieve a faster product delivery cycle and a shorter feedback loop, while preventing security flaws in production and thus reducing overall cost.
Embedded systems are increasingly connected and increasingly numerous across your ecosystems…
An embedded system is a device containing digital elements. It consists of hardware and software components with a direct or indirect, logical or physical data connection to a device or network. The proliferation of embedded systems in today’s world (22.3 billion IoT connections at the end of 2025 and more than 47 billion expected by 2031, according to the June 2026 Ericsson Mobility Report) is expanding the attack surface, and these devices are increasingly targeted: according to SonicWall’s 2026 Cyber Protect Report, attacks targeting IoT grew by 11% in 2025. Critical sectors such as automotive, aerospace, healthcare, and energy are directly affected.
… but also, increasingly vulnerable
Embedded systems are becoming the target of attacks that exploit flaws in embedded software stacks as well as vulnerabilities in network communications, particularly when encryption or authentication mechanisms are inadequate. The lack of firmware integrity verification and poor tracking of third-party components, whether proprietary or open source, are also points of weakness. Moreover, when hardware access is possible, physical interfaces (debug ports, internal buses, etc.) represent additional attack vectors. Finally, software update, deployment, and procurement processes have become critical links: compromising firmware, an OTA update, or an element of the supply chain can allow malicious code to be introduced into the very core of the system.
As a result, the attack surface of embedded systems is no longer limited to an isolated component but extends to all their software, hardware, communication, and supply chain, increasing their vulnerability within ever more interconnected ecosystems.
It is therefore critical to integrate security into embedded systems as effectively as possible.
Why can DevSecOps address today’s security challenges for embedded systems?
Implementing a DevSecOps approach in embedded systems development is an answer to these challenges, bringing agility to development. In practice, this approach makes it possible to:
- Anticipate, prevent, and respond more effectively to security flaws
- Through continuous security integration, flaws can be detected much earlier in the product lifecycle, often even before the code is deployed to the hardware. For example, automated static analysis or dependency scanning can catch a vulnerability as early as the development phase, avoiding costly fixes once the product is in the field.
- Anticipate, prevent, and respond more effectively to attacks
- The approach also makes it possible to react faster when an attack occurs. The software bill of materials (SBOM) makes it possible to immediately identify affected products, centralized logging makes it easier to detect abnormal behavior, and the automated pipeline makes it possible to deliver a tested, signed fix via an over-the-air (OTA) update, without waiting for the next release cycle.
- Integrate security as code through automation tools
- This means that security policies, tests, and controls also become automated and versionable, just like application code. Analysis, signing, software composition, and compliance testing tools can be integrated directly into the CI/CD pipeline, ensuring that every build goes through systematic, reproducible checks.
This automation is a game changer: it enables embedded teams to secure their products without relying exclusively on manual audits or external validation.
In addition, fixing a flaw discovered in production can cost 29 to 1,500 times more than if the weakness had been identified in the early design phases, according to a NASA study. This approach therefore naturally leads to an overall reduction in security-related costs.
An adoption that requires more than just a change of tools
However, theory runs up against reality: applying DevSecOps to embedded systems faces constraints that differ from those encountered in traditional IT:
Hardware constraints
Whereas cloud infrastructure can be resized and patched almost instantly, the memory and computing power constraints of embedded systems make these operations much more difficult. Embedded software must be optimized, which complicates the integration of security tools that are often designed for more powerful environments.
Added to this is significant hardware diversity: there are many different operating systems, architectures, and compilation toolchains, each with its own applications. This makes implementing a uniform DevSecOps approach far more complex.
Update constraints
Secure Over-The-Air (OTA) updates are another sensitive issue: they must be reliable, authenticated, and able to revert to a previous version (rollback) in case of failure. While a server can be patched in seconds, an embedded device requires much heavier deployment logistics.
Furthermore, isolated systems (without reliable or continuous connectivity) pose a further challenge, as it is difficult to deliver updates to them reliably and securely.
As for systems already running in production, updating them often requires downtime. It is therefore necessary to minimize disruption, ensure immediate recovery, and make sure the update will not affect operational continuity once deployed.
Regulatory constraints
Regulatory issues are also becoming increasingly important. Regulations such as the CRA in Europe impose strict security requirements on connected devices, such as guaranteeing security updates for several years. In the automotive sector, UNECE Regulation R155 requires continuous risk management and regular security testing, while UN R156 and the Software Update Management System require secure update processes. As a result, the heterogeneity of standards across industrial sectors, the lack of suitable tools, and hardware and software limitations makes it more complex to define a unified DevSecOps strategy.
Organizational constraints
Finally, there are human and organizational challenges: embedded teams do not always have specialized cybersecurity profiles, and Security Champions (security liaisons within product teams) are still rare. It is therefore necessary to invest in training, awareness, and collaboration among developers, testers, and systems engineers.
All these factors make the return on investment difficult to estimate. The initial costs in tools, training, and integration time may seem high, while the benefits (reduced risk, greater resilience, compliance) often only become measurable in the long term.
In other words, applying DevSecOps practices to such constrained systems requires adapting tools, processes, and sometimes even team culture.
Overcoming the challenges with a clear roadmap and suitable technologies
Fortunately, these obstacles are not insurmountable: concrete solutions now exist to support the implementation of DevSecOps in embedded systems. Modern tools such as automated build systems (Yocto, Buildroot, etc.), integrated CI/CD platforms, and specialized SaaS services make it possible to secure the development lifecycle without adding to hardware constraints.
The most effective approach is to proceed step by step, starting by automating the most repetitive, with high-value tasks (static code analysis, automatic image signing, SBOM generation, etc.), then gradually integrating security control tools suited to the target environment. The goal is not to be perfect right away, but to continuously improve security.
Artificial intelligence also multiplies these automation possibilities: triaging and prioritizing alerts raised by static analysis, suggesting fixes, generating unit tests or fuzzing scenarios, and assisting with code review. These uses do not eliminate the need for human validation, but they reduce the effort required from teams and make the approach more accessible.
At the same time, fostering a culture of collaboration and upskilling, for example by appointing security leads and relying on targeted training, makes it easier for teams to adopt new practices.
Thus, with a clear roadmap, suitable technology choices, and strong awareness among product team managers, it becomes possible to overcome these technical and organizational barriers and take full advantage of the benefits of DevSecOps in embedded systems.
Ultimately, DevSecOps is not yet another constraint for embedded systems, but an essential change that must take place in a gradual and controlled manner. It is vital to embrace this evolution as an opportunity to strengthen security for the long term while supporting teams through this transformation.
