Technology never slows down and to keep up,
we've had to move to a more nimble DevOps workflow.
With more complex software architecture,
we break things down to microservices,
use separate resources, containers,
and take advantage of cloud technologies.
These changes introduce new risks
and increase the attack surface of our systems,
which means our old,
monolithic single perimeter security approach doesn't work.
And with cyber security threats like ransomware
and supply chain attacks becoming more common,
how can we secure all the things, all the time?
(upbeat music)
DevSecOps is the next step in the DevOps evolution.
Security can't just be tacked on at the end of things,
it needs to be an integral consideration from the start.
Essentially, we need all the teams
in the pipeline to shift left.
Shift left places an emphasis on security
early in the software development life cycle,
so that potential issues can be resolved
before they become major problems.
DevSecOps aims to enable secure apps
without requiring developers to be security experts,
while still including them in the security process.
Let's talk to someone
who has experience with both shift left
and something that may seem
more to the right of the software development process,
like runtime security.
- Hey Chris, how's it going?
- It's going well, Liz.
It's been a while
and I was just thinking about DevSecOps
and shift left security and I mean, I know there's a,
there's an aspect to these words,
where it feels like a buzzword,
but you have a lot of experience in this space
and I just thought I would, I would get your opinion on
what are the key takeaway concepts
in DevSecOps and shift left security?
- So, if DevOps is all about
making it really easy to deploy code quickly,
we can't just sort of treat security as a sort of add on
to the, to the end of that process.
We can't be waiting for doing security patches
just once a month, you know, or twice a month,
we have to be, you know,
applying security processes all the time continuously,
just the same way that we do continuous testing.
- We really have to think about everybody participating in
building more secure code from the developer writing code
through to the automated testing and,
and even understanding what we put into production.
You know, we have complicated applications,
they're not monoliths, they're,
they're broken apart into a collection of services.
We're doing continuous delivery or continuous deployments.
You know, what are some of those key spots that,
in that pipeline that you look for, for security?
- Yeah, so the first thing that I always mention
when it comes to, you know,
securing your CI/CD pipeline is building more secure code
with your CI/CD pipeline, is vulnerability scanning,
because it's very easy, there's plenty of tools out there,
open source tools, that will scan your dependencies
for known vulnerabilities.
Making sure that you're using known base images
that have been agreed between
developers and the security team.
Developers might want to have, you know,
every bell and whistle in the base image,
but from a security perspective,
the smaller the images, the better,
the smaller the attack surface,
so getting an agreement on
what really needs to be inside a base image
is a really good,
is often, it's a good best practice
and checking that you're
only using those approved base images
is easy to automate.
And then another thing that you
would probably want to be thinking about
is how you inject credentials and secrets
because you don't want those secrets baked into images.
Again, something you can check for automatically,
but you do need, you might need the,
a certain service might need a password or a token
to be able to access a database.
We need to get those in somehow
and there are tools that can help you inject those secrets
into images at runtime.
- We're thinking about how we do these processes repeatedly
across every service, that's a part of the application,
so there's a complexity
that's coming out of just the volume
or the amount of work that you have to do
and so I can understand how automation is really key
in making this a part of everybody's job
so that it scales as we put
more and more code into production is,
is really a core concept here in shifting left.
- Yeah and it's essential, right?
Because if we're going to ship code several times a day,
then we can't just have security processes
the old fashioned way.
And also you brought up a really great point there about
decomposing architectures
into smaller components and services,
because we can treat those services
as things that we can secure in their own right
and we know that we can take the developer's intention
of what those services are supposed to do
and turn that into security rules.
So for example, if we think about network security,
we can understand
which components are supposed to speak to each other
and which ones aren't supposed to speak to each other
and use network policy to enforce that
and, so for example,
if you've got a product search component,
you want that to be looking at your product database,
but you really don't want your product search component
talking to a payment gateway
and being able to enforce that through network policy
is really powerful for security.
- Yeah, I think that that requires some definition,
some policy, some declarative view
of what it should look like and then some way to,
to manage that at runtime,
I'm curious what you think about the evolution.
I mean, we're in this shift left world
and we've introduced DevSecOps,
they're not brand new concepts,
they're starting to take, take foot.
What do you see as the, the evolution of these concepts
and what are the core technologies that
you're excited about in this space?
- Well, one thing that I'm really excited about is eBPF.
So I'm sure, you know, Chris, eBPF makes,
makes the kernel programmable,
and we can use this for so many powerful things
in terms of observability,
spotting what may or may not be a malicious behavior,
things like unexpected network connections,
unexpected executables running in your environment
and because we can see, using eBPF,
we can see things from the kernel's perspective,
we can see everything that's running on a system
in a really performant way,
And that's gonna be, I think,
a really powerful basis
for the next generation of security tools.
I mean, some of these already exist today
and I think we're going to see,
with the kernels that support eBPF,
becoming much more widespread in production use,
people are going to be adopting those eBPF based
networking and security and observability tools
over the next, you know, year or two pretty prolifically.
- I love that concept of having the,
the observability built in to the kernel,
so you get to see everything that's happening
across the system, combined with the programmability,
so you could actually do some of the enforcement,
so you create that relatively simple declarative policy.
You have ways to observe the behavior
and then enforce the policy
that you've, that you've defined.
In the end, we're taking all this, you know,
complexity that we're developing by distributing the system,
using simple tools to create really a more secure posture
and build a better, more secure internet in the end.
Really appreciate your time, Liz,
this has been a great conversation.
- My pleasure, Chris.
- DevSecOps is all about infusing a security mindset
to produce more secure code.
But to really integrate security into the pipeline,
this shift in mindset needs new technologies.
With eBPF and runtime security,
we're building technology to give us the visibility
to detect and respond more quickly.
And by sharing responsibility,
establishing more secure workflows with automation,
and being open and transparent in our code,
we can begin to connect our runtime protections
and secure development practices
to improve software security everywhere.
(upbeat music)