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: 

1. 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. 
2. 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. 
3. 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. 

Cet article How can DevSecOps transform the security of embedded systems? est apparu en premier sur RiskInsight.

Quantum Threats: a new era for industrial cryptography 

Quantum computing represents a threat to traditional cryptographic algorithms which guarantee integrity, authenticity and confidentiality of communications, including those of OT systems and products. Even if “Q-Day” (the day quantum computers will break current cryptography) is still several years away, the risk is already present: threat actors can already use « Harvest Now, Decrypt Later » attacks by storing encrypted data today to decrypt them as soon as current cryptographic algorithms are broken. Another risk, just as critical, is already appearing: « Trust Now, Forge Later ». Digital signatures or certificates seen as reliable today could be falsified tomorrow, allowing transparent deployment of malwares or even compromising supply chains. Unlike progressive data breach, this attack triggers an immediate collapse of trust and integrity, with massive impacts on industrial environments and smart products. With the European roadmap, structuring 2026, 2030 and 2035, the question hinges on the sequencing of the transition. 

Within the industrial sector, where assets are used for multiple decades, this represents a major concern: OT environments and embedded products depend on critical cryptographic usage that will be directly impacted by the arrival of post-quantum algorithms. 

Key OT and product use cases include: 

• Secure administration of OT systems and products: guarantee the integrity and confidentiality of operations. 
• Digital signatures and firmware integrity: guarantee the reliability of software updates (secure boot, code signing, X.509…). 
• Secure remote access to industrial assets and products: protect VPN, SSH, RDP connections as well as other protocols from future attacks. 
• Data exchanges IT/OT: secure flows between information systems and industrial environments (TLS, MQTTS, HTTPS…). 
• Data confidentiality of industrial processes: preserve the confidentiality of sensitive data in transit or at rest. 
• Secure logging and event history: ensure the traceability and integrity of logs and historical data. 

PQC for OT & Products: Address the constraints while preserving crypto-agility 

OT & Products context: specific constraints 

OT systems and products were never conceived for crypto-agility. Numerous industrial protocols, for instance DNP3, Modbus or MQTT, are not encrypted as of today because OT architecture historically depends more on network isolation than on cryptography, thus there is no reason to think they will be encrypted tomorrow with post-quantum algorithms. 

Nevertheless, encrypted communications will undergo this cryptographic disruption. 

In a second step, multiple OT devices face significant hardware constraints (CPU, memory, storage capacity) and have a very long lifespan, often between 10 and 30 years. Those characteristics make updates difficult and expensive: secure remote update mechanisms are still rare, and firmware signing is not consistently implemented, which is in fact bad practice. 

Those constraints explain why OT environments cannot integrate new cryptographic primitives at the same speed as IT, and why PQC isn’t yet natively considered. 

Nevertheless, even if current products and OT systems aren’t conceived for post-quantum cryptography, the emergence of PQC standards, the evolution of regulatory obligations and the rise of risks linked to quantum computing make this transition essential in the medium term. 

Making crypto-agility operational for the industry and products 

The scoping of the PQC project for Products and OT can be broken down into four main components: 

1. Conduct the cryptographical inventory and prioritize critical assets  

Start the dialogue with your cryptographic platform providers (PKI, KMS, HSM) now, to anticipate the migration. 

2. Conceive and deploy crypto-agile architectures 

Rely exclusively on NIST-standardized algorithms (for instance: ML-KEM, ML-DSA, SLH-DSA) and prohibit any internal development or non-standard library for cryptographical components; prioritizing validated and proven solutions. 

Conceiving crypto-agile architecture implies accounting for the embedded aspect and its constraints (limited memory, PCBs, energy resources). The implementation of PQC algorithms on those systems remains uncertain. Nevertheless, optimized algorithms for embedded systems are starting to emerge and open the way to its realistic adoption. 

3. Progressively migrate through hybridization and iteration  

Transition towards post-quantum cryptography cannot be approached as a one-off project or a “one-shot” migration. It is an iterative process that must be managed and governed over time, by starting with hybridization of algorithms: this is explicitly recommended by ANSSI (France’s National Cybersecurity Agency) and the European Commission. 

Crypto-agility isn’t an option, but a necessity to ensure resilience and compliance for industrial environments and products from the quantum threat. This depends on a structured approach, driven by inventory, architecture, hybrid migration and governance.  

Operational feedback & concrete use cases: stakeholders at different stages 

Our field experience reveals a noteworthy maturity gap between two industrial organizations when dealing with post-quantum cryptography: 

1. Organizations with a rudimentary understanding 

