[MUSIC PLAYING]
DAMITH KARUNARATNE: My name is Damith Karunaratne,
and I'm a Product Manager at Google Cloud.
And this is my colleague, Victor Szalvay,
who is a Senior Product Manager at Google Cloud.
Today, we'll be speaking to you about Google's new approach
to software supply chain security.
Before I dive into the details, I'd
like to turn it over to Victor.
He's going to take you through a quick overview on why
software supply chain security is such a hot topic these days.
VICTOR SZALVAY: Hey, thanks, Damith.
Well, let's start with some background on software supply
chains and why their security is top of mind these days.
Now, most modern software products
are typically made up of the source code
your organization writes, as well as third party software
in the form of dependencies.
Typically, then a build process will
combine these sources and output packaged software,
which, in turn, can be run directly by your organization
or consumed by other parties as their dependencies.
So the dependencies can either be
open source software or commercial off-the-shelf
products.
But in either case, the software will
have its own set of contributors, its own SDLC
process, and typically, its own set of third party
dependencies.
So as you can see, this constitutes a supply chain,
where you can be a supplier, a consumer,
and oftentimes, you're actually both.
So this has the potential to leave your SDLC
in a highly vulnerable state.
You're consuming software from a wide range of sources
with largely unknown set of contributors,
each with varying degrees of security and their own SDLC
processes.
And in fact, attacks on the software supply chain
are increasing at an alarming rate.
Sonatype has noted a 650% surge in attacks year over year.
Gartner predicts that, by 2025, nearly half
of the world's organizations will experience some form
of supply chain attack.
So at Google Cloud, we've identified
a wide range of attack vectors across the SDLC, and I think,
while most organizations are focused
on the top priority, obvious vectors,
like source code analysis and vulnerability scanning,
we are seeing real world threat actors
attacking across the entire spectrum here.
And this includes things like compromising
build systems and package repositories,
as well as injection of compromised
packages and a whole lot more.
DAMITH KARUNARATNE: So the question
is, what can we do to increase the security
posture of our software development lifecycle?
With this in mind, we're excited to introduce Google Cloud
software supply chain security solution, Software Delivery
Shield.
Software Delivery Shield aims to provide a holistic solution
to this problem, spanning the software development lifecycle,
dependencies, and Cloud runtime environments in which you
operate your software.
We've baked in a lot of Google's internal best practices
into the solution, such as a trust-based policy system,
and we understand that this is a journey we're all on together.
So we've provided a stepwise implementation pathway rooted
in the supply chain levels for Software Artifacts
standard commonly referred to as SLSA,
and each component of our solution
can be used together or independently in combination
with existing products you use in your software development
process.
Software Delivery Shield is aligned
to the pillars of your software development lifecycle.
Within Develop, we're shifting security
left into the developer's local workstation in IDE.
On the supply side, we're helping
to improve the security posture of your dependencies.
When it comes to CI/CD, we're helping to secure your build
pipelines with out-of-the-box security capabilities
for building both containers and non-container applications,
and our container runtimes now provide security posture
management for running workloads.
Lastly, we utilize a trust-based policy engine
to ensure only those images that meet your policies make it
into your runtimes.
Let's dig a bit deeper into all of this.
Starting with Develop, Cloud Workstations
provides a fully managed development environment
in the Cloud, supporting popular IDEs,
like VS Code and IntelliJ.
On top of this, Cloud Workstations
comes with a number of built in security features
to help IT administrators and operators secure
your development environment.
Administrators are able to control private ingress
and egress, while using VPC security
controls to prevent data exfiltration.
This can help ensure your source code doesn't
leave your organization's network perimeter.
Cloud Workstations also provide source image, updates,
and granular IAM access policies to make sure
that developers are always using the latest secure development
environments.
Continuing with Develop, Cloud Code Source Protect
brings dependency, vulnerability, and license
awareness directly into the IDE without blocking productivity.
This all works seamlessly with Cloud Workstations.
With Cloud Workstations and Cloud Code Source Protect,
your IT administrators and developers
can save hours in securely managing developer environments
and creating secure applications.
We're also providing new artifact management
capabilities to help secure your dependencies.
Artifact Registry now supports virtual and remote
repositories, further strengthening
dependency government and simplifying access points.
On-push vulnerability scanning in Artifact Registry
with container analysis has been expanded to include support
for Go and Maven containers.
We also now support scanning of non-containerized Maven
packages, and now, a software bill of materials dependency
list can also be generated for containerized applications,
allowing you to gain a better understanding of third party
dependencies.
In addition to this, assured open source software
provides a portfolio of over 250 Java and Python open source
packages.
These packages are built in our secured pipelines
with software delivery shield products
and are regularly scanned, analyzed,
and class tested for vulnerabilities.
When it comes to building applications securely,
Cloud Build has you covered by providing out-of-the-box SLSA
level 3 builds.
In addition to already providing ephemeral and isolated
build environments, Cloud Build now provides you
with authenticated and non-falsifiable build
provenance.
This is available for containerized applications
and Maven and Python packages, providing you
with the ability to audit how your applications were
built with zero configuration security guardrails in place.
We're also introducing new security insights
into Cloud Build through a new security insights panel.
This will allow you to immediately understand
the security posture built artifacts.
The Security Insights Panel will display the SLSA level
build, vulnerability, dependency,
and build provenance information for the built artifacts.
And once your applications are deployed to GKE or Cloud Run,
additional security insights will be
present right at the runtime.
GKE provides continuous runtime vulnerability scanning
for your workloads and also analyzes your Kubernetes
configuration against the pod spec security standards
highlighting DB instances.
And the Cloud Run built-in security panel
has been enriched with SLSA build level, vulnerability,
dependency, and build provenance information
for your containers.
Finally, Binary Authorization's trust-based policy system
can be used to turn all these security insights
into actionable policies.
With trust-based policy, you can create attestations
for specific processes that need to be followed
or for tools that need to be used before applications
can be permitted to run.
These policies can then be applied and enforced
on runtimes such as GKE and Cloud Run.
Now, Victor will show you how everything comes together.
VICTOR SZALVAY: So let's look at how these components work
together to improve your software supply chain security
posture.
We're going to do a demo, and we're
going to start in Cloud Workstations,
wearing our developer hat.
Cloud Code will warn us about vulnerabilities in our IDE.
We'll then trigger a CI/CD pipeline,
with Cloud Build creating the images with build provenance
and displaying our SLSA level.
We'll then use Artifact Registry and Container Analysis
to store and automatically scan our images for vulnerabilities
and also generate the S bomb.
Next, we'll see how Binary Authorization policies
gate our deployment to only trusted images.
And then finally, we're going to check out the new GKE security
posture feature, which shows us security
concerns in the context of running workloads.
Let's get started.
Let's start with the developer environments.
Cloud Workstations provides customized developer
environments that allows developers to get up
and running quickly with just the pieces
that they need for a particular project.
We can create custom profiles that can be set up
within private networks.
We can minimize data exfiltration risks.
And we can customize the environment.
So I can do things like select the CPU, RAM, and even GPU
profiles that I need.
I can also do things like select the IDE that's going to run.
I can also select a completely customized container image.
And that would allow me to fully have
control over all of the tools running within that.
We're going to be working in a Java environment.
So I'm going to launch our Java dev profile here,
which has all the tools I need, including the Eclipse Temurin
JDK.
I also have Maven installed.
So we're going to be working within a Maven project today.
I also have Artifact Registry's new remote repositories
configured.
Now, this allows for proximal caching of my dependencies
for speeding things up.
And I've also got that configured, of course,
within my pom.xml to read from that registry.
So I can get started with my Maven work.
Let's shift gears and talk about dependencies.
And let's talk about securing those dependencies
against vulnerabilities.
Cloud Code has a new capability called Source Protect.
Now, Source Protect will provide linting style--
as you can see, this kind of red underlining--
linting style notification of vulnerabilities
that are lurking within the dependencies that you define.
In this case, I'm, again, looking at a pom.xml file.
I've got the Spring boot framework here.
And you can see all the various vulnerabilities
that are lurking within those dependencies.
Now, if I update one of the versions here, one
of the main versions to something more current,
you can quickly see that the count
drops from 15 to 12 problems.
And I can work through this pom.xml
and address all of these problems.
Now, I'm not going to do that.
I'm actually just going to go ahead and commit.
And we're going to kick off a build within Cloud Build.
Now, Cloud Build can be configured
to run all those same tools that we just talked about.
In this case, again, I've got my Maven builders there.
I've also got Docker.
And Docker is going to help me containerize my application
and ultimately push, to Artifact Registry, the compiled image.
Now, I've also configured a vulnerability scanning policy.
On push, I'm going to be scanning for vulnerabilities.
What this policy does is it will fail
the build if that policy has not been met,
basically if the thresholds are exceeded.
In this case, you can see that it has.
Now, we know that there was at least 12 problems still lurking
there.
And you can see that, in this case,
Cloud Build caught those problems,
and we were able to stop the build without proceeding down
toward a deployment.
Now, we can take a look at the actual image that was produced.
And this is stored and housed in Artifact Registry.
Artifact Registry provided that vulnerability
scanning, basically.
On push, it automatically scans.
And you can see that, in fact, aside from the eight mediums,
I have quite a few highs and criticals lurking here,
both Maven and OS-level vulnerabilities.
So my vulnerability policy stops the ICD
from deploying this image.
But what if I tried to deploy it directly with kubectl,
so short-circuiting the CI/CD process?
Now, I'm going to do that.
We're going to try.
But you'll see that it actually fails.
And the reason my deployment fails
is because I have an admission control policy set up
that blocks any image that has not accumulated proper trust.
Now, this is done by a system called Binary Authorization.
And Binary Authorization can be configured
to set out a policy where you can specify all the trust
factors required.
In this case, I only have two.
I have that it be built by Cloud Build, is one,
and that we have a vulnerability scan as the second.
So as a result, I'm going to have
to just go through and fix all of the problems
within this particular application.
So I'm going to use Cloud Code here to help me do that.
Now, you can see that Cloud Code will
help me find not just the direct dependencies, but also ones
like this, which is a transitive dependency.
And that would be very challenging to find otherwise.
So let's fast forward a bit.
We've fixed all those problems.
And now we can kick off another build
by triggering it via push.
And we'll do that now.
And we'll see that once this thing finishes,
it actually passed, and we were able to get
through that vulnerability policy step
and on toward a CD via Cloud Deploy.
We can also take a look at a new capability called Security
Insights within Cloud Build.
This provides information, such as the SLSA
level that we attain, the build integrity
of this particular item.
So we can see that there's no vulnerabilities lurking here.
We can also inspect all of the dependencies that
are in this particular image.
We can also look at the provenance of this image.
Now, provenance is-- think of it as the recipe.
So this is all of the inputs, including
all the build steps, including the builders that were used,
like Maven in this case and Docker.
We can also see things like the fact
that we went through that vulnerability policy step.
My application has been deployed.
It's running in GKE.
Now, let's take a look at the security posture a little more
closely using the new security posture management
capability within GKE.
Now, this provides an analysis of my running workloads
on the various clusters I have.
In this case, I have three clusters.
I have 13 running workloads.
And it looks at things like configuration concerns.
Now, these are pod spec considerations.
Also, of course, vulnerabilities.
So this is a daily scan of OS vulnerabilities
that comes with GKE.
So I have a drill-down interface,
where I can slice by various perspectives,
like concern or namespace, workload.
I can also do things like filter by severity.
So in this case, I'm going to prioritize my time
and focus on the most important things.
In this case, I have a high CVSS score vulnerability
with a fix at hand, so I can go ahead and remediate.
I also know where to remediate.
And this is one of the great things about security posture
management in GKE.
It ties together not just the problems,
but it pulls them in to the context
of where it is, where in your workloads these things reside.
Let's take a look at our application,
the Maven application we just deployed.
And we can go and filter for that particular cluster.
And I can see my demo-app application.
And I can see that there are actually two suggestions,
some medium-level suggestions.
One is that we're running as root.
The other problem here is that my pod security spec actually
allows for privilege escalation.
Armed with where it is and how to fix it,
I can just update the YAML and make the changes to secure
this particular workload.
So that was our demo.
We saw how Google Cloud's developer tools,
build platform, artifact management,
and our trust-based policy engine work
together to secure your software development lifecycle,
while GKE now provides built-in security posture
awareness and remediation.
DAMITH KARUNARATNE: Thanks for the great demo, Victor.
All of these features are available in Preview,
and you can get started with our Quick-Start tutorials.
To learn more about software supply chain security
and how to secure your software development lifecycle,
take a look at our software supply chain security site.
And don't forget to check out some of our other sessions
on Cloud Workstations, simplifying
the building of modern apps, CI/CD, GKE, and Anthos.
Thanks for tuning in and learning
about how Google Cloud is looking to secure your software
supply chain.
Enjoy the rest of Google Cloud Next.
[MUSIC PLAYING]