GUEST BLOG: Everything you wanted to know about DevSecOps (but were afraid to ask)

Blog

February 02, 2023

DevSecOps – first defined more than 40 years ago – brings a lot of value to modern development of military embedded systems, as the world sees global instability, ransomware attacks, and shortened development cycle.

Military and aerospace developers work with the realization that a security failure is as bad as – or potentially worse than – failure of quality. A breach of security in software integrated into deployed devices risks more than a loss of data or intellectual property (IP).

Increasingly, these teams are adopting a new development methodology that addresses these security requirements similarly to how they address functional and safety-critical requirements, extending the focus on security throughout the development life cycle.

We recently conducted a survey of U.S. IT decision-makers in the aerospace, aviation, military, and public-sector industries to determine their views on and adoption of the methodology known as DevSecOps. Several of the findings surprised us. While the assumption was that these industries lagged behind the overall software development industry, we found that more than three-quarters (76.1%) of respondents had implemented the practice at every stage of the development cycle. That number increased to more than 4 in 5 (87.5%) respondents working in the aviation industry. One surprise was that the DevSecOps approach is really starting to be applied to mission-critical systems themselves, in addition to the supporting infrastructure.

What is DevSecOps?

A portmanteau of “development,” “security” and “operations,” DevSecOps is an augmentation of development operations (DevOps), a set of practices designed to shorten software and systems development cycles to deliver high-quality code continuously. With DevSecOps, security is integrated and tested at every phase of development rather than as a discrete event conducted by a special quality-assurance team at the end of production.

Development teams benefit from adopting a DevSecOps approach in their ability to deliver code that is more secure, quickly and cost-effectively. According to the DevSecOps Manifesto (a generally agreed-upon set of industry values), “the purpose and intent of DevSecOps (are) to build on the mindset that everyone is responsible for security, with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.”

For veteran development teams, adopting a DevSecOps approach requires a change in mindset, one in which the groups responsible for each of its three components collectively share common goals and accountability. Research has shown that this proactive approach to identifying and repairing security issues earlier in the production cycle is cited as a top benefit of a DevSecOps approach, cited by more than four out of five (82.6%) survey respondents.

Security as an integral part of the development process, as opposed to being an afterthought, is the classic benefit stated for DevSecOps. What was surprising from the survey was that the main driver customers cite for adopting the approach is the need to collapse both development cycles and development costs. One of the clear focuses for this industry is the need to comply with the zero-trust mandate, whereby U.S. Department of Defense (DoD) systems must implement zero trust by the end of FY24. Additionally, systems that were traditionally closed are now required to offer secured connectivity to other systems. One example in on the commercial-aircraft side is the desire to deliver passenger manifests and additional flight and plane data wirelessly, as opposed to via physical media. Both of these trends are causing companies – both in the defense and commercial arenas – to rethink system architectures for both deployed and new products.

Streamlining development, certification

For embedded developers, one of the biggest items that gates software development is access to actual hardware. It either hasn’t been created yet, or there simply isn’t enough of it to serve all parties. Lynx has seen a rapid uptick in harnessing virtual platforms in the cloud to relieve this pinch point. Coupled with this approach, DevSecOps enables the automation of repetitive, manual steps in the development process that are often prone to errors. The continuous integration and continuous deployment methodologies of DevSecOps provide the backstop that not only finds bugs and other quality and security failures but speeds up the time to resolve any issue. There are two challenges that must be addressed.

The first: There are some specific items where the actual hardware has to be harnessed. One example is software that addresses critical real-time system behavior. The second is ensuring that system-certification processes like DO-178C DAL A remain vital for proving the safetyworthiness of platforms. With each line of source code taking hours to certify (and there being millions of lines of software in a platform) the approach that was previously taken was to reduce the codebase that needed to be certified to an absolute minimum.

This iterative DevSecOps approach to software development may seem at odds with the rigorous regulatory, compliance, and documentation requirements of the aerospace industry. Software teams simply need to leverage the tools and techniques used to prove traceability and other proven validation data accurately and in exact terms. Our research backs this up as a need to save time recertifying software was the second most frequently cited reason for adopting DevSecOps (52.7% of respondents).

We are seeing a significantly strong emphasis on the modularity of software. This has other benefits in terms of reducing vendor lock-in, which is outside the scope of this article but is a well-articulated challenge faced by our industry right now:

•        Demanded more frequently: Alignment with the modular open systems approach (MOSA), adherence to Sensor Open System Architecture (SOSA) and the Future Airborne Capability Environment (FACE), and even stronger alignment to standards like POSIX.

•        Suppliers are being asked to prove that these subsystems are isolated and operate independently from each other.

•        From that point, integrators can start to approach certification with a “delta” argument, only certifying new code that is in a specific module as opposed to certifying the entire platform. This technique becomes particularly critical as technologies like AI/ML [artificial intelligence/machine learning] as well as advanced cybersecurity require regular code updates to (respectively) improve the accuracy of the decision-making processes in the system as well as raise the immunity of systems to cyberattack.

 

Ian Ferguson is vice president, marketing and strategic alliances, at Lynx Software Technologies. 

Lynx Software Technologies · www.lynx.com