search menu icon-carat-right cmu-wordmark

DevSecOps Platform-Independent Model Receives Major Update

DevSecOps Platform-Independent Model Receives Major Update
• Article

November 7, 2022—Recent updates to the Software Engineering Institute’s DevSecOps Platform-Independent Model (PIM) add cybersecurity, personnel role involvement, and DevSecOps main flow features. Version 2.1 of the PIM is now even more useful to organizations that use software development pipelines.

DevSecOps is an engineering practice that promotes collaboration among development, security, and operations. When implemented, it creates a socio-technical system that uses automation for flexible, rapid, frequent delivery of secure infrastructure and software to production. Software development organizations must tailor each DevSecOps pipeline to the people, processes, and technology needed to provide a product or service. Until recently, there was no consistent basis for managing software-intensive development, cybersecurity, and operations in distributed systems.

Then in May, the SEI released version 1.0 of the DevSecOps PIM, a reusable reference architecture for DevSecOps pipelines. Software development organizations can use the online, interactive PIM as a reference architecture or assessment tool for their own DevSecOps pipelines.

The first release of the PIM described a DevSecOps pipeline at the highest level: requirements, the product development lifecycle process, and the organizational roles needed to produce software. Since then, a cross-disciplinary SEI team has added flesh to the PIM’s bones.

The team enhanced the PIM’s cybersecurity by conducting threat modeling workshops on the socio-technical system of the PIM. The resulting high-level threat scenarios included attacks, their actors and effects, and the pipeline assets to protect. Users of the PIM version 2.1 can now use its cybersecurity aspects to create more secure processes and pipelines or spot security weaknesses in existing ones. When the pipeline is more secure, so too is the software it produces.

Those cybersecurity scenarios mesh with the second new part of the PIM, the personnel role involvement model. The PIM team used a RACI matrix—a tool to determine which roles are responsible, accountable, consulted, and informed—to develop a socio-technical view of the software development process. The involvement actions included in the PIM version 2.1 are Approver, Contributor, and Observer, in addition to the standard Performer. Representing these involvement actions previously took a lot of extra modeling but added little value. Version 2.1’s involvement profile simplifies and streamlines these aspects.

The involvement profile enhances the cybersecurity scenarios. “A role can be a performer or an approver of an activity and at the same time can pose an insider threat to it,” said Nataliya Shevchenko, one of the PIM’s creators and the main modeler. “If you look at the roles and cybersecurity separately, you won't see this interaction. But if you put everything in one view, it starts to appear. Then, you can do more analysis and mitigate threats better.”

The final thrust of the update used model-based systems engineering (MBSE) practices and tools and the Unified Architecture Framework (UAF) to create the main flow of the DevSecOps pipeline. “We looked at it as we would look at any other system,” said Shevchenko. “We modeled its requirements, organizational structure, and operational processes, including information and control flows. The DevSecOps pipeline is not a collection of separate things, like a bag of tools. It is a socio-technical system, and it should be modeled as a system.”

Software developers naturally focus on perfecting their products. The SEI is innovating the application of systems engineering to DevSecOps itself. To tackle this task, the PIM team leveraged a digital modeling environment for MBSE, its experience with Department of Defense mission threads, and a recognition of humans not just as users of systems, but integrated components.

The new updates to cybersecurity, role involvement, and DevSecOps main flow make the PIM version 2.1 more robust than ever. Industry and defense organizations are already exploring the PIM for their own software development environments as a reference architecture or as an assessment tool, but Shevchenko says the team has just scratched the surface. Future updates will continue to expand the PIM and add tools for pipeline analysis.

“Software development and operations were much simpler 20 years ago,” Shevchenko said. “Now they have layers and layers of complexity, such as on-premises installations, embedded software, virtual machines, the cloud, and so on.” Shevchenko compares software pipelines to industrial factories, which are as specialized as the products they make. Instead of building software factories ad hoc, development organizations can use the PIM as a consistent and coherent source of best processes and practices for how to build or assess their factories consistently and securely. “DevSecOps for big, software-intensive systems is so complicated these days that you've got to have help managing it and assessing it. That's where the PIM comes in.”

Explore the model at the PIM interactive website. Learn more about the project and the SEI’s DevSecOps research on our website. Read Shevchenko’s blog posts about MBSE, and subscribe to the SEI Blog to be alerted to upcoming posts about the DevSecOps PIM and MBSE. Also watch the SEI website for related podcasts.