•  Observation: In numerous industrial environments, PQC remains an abstract concept, often seen as distant or limited to experts.  
• Symptoms:  
  • Operational and business teams aren’t part of strategic deliberations on cryptography. 
  • Current roadmaps lack maturity and clarity; the underlying projects costs are often underestimated. Priority remains on service availability; quantum security is therefore deprioritized. 
  • HNDL & TNFL concepts are poorly understood, if not outright ignored.  
• Risks:  
  • Disruption of industrial production processes and data breaches: vulnerable communications between critical assets, based on outdated algorithms, expose sensitive data and can cause interruptions or major disturbances in industrial operations (loss of integrity of the data). 
  • Production downtime caused by abrupt migration: A forced transition towards post-quantum cryptography, without preparation nor crypto-agility, can lead to production interruptions, significant additional costs and severe impacts on operational continuity. 

2. Product suppliers: pioneers already undergoing industrialization 

• Observation: On the contrary, some product suppliers are already ahead (including automotive and smart objects). 
• Symptoms:  
  • PQC projects are prioritized over critical use cases: firmware and update signatures (OTA), device identity management, secure remote access, etc. 
  • Pilot projects are being launched on product lines or representative environments, with concrete feedback on performance, compatibility and robustness of hybrid solutions  
  • The process is being industrialized: Integration of PQC clauses in supplier contracts, automation of cryptographic inventory CBOM, team upskilling, and dedicated governance.

Conclusion & Roadmap: Take action to build a quantum-safe future 

Quantum threat is no longer a distant prospect: it already demands a significant transformation of industrial and product cybersecurity. 

1. Plan ahead to protect the future 

Demystify quantum concepts and incorporate them in your cybersecurity processes, including your products, your OT environments or your IT systems. Planning ahead is the key to preventing a major disruption. 

2. Make crypto-agility a strategic vision

Stop viewing it as merely a technical project, but as a pillar of your resilience and of your digital sovereignty. Build a clear roadmap, with milestones in the short, medium and long term. 

3. Rely on trusted partners 

The market is ready: experts and solutions exist to support you through the modernization and securing of your critical infrastructure. Don’t face complexity on your own.  

4. Industrialize the process

Move from pilot projects to broader rollout:  

• Implement a PQC strategy to map out, prioritize and pilot the migration of critical uses (include PQC clauses in contracts). 
• Start a transition program to modernize trust infrastructure components (PKI, CLM, HSM), automate the inventory and ensure the operational continuity. 
• Rely on peers’ feedback as well as feedback from sectors already engaged in PQC. 

Quantum risk is already there: weakened asymmetric encryption, leaving signatures and data exposed. 

As mentioned previously, we start from the observation that elements that aren’t encrypted today in OT environments are not meant to be encrypted tomorrow with post-quantum algorithms, because already existing measures ensure a risk level judged acceptable. 

In other words, PQC doesn’t aim to transform the entirety of OT, but to protect the uses that really rely on cryptographical components exposed to quantum risk. 

However, this observation doesn’t reduce the importance of planning. 

The two priorities remain as follows: 

• Migrate your assets before 2030 and act today to protect data confidentiality 
• Define your perimeter, build your roadmap, and above all, begin the migration process today. 

Cet article Post-Quantum Cryptography for products & OT: From trends to industrial reality est apparu en premier sur RiskInsight.

What is SBOM, and in what context does it come into play?

 The SBOM (Software Bill of Materials) is a formal inventory, typically in JSON, XML, or plain text format, designed to be machine-readable. It contains detailed information about the software components of a system, including their dependencies, attributes, and hierarchical relationships. The primary goal of an SBOM is to provide a comprehensive and up-to-date view of all the software elements composing an application or system (source: NTIA-Software-Bill-Of-Materials)

Like a physical product, software is a complex assembly of various elements. It includes internally developed code, third-party components (open-source libraries or modules subject to different licenses), as well as all the tools necessary for assembling the final product.

However, with each new vulnerability discovered by researchers or exploited by hackers, suppliers and buyers are faced with a crucial question: where do potential critical vulnerabilities lie within their product?

Today, Wavestone’s analysis formally attests that the SBOM is undeniably an essential element to address this issue.

Generation methods

A comprehensive technical analysis of tools available on the market has revealed the methods for generating Software Bill of Materials (SBOMs).

Three main sources emerge for creating a SBOM:

• Binary Code (compiled)
• Project Source Code
• Image Container, generated by platforms such as Docker.

These three sources can produce a file compliant with established standards, including SPDX and CycloneDX. However, it is essential to note that not all tools support these three inputs uniformly.

