Getting DevSecOps off the ground the right way
By Cody Pierce
Introduction
With the rise of DevOps, the movement to improve software development speed and reliability, it’s no surprise that we also want to make our software more secure. Fixing security issues earlier in the development process has many proposed benefits. Beyond reducing business risk, security from the start is cheaper and scales more effectively; or that is the current hypothesis.
But is the addition of Security to Devops, also known as DevSecOps, achievable? Maybe,time will tell. However, DevOps and Security’s current modus operandi makes this transition very difficult, often leading to false hopes and dreams that can create a false sense of security.
This post will explore the reality of security and developer’s existing operating partnership, why life isn’t so simple, and what necessary steps we can take today that gets us closer to effective DevSecOps.
The Dream
Developers are shipping code fast. The integration of CI/CD pipelines and collaborative tools that let teams perform quality-control before deploying code has revolutionized software development.
It makes logical sense that we can also leverage this approach to improve the security of our software. Success means less risk to our businesses, improved security awareness, and better code. All of these outcomes are great. I would be lying if I didn’t subscribe to this idealized world.
In theory, we can build a harmonious organization free from silos and finger-pointing with a shared goal of great software that’s impenetrable to attack. However, the devil is in the details.
The Reality
Ring, Ring, Ring. The alarm goes off, you wake up, and reality brings you back to consciousness. Developers are not security experts, and security experts aren’t developers. Articles on “shifting security left” typically include the same steps. I’ve summarized them generally as the following.
- Change your culture.
- Automate security reviews.
- Evaluate your performance
- Iterate
Let’s look critically at each step to understand the potential pitfalls most organizations will face when building a DevSecOps program.
Change your culture
If you have ever tried to change any group’s culture, you know that it’s nearly impossible and takes a significant amount of time. As a parent, I have asked my children hundreds (thousands?) of times to pick up after themselves. Adults are not much different (No offense!). Change is hard.
The biggest impediment to changing your culture to adopt DevSecOps is the impedance mismatch between developers and security teams’ goals. Developers need to ship code that serves the business’s growth: typically in the form of a pleasant and reliable software experience. Alternatively, the purpose of a security team is to protect customers and resources. The subtle difference creates a conflict that makes the integration of these groups prohibitive.
If you have ever observed developers during sprint planning, the appetite for distraction and unnecessary velocity barriers are near zero. Yes, with education, encouragement, and time, you can reduce friction, but evolution is slow and fraught with extinction.
Automate security reviews
Automation is fantastic for reasons I won’t cover here. But security is often more art than science. The experience of your team is likely diverse and varied. Some teams specialize in Vulnerability Management or application security, while others are responsible for Detection and Response and IR.
An expert in code analysis is costly and only part of the security expertise needed to automate code review. So most organizations are looking at tools to solve this problem. But the current set of tools to automatically find and report software vulnerabilities are inadequate. In GitLabs “2020 Global DevSecOps Survey,” they discovered the following.
“Less than 19% of companies surveyed in this year’s DevSecOps report put SAST scan results into a pipeline report that developers can access, and over 60% of developers don’t actually run SAST scans”
This insight tells me that existing automation tools are inadequate, expensive, or waste developer’s time. Maybe all three. Automation is hard, and we aren’t mature enough to expect success.
Evaluate your performance
Security performance has to be measured. But what do we quantify when developers must ship code fast and securely. You could define success as zero code vulnerabilities, but what do you consider a software vulnerability? Are all vulnerabilities created equal? Would you stop a release that your customers are waiting on? It’s hard to say, and without a precise definition, developers will feel frustrated and disillusioned, leading to low adoption and bad vibes all around.
The shared responsibility model is a good idea. Security is a team sport. But it’s naive to believe that everyone is equally bought into the journey when push comes to shove. Without the cultural shift and seamless automation, performance will be hard to measure, and adverse outcomes might disrupt said culture. Shared responsibility is a tough sell when you ask specialists to operate outside of their comfort zone.
Iterate
Iteration is an enjoyable experience. You continuously improve people and processes, thus making your organization more efficient. Unfortunately, cybersecurity is so dynamic that iteration can only happen when the previous steps are working as intended. Successful iterative improvements only come with lots of investment and experience. Don’t expect to perfect a process until the process is stable and repeatable.
Baby steps
In the previous section, I covered the difficulties in building a successful DevSecOps program. While I consider DevSecOps an eventuality, the realist in me knows that to move security left, you must first improve security on the right. The following are two suggestions to get your security team warmed to the DevSecOps dream.
Visibility
Visibility is the first step in any successful security program. You can’t secure what you can’t see, and visibility is necessary across the different security team’s roles and responsibilities. So how does that relate to DevOps?
First, your security team needs to know what developers are responsible for deploying. Many organizations have multiple properties and applications accessible to the internet. Websites, portals, apps, etc., need to be inventoried and visible to security analysts in a single pane of glass. Owners of the applications must be correlated and tracked. If a development team owns your customer portal, security must know who to work with when security issues arise.
Second, software development is layered and complex. For instance, a javascript app might have hundreds of third-party software dependencies. Each dependency must be cataloged and monitored for vulnerabilities. It is critically important for security teams to understand how developers build applications to analyze and verify the risk associated with them adequately.
Once your security team has complete visibility, you can then start the conversation with developers on improving the security of applications. For instance, a new policy that requires automatic updating of NPM packages.
Verification
Empower your security team to verify the result before asking them to move left. It is essential that the final product, deployed code, is in the expected state. All the DevSecOps in the world won’t matter if the outcome isn’t verifiably secure to a predetermined level.
In the AlphaWave platform, we have created a taxonomy of security exposures, from software vulnerabilities to risky services. Having continuous access to this information gives security analysts the observability to work with developers, improve architecture, quality, and reduce risk. A good first step might be setting the expectation that an application isn’t exposing any risky service like a database without adequate controls.
Conclusion
Let me be clear. Moving security left is inevitable, but jumping into DevSecOps without having visibility and verification will lead to frustration.
Right now, developers and security analysts do not have shared goals. Before making cultural changes to bring these groups together, you must take the initial steps to get your security team closer to the software and services developers are responsible for. As Intelligent CIO puts it, “Develop a culture of visibility.”
Starting your DevSecOps journey by educating and empowering security to dip their toes in the water will pay dividends as you grow. Building your security team’s confidence before asking them to integrate and automate operations will hopefully break down the silos inherent in your organization.
Good luck on your journey, and don’t hesitate to reach out to understand how LookingGlass can start you on the right path.
