DevSecOps is not simply a technology, a pipeline, or a system. It is an entire socio-technical environment that encompasses the people in certain roles, the processes that they are fulfilling, and the technology used to provide a capability that results in a relevant product or service being provided to meet a need. In much simpler terms, DevSecOps encompasses all the best software engineering principles known today with an emphasis on faster delivery through increased collaboration of all stakeholders resulting in more secure, useable, and higher-quality software systems. In this blog post, we present a DevSecOps Platform-Independent Model (PIM), which uses model based system engineering (MBSE) constructs to formalize the practices of DevSecOps pipelines and organize relevant guidance. This first-of-its-kind model gives software development enterprises the structure and articulation needed for creating, maintaining, securing, and improving DevSecOps pipelines.

Although companies have adopted, implemented, and benefited from DevSecOps, many challenges remain in highly regulated and cybersecurity-constrained environments, such as defense, banking, and healthcare. These companies and government agencies lack a consistent basis for managing software-intensive development, cybersecurity, and operations in a high-speed lifecycle. There are standards being published for DevSecOps, such as the recently published IEEE 2675 working group standard, but this guidance and other reference architecture design still requires a considerable amount of interpretation for any particular organization to apply successfully. A reference design does not address strategy, policy, or acquisition, yet organizations are jumping right in to build or acquire the various components outlined in a reference design without the necessary planning or understanding of why certain design decisions were made.

Our team was recently brainstorming on how we could assure a DevSecOps pipeline and possibly prevent attacks that targeted the pipeline, not just the application or system being developed. We realized that it was too challenging to assure a pipeline due to the complexity and lack of a single source of truth of what DevSecOps encompasses. To address this problem, we decided it was best to combine a MBSE approach and enterprise architecture to capture the social, technical, and process aspects of a DevSecOps ecosystem across its lifecycle. The result is a platform-independent model (PIM), which we discuss below.

What Is the DevSecOps Platform-Independent Model and Why Is It Needed?

An authoritative reference is needed to enable organizations to fully design and execute an integrated DevSecOps strategy in which all stakeholder needs are addressed. Most literature discussing DevSecOps depicts it using some variation of the infinity diagram shown in Figure 1 below. This diagram is a high-level conceptual depiction since DevSecOps is a cultural and engineering practice that breaks down barriers and opens collaboration between the development, security, and operations organizations using automation to focus on rapid, frequent delivery of secure infrastructure and software to production.

One example of this collaboration is engineering security into all aspects of the DevSecOps pipeline to demonstrate and test security concerns for both the pipeline and the product. While large organizations have successfully implemented some aspects of DevSecOps on smaller initiatives, they can struggle to implement these same techniques on large-scale projects. Even in small, relatively successful initiatives, substantial loss of productivity can occur when technical debt and insufficient security and operational practices are in place. This loss often results from insufficient knowledge, experience, and reference materials needed to fully design and execute an integrated DevSecOps strategy in which all stakeholder needs are addressed.

While organizations, projects, and teams desire to reap the flexibility and speed expected through the implementation of DevSecOps principles, practices, and tools, the missing reference material must first be addressed to ensure that DevSecOps is implemented in a secure, safe, and sustainable way. We created the DevSecOps PIM to address this need by enabling organizations, projects, teams, and acquirers to

• specify DevSecOps requirements to the lead system integrators tasked with developing a platform-specific solution that includes the designed system and continuous integration/continuous deployment (CI/CD) pipeline
• identify organizational, project, and team knowledge and experience gaps
• assess and analyze alternative pipeline functionality and feature changes as the system evolves
• apply DevSecOps methods to complex products that do not follow well-established software architectural patterns used in industry
• provide a basis for threat and attack surface analysis to build a cyber assurance case to demonstrate that the product and DevSecOps pipeline are sufficiently free from vulnerabilities and that they function only as intended

While one can search “DevSecOps” on the Internet and find a lot of literature that paints a picture of what DevSecOps could be or should be, this literature is not definitive and requires a considerable amount of interpretation, particularly for heavily regulated and cybersecurity-constrained environments. This interpretation results in

• DevSecOps perspectives not being fully integrated in organizational guidance and policy documents
• projects being unable to perform an analysis of alternatives (AoA) regarding the DevSecOps pipeline tools and processes
• multiple projects using similar infrastructure and pipelines in different and incompatible ways, even within the same organization
• suboptimal tools and security controls

To address these problems the DevSecOps PIM provides

• consistent guidance and modeling capability that ensure all proper layers and development concerns relevant to the needs of the organization, project, and team are captured
• the basis for creating a DevSecOps Platform-Specific Model (PSM) that can be incorporated into the product’s model-based engineering approach as the DevSecOps master model is included in the product’s model. This PSM allows proper modeling of DevSecOps design trades within a project’s AoA processes, resulting in less costly and more secure products.
• the basis for metrics and documentation of trade-offs to capture and analyze through the model-based engineering approach. The model provides dynamic matrices of whether those points were addressed, how they were addressed, and how well the corresponding (to the points) module is covered.
• the basis for performing risk modeling against decisions and DevSecOps model-based engineering to ensure security controls and processes are properly selected and deployed

