Originally posted on Techbeacon.com

Adding security controls into a DevOps pipeline is a challenge on a good day. Often, the security organization might request to add functionality such as static analysis and security testing (SAST) scanners, open-source software scanners, and other tool sets—possibly with little or no understanding of the delivery process.

If introduced incorrectly product delivery gets held up, dates slip, and ultimately DevOps teams lose confidence in their security counterparts.

When adding security controls, careful attention needs to be paid to what stage of a pipeline it is added to, and in what order. Ideally the addition of the controls shouldn’t be noticed by any product stakeholder, nor adversely affect the flow of the product to a customer.

So, where do we start? What kind of security controls even exist? Can we really automate them? Where should we inject these processes to increase our security quality without affecting our delivery velocity?

Here's how reference architectures create new possibilities for DevSecOps.

[ Continuous delivery and release automation (CDRA) demands speed and quality. Find out how in TechBeacon's guide to CDRA. Plus: Get the Forrester Wave on CDRA. ]

Enter a new real-world architecture

To answer these questions, I developed an extremely detailed DevSecOps reference architecture based on years of real-world experience. I will be sharing it with attendees of the DevOps World/Jenkins World conference in San Francisco this week.

At first glance, the architecture may seem a bit overwhelming. It’s big. Really big.

Not only have I spelled out which processes are manual, which are automated, and which are being observed by stakeholders, but I also show the interactions between systems, stages, and stakeholders and where security fits into the overall picture. Similar to a subway map, the architecture details how to get from the spark of an idea to the point where the idea’s value is delivered to end users and beyond.

One of the things that the architecture is not meant to do is be a copy-and-paste template for a DevSecOps architecture in any organization. It is a tool to develop your own architectures, or describe your existing design. It’s meant to show where controls can be inserted into a pipeline with minimal impact, where example vendors and products fit into the processes, and where the journey to DevSecOps can take you as your practices evolve.

This reference architecture was extremely enjoyable to develop. After completing a first draft, I looped in industry peers from development, security, and operations backgrounds to review the flow and the interaction between the stages in the pipeline, and rolled their input back into the diagram.

[ Learn the secrets of successful DevOps initiatives in TechBeacon’s Guide. Plus: Get the Optimizing DevOps Initiatives: Both Sides of the DevOps Divide report ]

Pay special attention to two important parts

Two parts of the design that I find intriguing are the repeated signing stages in the pipeline and injection of moving target-defense elements. The signing design is meant to provide irrefutable evidence that code artifacts have gone through stages in order.

Take for example code flowing into a SAST tool. Before the code enters the stage where it's scanned for security vulnerabilities, it's digitally signed. This would record the signing system identity, the date and time the state was started, and other metadata. Once the stage is completed the code or artifact is signed again to confirm the process completion.

The digital signatures ensure that subsequent systems or stages in the pipeline can validate that the artifacts (or code) have passed through the previous stages and haven't circumvented them. This provides evidence for compliance or audit requirements.

[ Special coverage: DevOps World | Jenkins World 2019 ]

Your journey is your own

I will be discussing the reference architecture in a lightning talk on Wednesday at DevOps World/Jenkins World and in a later session called “Blue Is the New Green,” where I will share the concept of blue/green pipelines and the separation of pipeline operation from pipeline development and experimentation tasks.

Everyone's journey to successfully adopt DevSecOps practices is their own, which is why reference architectures are so important. Even if you aren’t at DevOps World/Jenkins World, you can review the architecture in multiple formats. I’ve included a Draw.io file so you can open the diagram, examine the different layers, and develop your own DevSecOps pipeline architecture.

I would love to gather more feedback on this reference architecture. If you’re so inclined, ping me at @djschleen, and offer suggestions on what’s next, what’s missing, or how it may have helped you.

Want to know more? Come to my lightning talk on Wednesday at DevOps World | Jenkins World, which runs August 12-15 in San Francisco. I look forward to seeing everyone at the show this week.

[ Get up to speed on quality-driven development with TechBeacon's new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]