Modern software delivery demands that we think differently about how we bring code to production. Traditional methodologies typically took on a siloed approach: a development team writes the code, a security team ensures that this code adheres to organizational compliance requirements, and operations teams maintained the availability of the running service. While this organization of specific roles often met the demand for bringing code to production, it also has a number of drawbacks.
First, it was often slow. With different groups all involved in bringing code to production, responsibilities were often serialized. Once the code is ready, the security team takes a look. And then, once the security team blesses the release, an operator can deploy and maintain it. Yes, these teams could multi-task, and begin the next body of work while their current release candidate was being validated. But, this is typically not an efficient process. In practical terms, it introduces disruptive context switching, but it also means that these teams are not working collaboratively towards a common goal.
Because these teams each have different objectives, friction often develops when attempting to achieve outcomes. Development teams are often blindsided by unclear or poorly understood security requirements, operations teams do not usually have nuanced understanding of the code to effectively operate it, and security teams struggle to keep the business secure in the face of rapidly evolving technical requirements.
While Secure Software Supply Chains are primarily a component of getting code into production, they are also an opportunity to reduce the friction between the various stakeholders attached to software development efforts. When implemented properly, each part of the organization will be working together towards the common goal of delivering customer value through software delivery.
Members of a development organization will still maintain their respective areas of expertise, but they will now be asked to work more collaboratively towards this common goal of bringing code to production. Instead of serialized tasks, within DevSecOps each of these groups are working together in parallel. Needs and solutions are clearly communicated on a regular basis. And, because these lines of responsibility are becoming blurred, members can come to shared understandings of how the system works through code. After all, they are now working as one team.
The role of the SRE or platform operator shifts from one of being primarily focused on system availability to one where the operator is an integral part of the development process itself. While the application teams will be focused on new feature development, SREs will focus on the reliability of the whole system. This will require new and different skills from that of a classic system administrator role. Instead of a simple restart of a service, an SRE will now be analyzing performance metrics, debugging defects, and helping to build plans to ensure data integrity.
Platform operators need to be involved from the beginning in order to develop fault-tolerant systems. Their broad infrastructure expertise will help to inform key code decisions during the design and development phases. Determining backup and recovery needs as well as how to ensure the high-availability of systems are just some of the tasks that require operator involvement.
Maintaining the supply chain will require the development of cross-cutting functionality: pipelines and tools that are suitable for all development teams. This may include implementation of common frameworks for business continuity, systems that enforce transparent security, and general infrastructure management.
The role of the security engineer, similar to that of a platform engineer, evolves into one that is closely aligned with their development partners. Instead of acting as a gate to production, they are now engaged with the development teams from the start. The goal is to ensure that security requirements are implemented from the beginning. And, these requirements are no longer defined by spreadsheets and quickly-dated documents, but where possible they are defined by code and continuously verified. This code will make crystal clear, to anyone who would like to ship new code to production, the security requirements that are expected to be adhered to.
Modern platforms provide for shared mechanisms of policy enforcement. This may include everything from how infrastructure is deployed and refreshed to clearly outlining which software dependencies a development team is cleared to use. With a DevSecOps mindset, security engineers are helping to define these policies, but more importantly, help to implement these policies through code. Sometimes that code will be implemented as simple configuration data, but there is also the expectation that security teams will engage on the product’s code itself; advising on items like dependencies, user identity flows, and similar types of needs.
Within DevSecOps the application developer’s role still consists, primarily, of bringing new software to customers. However, the scope of their work grows. Instead of being squarely focused on new features, or even addressing bugs, their scope needs to include tasks that will help to establish and maintain the security of their software pipelines.
The software delivery pipeline requires the same degree of diligence as the product itself. After all, this is the component that stands between your development teams and customers realizing value through your code. Without this robust capability, new code will never make it to your customers.
Developers will need to be involved in the development of unit and integration tests that exercise their code in ways that will mimic real-world use. Likewise, they will be a critical part in ensuring that all of the components in their software artifacts are up to date and secure. And, as they are typically closest to the data requirements of the software, they will need to play a critical role in developing disaster recovery requirements with their Security and Operations counterparts.