Building Security Into DevOps Processes

The pressure on DevOps

DevOps teams are under tremendous pressure to understand and implement security principles while meeting software delivery deadlines.

There is an expectation that DevOps practices will enable the business mandate of managing speed and security. We know security is a top business concern because of the increasing number of regulations and standards. Internally, however, it is largely viewed as a low-level technical activity because of its association with software development processes and operations.

While business stakeholders often support training programs, the execution of these programs are often rushed in an attempt to comply with regulations that require a minimum perceived level of security understanding.

For DevOps teams, this is in addition to the existing pressure to release products as fast as possible while maintaining existing quality standards.

Bringing DevOps and security together for proactive security

We talk about “building security in” as a proactive way of managing security concerns. It is about “shifting left” and injecting security requirements early in the application development lifecycle and tracing them into a production environment.

This is in contrast with the traditional approach of testing for security only after a software or product has been built.

“Building security in” implies a common understanding of security across development and operations. Rushing headlong into a discussion on security controls without a base level awareness and understanding of security concepts simply adds to the confusion.

This is often expressed as security slowing down DevOps teams, or security misunderstanding DevOps challenges. We need to bring our teams in a systematic and deliberate way, starting with their current knowledge.

Grow gradually through collaboration

When building out a security program, start with the fundamentals.

Focus on where your teams are today. If they have limited knowledge about security, create an environment where they can talk as peers with other teams. You can create a security awareness program or use security techniques like misuse cases that are functionally based. Sustain the momentum by creating appropriate metrics that the DevOps teams can track against. Keep the metrics that are aligned with business priorities and current skills. Eventually, DevOps teams should start to recognize common security patterns in the application lifecycle.

Once your DevOps teams understand the fundamentals of security awareness and have a bit of experience applying that to their work, you can start introducing increasingly mature concepts.  Introduce DevOps teams to public material made by OWASP, NIST, and ISO once they understand security terminology.

Improve collaboration and involve your security teams in educating the DevOps teams. Create metrics that are related to business priorities like PCI or GDPR compliance. That will provide the business with valuable information around the security posture of its software and product portfolio. It will also demonstrate the business value of DevOps in the context of risk management.

As more DevOps teams get comfortable with security, it may be a good idea to capture security knowledge in a cross-functional repository. This will allow you to integrate knowledge from different teams and gain valuable security insights. Establish metrics that reinforce the responsibility of keeping the knowledge up-to-date as a reflection of security becoming everyone’s responsibility.

Bringing a change in DevOps culture

In the end, building a security program intentionally helps ensure a solid foundation for the future. The goal of a security program is to eventually bring a change in the DevOps culture where teams proactively reach out to security experts and offer their opinions about strengthening the security posture.

You will then have a culture that will help scale the reach of security engineers and ensure developers and operations teams are aligned with business performance.