The technical challenge lies in decompiling binary code, which can sometimes impede its integration. In such cases, the search for specific predefined indicators within the code proves to be an effective method for identifying most of hierarchical interdependencies in an appropriate format.

Types of Inputs for Generating an SBOM

Despite these code extraction and analysis techniques, data completeness is not guaranteed, and additional verification must be considered.

Facilitated generation but an exploitation that remains to be determined, posing numerous unanswered questions

 The creation of an SBOM has been significantly simplified due to the presence of major players specialized in the market, such as Dependency Track, Adolus, and Fossa, to name a few. Additionally, well-established Software Composition Analysis (SCA) tools within our clients’ development teams now offer the capability to generate and read an SBOM.

Generating it is no longer a major challenge today, thanks to the implementation of the standards mentioned earlier. They facilitate automated SBOM generation by providing clear guidelines on how information about components should be structured and presented. Moreover, many software development and supply chain management tools now natively integrate SBOM creation.

However, the systems designed to analyze SBOMs are not yet fully mature. Clients receiving these inventories often face questions about how to use and share them with other parties. Furthermore, to this technical issue, organizational challenges are added, as the framework for use between organizations has not yet been clearly defined.

Nevertheless, stakeholders are actively working to establish a secure integration architecture for these SBOMs within their CI/CD pipelines.

Currently, obtaining a reliable SBOM from a third party remains a challenge. Concerns about exchange and sharing arise as soon as this topic is addressed. The diversity of contracts with suppliers, who seek to protect their intellectual property, and the challenge of centralization pose hurdles to the content of such inventories. Each inventory is developed heterogeneously, without follow-up or a uniform regulatory framework imposed. From a technical standpoint, each entity has the freedom to report the information of their choice.

As of now, we observe that pioneers in the field are opting for internal generation of their SBOMs, including for third-party software. This approach offers greater control over the quality and specificity of data, underscoring the need for more detailed regulation and stricter standards to ensure the reliability of software inventory exchanges.

The SBOM Integrated into the Core of Your Software Processes

All these gaps have prompted the design of an optimal, theoretically state-of-the-art process to integrate an SBOM into a CI/CD pipeline, a process that can be broken down into a few steps.

1. Creation of an SBOM Generation and Collection Space, Automating the collection of these data to ensure their accuracy and completeness.
2. Storage of SBOMs in a Repository, Configuring a centralized repository to store all generated SBOMs. This could be a version control repository or a suitable data storage system.
3. Distribution of an SBOM Package upon Client Request, Ensuring that SBOMs are easily accessible, and clients can securely retrieve them on demand.

                                   Projection on the Integration of an SBOM within a Software Supply Chain

This theoretical outlook paves the way for the automation of the process of generating, storing, and disseminating inventories and vulnerability reports.

This will provide stakeholders with the ability to:

• Receive real-time SBOMs and vulnerability reports.
• Authenticate the legitimacy of received artifacts (image containers, documents, etc.).
• Establish trust and validation through transparency at the heart of the software production process.

A Bright Future for SBOM?

 Political entities are becoming aware of the level of unpreparedness of their infrastructures in the face of increasing cyber threats. In this context, SBOM is increasingly seen as an effective means to enhance responsiveness to vulnerabilities that could simultaneously affect many companies.

Even though the market is not quite ready for a widespread transition to the use of this solution, it is common for regulation, even if it may seem arbitrary, to profoundly influence the trajectory in a new direction.

It is likely that Europe will eventually converge towards the regulation established in the United States, even though it still seems to be in a preliminary and incomplete stage, especially concerning the mechanisms for sharing and exchanging these inventories.

In the current context, stakeholders are compelled to reassess their priority criteria. It will be important to have data on software composition, the origin of its components, their source, known vulnerabilities, and to trust the production and quality control process.

However, it is necessary to bring back to the agenda the series of challenges they generally face:

• Incomplete or lacking data, the absence of comprehensive data on software composition can make risk assessment difficult.
• Ad hoc approaches for data sharing, non-standardized methods and improvised approaches for information sharing can make communication inefficient and unreliable.
• Additional costs for data collection and maintenance, Collecting, verifying, and updating information on software composition can incur additional costs.
• Lack of standardization, the lack of standards in collecting and sharing data makes it difficult to compare and analyze information among different stakeholders.
• Governance and data privacy, managing sensitive data on software composition raises concerns about its confidentiality, integrity, and availability.

In conclusion, the SBOM serves as a vital ally for the security of your products, enabling transparency, risk reduction, and informed decision-making throughout the software development lifecycle.

Cet article Why is SBOM considered a vital ally for the security of your products? est apparu en premier sur RiskInsight.