SPEAKER: The 2021 State of DevOps Report released
last year--
it contained findings about how teams navigate
key areas of software delivery.
We talked with two of the researchers, Dustin Smith
and Dave Stanke, about the report's section on security.
Hi, Dustin and Dave.
Were there any surprising findings
in this section of the report?
DUSTIN SMITH: You would think that the more steps I
add into my process, the slower it will be.
But I think it's really about how teams are
integrating these practices.
And are they doing it by looking at their entire system
and figuring out how they can best
fit them into the actual process so that it is seamless?
And that should be the idea with any of these practices.
And we find that teams that implement these practices
are actually delivering software faster and more reliability,
and all while seeing value driven to the business.
DAVE STANKE: So one thing that we found consistently,
and yet I'm still surprised by it every time,
is that we don't have to make a compromise or a trade-off
between delivering fast and delivering well.
We found that teams that have the best secure code practices
actually are the same ones that are
delivering the most frequently and having the shortest
lead time from code to delivery.
So we really can have both fast and market responsiveness
and security and reliability.
SPEAKER: What exactly did the security section of the report
focus on?
DUSTIN SMITH: I think one of the important things
to clarify with how we looked at security
is that we weren't looking at things
like how many vulnerabilities did you experience
in the last year.
We weren't measuring how secure is your team.
Instead, what we focused on were what
practices have you implemented on your team
in order to detect and recover from security vulnerabilities
in an effective way.
That's one of the key differences
that we try to focus on for several reasons.
One of the main ones is that people may not
be willing to share how many vulnerabilities
they've experienced.
But they are willing to share what practices they've
built into their process.
SPEAKER: What did you find separated elite teams
from the rest?
DAVE STANKE: The real fundamental thing
that we see is they do something called shifting left
on security.
The teams that are succeeding are the ones
that are bringing security principles, knowledge,
and practices leftward into their testing,
into their initial development processes,
and making it something that is known and practiced
throughout the organization.
They make a lot of use of automated testing
to make it so that known vulnerabilities can rapidly
be detected and kicked back for remediation.
And something that really high-performing teams
like to do is having guardrails or pre-approved libraries,
things that developers can pull into their code
with the assurance that those have been vetted by experts
and that they're going to pass their security
tests because they've already been built in.
The security practices have already been built in.
DUSTIN SMITH: Elite-performing teams
are more likely to build security
into their entire development process.
And so that means not throwing over your most recent change
to the security team and asking for approval right
before deployment and hoping that they do it quickly.
It means pulling them in earlier,
right at the design doc phase.
Are you including your security team?
And then are you including security reviews
throughout your entire process as well?
And then do you have tests that check for known vulnerabilities
built into your build process?
And finally, do you have pre-approved libraries
that you can pull into your project
and know that those versions of those dependencies
are pre-approved and secure and ready to be used?
SPEAKER: How can teams start implementing these practices?
DUSTIN SMITH: I'd say go to the report
and look at all the practices that we've outlined
and try to identify some of those quick wins
that you could get.
Where are the low-hanging fruit?
And one of the nice things about the report
is that we also include industry benchmarks for each practice.
So you can get a rough idea of to what
degree has this practice already been adopted in the industry.
That should give you an idea, even
if you haven't met with your team yet, of where,
potentially, are we lacking.
SPEAKER: What would you say is the core idea from this section
of the report?
DAVE STANKE: Really, the meme is security is everybody's job.
But that doesn't mean that it's not your job.
There can be an unfortunate interpretation
that says, well, if it's everybody's job,
then I'm covered.
I don't need to worry about it.
Well, the bad news is it's your job, too.
And we find that teams that succeed
are the ones where everyone in the organization
really internalizes the importance of shipping
secure code.
Now, that doesn't mean that we expect
every person in an organization to be
a security expert and a worldwide leader in software
security.
Instead, what we like to see is a consultative model,
where an organization has a team of real security experts
who are creating guidelines, creating
pre-approved pipelines, and generally educating
the organization about how to incorporate security
into their work.
And then everyone throughout the organization,
from design to implementation to testing to operations,
all can reflect that knowledge back into the work
so that it's incorporated in their day-to-day jobs.
DUSTIN SMITH: I think the overarching principle should
be that we need to move from being reactive to detective
vulnerabilities and more proactive and even diagnostic
and just noting that vulnerabilities
are, essentially, inevitable.
And so we need to be able to come up
with practices and processes in order to recover from them
when they are detected in a way that is quick and scalable.
SPEAKER: Where can users go to learn more?
DAVE STANKE: We've got a great resource on our Google Cloud
site that incorporates this year's State of DevOps Report
as well as previous years'.
It's got a capability catalog that
shows all those capabilities I mentioned.
And for each one, there's an article
that talks about what it is, how to measure it, and how to get
started practicing it.
There's all that and more, including
a self-assessment tool that I really recommend.
You can check it all out at g.co/devops.