DevSecOps is a hot topic. It’s touted as a utopia where automation saves time and money while cutting risk and reducing dependencies. In reality, without effective oversight, DevSecOps leaves orphaned technologies, unmaintained repositories and application artifacts, and ruined credibility in its wake.
The value of DevSecOps lies in shifting your security program to the left in your schedule—in other words, shifting it earlier into the software development lifecycle and testing against it all the time.
Tony UcedaVélez, founder and CEO of VerSprite, outlines this well in his presentation, available on demand below.
The Goals of DevSecOps
The high-level goals of a DevSecOps program are:
- Reduce security control gaps.
- Lessen the time spent on manual configurations.
- Improve incident recovery efforts.
- Increase security assurance across environments.
- Build security requirements into products and platforms.
- Eliminate vulnerabilities in the deployment pipeline itself.
- Put governance into operation.
Two of the most important aspects of DevSecOps are assurance and compliance.
Assurance
Assurance ultimately dictates the reputation of any product you sell. To manage it properly, build it into your code base, infrastructure, and even the actors in your pipeline.
Compliance
Including governance in the DevSecOps process is key from a compliance point of view. By doing so, you can demonstrate compliance on an ongoing basis across all environments.
Governance currently sits outside of DevOps and catches issues too late. Instead, determine your security requirements before development starts. To do so, work with your compliance team to understand the controls they need and account for them early in the process.
Planning the Shift
The goals of shifting security left are:
- Ensure that all environments—not just production—receive security configuration.
- Reduce security and privacy discrepancies across environments.
- Operationalize security efforts through code and the CI/CD process.
Shifting left means not waiting until deployment time to worry about security. Instead, put security and compliance into the pipeline before any development begins, and verify it in all environments. As a result, you’ll have consistency in controls across environments.
Layers of Need
The layers of need give you three ways to think about security in the pipeline: assurance; governance and compliance; and security testing. Assurance certifies your platform and environment and validates third-party libraries. Governance and compliance aligns your security controls with regulatory requirements and pulls them earlier into the pipeline. Last, test new features for security on an incremental basis, just as you do with your functional testing.
Getting Started With DevSecOps
Where do you want to start? Ask yourself this question before embarking on a DevSecOps program. For example, quality of code may be your biggest risk. In that case, bring in static code analysis tools, and set them up to run in the pipeline during builds. Instead of having to bolt security on at the end, you’re building a better picture of your code the entire time. Then you can put in a program to remedy any existing production issues while preventing new ones.
Threat Modeling
Look at your entire pipeline, and apply risk to it to produce a threat model to drive your automation priorities. For example, suppose you have a financial application that traders on international exchanges use. Continuity and availability are key, and a threat model should lay out risks to each of those. In this case, availability means finding weaknesses to denial of service attacks and mitigating them across the application, stack, and infrastructure. And here’s a second example: GDPR regulations require protection of certain personal information. To obey these regulations, apply threat modeling to identify noncompliance risks and to demonstrate proper controls throughout the pipeline.
Let’s discuss automation further.
Automation Cases
Map your automation opportunities into your software development life cycle. For example, if your control is “Use cryptographic controls to protect your information,” then there are lots of ways to comply with that across a variety of situations. Regardless, though, rely on automation and tooling to automate those checks throughout your ecosystem. Then have the findings of all automation checks saved to a repository or other source. Last, link the findings to a central website or dashboard. When auditors come, start them there to save time and staff effort.
Moving Forward
Start small and go from there. At first, let your strategy dictate your automation and priorities instead of any automation tool. Then understand the mapping between your organization’s weaknesses and its threats and go from there. Last, automation should go all the way through to results analysis and remediation.
