Building a DevSecOps culture and shifting security left

There is an old saying that you can pick only two of the following traits: good, fast, and cheap. If you choose a good and fast path, it will be expensive. If you choose good and cheap, it will take time to get it delivered. Lastly, the fast and cheap selection will yield poor quality. 

Over the past decade, companies have embraced DevOps methodologies, and understand the tough selection between the three traits. Tool selection is extremely important to implement a DevOps culture, although it will require more than just the perfect tool.

Successfully implementing DevOps, as a culture and practice, is predicated on automation. Efficient automation is how a company like Etsy does 50 deployments per day. This speed of development and deployment has some obvious advantages—bugs don’t live in production very long because rapid development and deployment replaces them very quickly with corrected code. You can also introduce new features quickly without having to wait for long development cycles to create a complete package. A new feature can be developed and deployed while other features are being developed alongside. 

Like DevOps, DevSecOps is a culture. Security-minded companies are often the first to adopt DevSecOps methodologies, where developers work closely with security teams and bring security considerations earlier in the development life cycle — also known as “shifting left.” 

In a typical (and simplified) software development process, you might have a requirements phase, followed by design/development, testing, and deployment. Shifting left means introducing security as far to the left in this software process as possible. 

The security tools you use are essential to enabling and automating DevSecOps. You need to make sure you are selecting toolsets that will integrate with your existing environment, and support development from the source code repository, through the build process, testing, and deployment. These tools should also be API-enabled so that your developers can leverage them programmatically using automation.

Following are some ways that you could consider introducing security into the development process.

Adding DevSecOps in development processes

Requirements

The best place to introduce security is in the requirements phase. There are significant cost increases to fixing problems in later phases. There may be several ways of addressing

security in the requirements phase but a simple one is threat modeling and ensuring that the identified threats have mitigations in place.

Design/development

The same threats identified in the requirements should be kept in mind during the design and development phase. Designing how the product is going to operate should not introduce new threats while limiting the impact of existing threats that couldn’t be removed. Additionally, developers should always be following secure programming practices that are specific to the language they are using. Additionally, in cases where developers are expected to write test cases, they should be trained to write misuse cases and test against those so their software is more resistant to bad or malformed data being passed through functions they write.

Testing

All requirements should be addressed during testing, but specifically, any threat mitigation identified in the requirements phase should be tested to ensure the mitigation is in place and works. This is a case where misuse and boundaries should be tested. Data should be introduced that would violate the specifications to try to ensure any application failure is safe, meaning it doesn’t present an attacker with the opportunity to manipulate the program space or introduce and run code in a way that violates acceptable risk.

Deployment

The deployment phase may be one of the most critical, especially in the case of web applications or any application that is hosted in a network environment. All systems and containers that are deployed should be hardened, meaning unnecessary software or services should be removed and all access requirements reviewed and tightly controlled. The goal of deployment should always be to limit the attack surface, meaning the ability of an attacker to see any service from either the internet or within the network space controlled by the deployment team. This is also where you implement any changes based on observations from your production environment. Lastly, policy violations that exceed acceptable risk should be addressed before moving anything beyond this point.

Getting started

If you’re in an organization where security and development remain separate until applications are deployed and running in production, adopting a DevSecOps methodology can be challenging, especially when you have well-entrenched development processes. The cultural change alone could be met with resistance by your teams. 

It may be easier to slowly push your way backward from the far right. While security testing is a minimum to push to production, you can steadily introduce secure programming practices and threat modeling into your workflows. It’s worth noting that security will typically require specialized staff, and you may not be able to find a single person who understands security from the perspective of all phases, so you’ll be adding additional bodies to your development team. 

However, the increased investment in DevSecOps will pay off once you realize that security concerns, especially those that were not addressed earlier in the development process, are one of the driving forces behind deployment delays.