Software Engineering Institute

A major challenge for cybersecurity comes from new technology approaches that focus primarily on the benefits of implementation rather than on defining the governance and risk management changes necessary to establish and enforce appropriate protections. This challenge is especially important for the adoption of technology that impacts critical infrastructure and shared services, such as voting and defense. Researchers examined the challenges and the effective cybersecurity options facing Department of Defense (DoD) programs delivering cyber-physical systems and adopting DevSecOps. These researchers found a lack of broad understanding about the level of management and governance responsibility needed to define and use the DevSecOps pipeline. Adopting DevSecOps is a socio-technical decision that links technology with operational process and practice. Researchers identified several areas that require cross-functional and organizational management attention to fit the pipeline for mission use and considerations to address for producing the system. This paper describes the case study and lessons learned to date.

When a program adopts DevSecOps, it creates and supports two major systems concurrently: (1) the product the program was assigned to produce, and (2) the pipeline the program uses to develop and operationalize the product. Both systems need effective built-in security. In addition, neither the product nor the 1 Editing and final reviews were handled by Communications Services of the Software Engineering Institute. pipeline can remain static, so the cybersecurity of each must change to ensure sufficiency. The product expands with added functionality, which includes added vulnerabilities that tools and developers must address. The pipeline should be continually refined and improved as new tools and techniques better enable the consistent throughput of new features and capabilities. The focus on functionality and throughput is not sufficient for either system because the threat landscape changes constantly with new attacker capabilities. As a result, the need for improved tools to avoid and remove vulnerabilities from the product become critical. These tools must also be patched since they are software and contain vulnerabilities. As more data about the product is collected through the pipeline, it is critical to tap this information to improve the product and pipeline. However, the pipeline is not a single entity. It is a collection of highly configurable pieces built independently and assembled to perform together.

The increased use of the DevSecOps pipeline to automate software assurance, cybersecurity, and safety compliance transfers the responsibilities for identifying and addressing pipeline and product risks to roles that were not involved in the past. For example, acquirers and maintainers of pipeline tools may now be responsible for the level of verification performed on the product and its associated effectiveness. If the criteria for tool selection remains focused only on cost, availability, and compliance, the expectations for this new responsibility could fall short of stakeholder expectations, especially if structuring the pipeline does not include stakeholder requirements. There is a lack of broad understanding about the level of management and governance responsibility needed to define and assure the responsible use of a DevSecOps pipeline. Our work is focused on bringing these under-address areas to light.