For this session, John Willis and Shannon Lietz took on questions about all things DevSecOps and what the future of the practice looks like. Lietz was involved from the start in helping make All Day DevOps happen. She leads DevOps practices at Intuit and has 20 years of experience in security across her career. Similarly, John Willis (a.k.a. Dr. Deming), an entrepreneur and skilled DevOps leader, is considered one of the utmost experts in DevSecOps.
Let’s talk about how we help senior leadership understand the value of DevSecOps. The real issue is twofold: It comes down to communication and measurement. And more than that, it’s really a question of how do you boil things down so that you’re focusing on the most important things you need to be successful?
Then, let’s look at communication. It’s easier to convey math than language. Developers talk about the language they’re using to build their code, while security and ops have different languages that they use. Bringing those together is difficult. When looking at measurement, we want to know what it means to have secure and resilient systems. And to answer that question, we want to look at securability and which metrics show how we’re doing.
A key aspect of that is feedback loops. In listening to Charity Majors, Willis gave an example where Company A has 3,000 developers who deploy three times a day, and Company B has the same amount of developers, but they only deploy three times a year. What’s the result? Company A learns two orders of magnitude faster than Company B. They get faster feedback. What we’ve learned from DevOps is that we want to shorten feedback loops.
Becoming Proactive
In security, we’re very waterfall. We have control regulations and we want to translate them into infrastructure requirements. And that somehow flows down to developers, who then have to determine how to apply these to their applications. And we measure our success only once a year in an audit. So, we’re not validating the implementation and outcomes. By that point, we don’t know what the code was supposed to be—we’ve moved on to different roles.
We use the term “shift left,” but how do we create a good feedback loop so that we can create an agile structure? Well, you have to show leadership that we can transition from being reactive, in the form of an audit, to being proactive. Move from telling auditors that they already know to empowering teams to self-identify risks.
When we blend DevSecOps into the organization, everyone takes an interest in one another’s goals. And we become more focused on our customers.
Let’s consider this scenario. From an internal perspective, how do we look at metrics? And how do we look at what adversaries are doing?
For example, SaltStack announced a vulnerability that required an upgrade. Within three days, organizations were hit by the vulnerability. And this was predictable. So, how do you minimize that blast radius?
We require clarity and visibility into what’s going on. We need to look at the supply chain and we protect against it. Adversaries look at edges. We need to release software faster. And we need to make sure our tools support that. For example, we have a pipeline made up of tools to protect our applications, but our pipeline itself is vulnerable to attacks.
We have to move away from checklist security, where everything is focused on reactive steps to verify whether we have a certain scan or tool. And then we push the software out the door and find out there was a vulnerability and some number of people were affected.
We need to get out of the trap of “I have to do this, I have to do that.” We do need the tools—they do help.
But do they change the organizational mindset to understand why we’re doing these things? It’s critical to think about software as a service that we’re delivering and what our strategy is across the whole ecosystem. That’s how we change the organizational mindset and empower ourselves to embrace the benefits of DevSecOps.
So, how do security advocates play into this? How do people get started? First, there’s this notion or bar in people’s minds that assumes you need certain things to learn and look at security. And people fear this barrier to entry.
Ultimately, people should set their own goal or bar and measure themselves against that skill. Get to know people doing it already. Start trying things and testing things. The “just getting started” mentality turns you into the practitioner that you want to be. There’s no barrier to entry, and leadership needs to support people who want to learn.
And what can leaders do to support their developers? Make the easy thing the right thing. Help developers select the things that make the most sense.
We still have companies that haven’t heard of DevOps. So, we still need to work to change the mindset of teams and the culture. Let’s not look at the org chart or get lost in the weeds about what belongs in a story and what doesn’t.
So, what metrics should we look at? So many exist. Do we even understand them? For example, is adversary return rate important?
Pull requests per hour provides a great start. So is mean time to defect. The truth is, if you’re doing well at DevSecOps, there isn’t a single set of metrics that applies to every use case, but there are some that are critical. And one of them is definitely adversary return rate.
But do your own research. Look at what metrics you can leverage and what change those metrics can drive to improve your organization's DevSecOps implementation.
To sum it all up, we need a holistic mindset to look at things. And with great power comes great responsibility. People need to learn from the mistakes they make. And we need to let people make mistakes safely.
This session was summarized by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.