Addressing the Larger Attack Surface of the Project

A DevSecOps pipeline is a means for building products that support an organization’s mission. To build a pipeline, first develop business cases and requirements to ­­­­­define the functions that the various technologies will address. These cases and requirements are further refined, feeding the pipeline and establishing the development cadence for an integrated pipeline and infrastructure, as shown in Figure 2 below.

Tools and infrastructure capabilities are then selected to allow designers, architects, developers, testers, verifiers, users, operators, and other relevant stakeholders to work together to produce the products needed to meet the objectives using the pipeline (as depicted in the Products box in Figure 2). In addition, a parallel group of participants implements and supports the automation that allows product creators to build and facilitate management oversight (as depicted in the Capability Delivery box in Figure 2).

Each of these roles requires specialized technical expertise, and each branch relies on the same tools, repositories, and processes structured through the pipeline. The pipeline must be structured to allow each relevant stakeholder to access what they need to perform their role. Moreover, the processes must be arranged so that each activity flows through the pipeline and is easily handed off from one role to the next all the way from planning to delivery.

The application and pipeline are built incrementally and updated continuously to address changing business requirements, as well as security and technology demands. The pipeline encompasses the intake to the release of software and manages those flows predictably, transparently, and with minimal human intervention/effort .

An organization must be mindful of what it is building to instantiate a DevSecOps pipeline that fulfills its particular needs. Unfortunately, there is no one-size-fits-all pipeline. Each DevSecOps pipeline must be tailored to fulfill the needs of a particular program. In some cases, the capability delivery could be more complicated than the products themselves.

The DevSecOps pipeline is not simply instantiated once and used throughout the product’s lifecycle. Instead, it evolves continuously as the product evolves. The actual automation of processes is realized over time as a pipeline matures. This concept is captured in the DevSecOps PIM through the DevSecOps Capability Delivery Model diagram represented in Figure 3 below. In that figure, the DevSecOps Capability Delivery Model adds several new activities to the traditional DevSecOps infinity diagram to represent the mindful nature of establishing and evolving a project’s capability delivery pipeline.

Figure 3 also depicts an activity flow that begins with business, or mission needs that feed the teams’ planning activities and include the capability delivery needs of the product. In turn, this activity flow feeds the DevSecOps platform-independent model (PIM), which is used to create a DevSecOps PSM that represents the current system and its planned updates, preferably maintained using a model-based system engineering tool.

This DevSecOps PSM captures all socio-technical aspects of the project’s specific capability delivery pipeline. It allows the organization to perform trade-off analyses among alternatives to ensure that the project’s capability delivery pipeline is operating in a cost-effective and secure way, while consistently meeting the needs of the product and all relevant stakeholders.

Based on the PSM, the capability delivery pipeline is configured and instantiated within the Configure DevSecOps System activity. The Configure DevSecOps System activity is analogous to the concept of Infrastructure as Code (IaC) and Configuration as Code (CaC). The product is developed, secured, and operationalized by using the instantiated capability delivery pipeline.

Throughout the lifecycle of the product, data must be collected continuously from both the pipeline and the product under development. This data must be analyzed and evaluated via the Analyze System Feedback activity. If new risks or improvements are identified, such as security vulnerabilities or the possibility of not meeting contractual delivery dates, then the Perform Model Analysis activity is used to evaluate alternatives to the current capability delivery pipeline instantiation. Resulting changes are modeled and then implemented in the Configure DevSecOps System activity, and the process repeats.

Requirements changes require risk analysis, as well as an evaluation of the capability delivery that may be impacted. Even with all this analysis and work, we haven’t yet addressed what the DevSecOps Infinity diagram really represents. From a high-level modeling perspective, the DevSecOps Infinity diagram is simply represented as the Product Under Development Main Flow activity shown in Figure 3 above. Breaking out the infinity diagram to the next level of abstraction would look like figure 4 below. The complexity of the DevSecOps pipeline grows quickly, which motivates us to explore why a DevSecOps Platform-Independent Model is needed.

Large, complex, heavily regulated, and cybersecurity-constrained projects have already embraced model-based engineering but have not applied the same techniques to their DevSecOps CI/CD pipelines. This limitation impedes a project’s ability to build a cyber-physical software factory that is fit for purpose. Establishing a DevSecOps PIM enables projects to develop a robust framework for creating a customized model where the system’s architecture and the DevSecOps pipeline architecture are not in conflict and where they address the larger attack surface of the project. This model enables DevSecOps to become a part of the enterprise architecture of the product being built. In contrast, current practices do not include DevSecOps in the overall product architecture and thus do not integrate effectively with the compliance and operational context of the project.