LinkedIn
Twitter
With many enterprises moving to the cloud, it’s imperative to focus on securing the cloud platform. In today’s world, securing just the cloud platform is not enough. Organizations must also focus on securing their applications. The White House even issued an Executive Order around this.
In this blog, we’ll be talking about how you can secure your application by securing your software supply chain. We’ll cover components of the software supply chain, the risks of an insecure software supply chain, and the importance and some best practices for supply chain security – specifically, how we can leverage Google’s Software Delivery Shield.
First off, what is a software supply chain?
Next, you have your version control system, or VCS. A VCS is where your code lives. Best practice is to not have your code locally on your workstation! Storing your code in a VCS allows for collaboration and for backing up of your code.
This is followed up with testing tools. These tools will scan your code as well as your third party software dependencies used for security vulnerabilities. These tools are important as they can help you keep track of zero days or critical security vulnerabilities that can harm your organization.
Now we get into deployment tools. A deployment tool is leveraged to build and compile everything together. For example if you have a java application, you can use your deployment tool for compute power to compile all the software dependencies for that application. With the more popular deployment tools, you may be able to even run the testing tools on top before your application is fully built.
Now we get into the interesting parts: your cloud hosting providers and applications. A cloud hosting provider is essentially where you would host your application and where services would run. The big three are Google Cloud, Amazon Web Services, and Azure. Since we’re going to talk more about Software Delivery Shield, we’ll be going deeper into Google Cloud-specific services.
Getting to know Google’s Software Delivery Shield
Software Delivery Shield (SDS) is a fully managed, end-to-end solution for securing your software supply chain. It contains services and products that allow you to integrate security into all the stages of your software supply chain. It also provides a dashboard view that includes information around vulnerabilities within your application’s dependencies. SDS also gives you information that helps you identify the maturity level of your software supply chain using the SLSA Framework.
SDS is an end-to-end solution, so let’s start from the beginning: code development.
Code development
When we think about security in code development, we should think about the best practice around shifting security left. If you want to learn more about shift left security, check out this post from Google.
Even better, starting security left. When we talk about this, we integrate and embed security in places where code is developed. In this stage, we can leverage the following services:
- Cloud Workstations
- Cloud Code
- Assured Open Source Software (Assured OSS)
- Artifact Registry
These four services are what help organizations securely develop code to build applications that will run in their environment. Let’s break each down.
Cloud Workstations
Cloud Workstations are essentially virtual desktops that run on Google Cloud. Using Cloud Workstations allow for secure access to environments and coding, allowing for ensuring the right monitoring and security controls are set up for users. Cloud Workstations also work with Google Cloud’s VPC Service Controls, network security such as private ingress or egress, forced image updating, and IAM access policies.
For more info around Cloud Workstations, check out Google’s documentation here.
Cloud Code (currently in private preview)
Cloud code is still in preview as of this post, but Cloud Code is basically a managed IDE that runs in Google Cloud. By using Cloud Code for development, users can get real time security feedback, such as vulnerable libraries and dependencies, as well as license reporting. This follows industry best practices by shifting security left and having security start at code development.
For more info on cloud code, you can check this page out. Since this is still in private preview, you may request access to this service through this access request page.
Assured Open Source Software (Assured OSS)
Assured OSS is a service by Google Cloud that lets you access OSS packages that have been verified and tested by Google. These packages are mainly Java and Python, and are built using Google’s pipelines. Think of these packages as verified social media accounts with the little checkmark; trusted packages for secure development.
For more info around Assured OSS, go here.
Artifact Registry + Artifact Analysis
Artifact Registry is where we can store, secure, and manage artifacts that will be used during the build stage. This could be a package, a file or a binary that needs to be used for development. Think of this as a trusted share for artifacts for your organization.
Artifact Registry has a feature called Artifact Analysis. Artifact Analysis does proactive scans to detect vulnerabilities against artifacts stored in Artifact Registry. You can do on-demand, or automated scans, generate a Software Bill of Materials or SBOM, and upload a Vulnerability Exploitability eXchange or VEX statement for images. Artifact Registry also allows support of remote and virtual repositories for Java packages. A remote repository will act as a caching proxy which allows for reducing download time that can improve availability, as well as provide a vulnerability scan. Virtual repositories will consolidate repositories of the same format behind a single endpoint which can let you control the search order upstream. This can reduce your organization’s risk of dependency confusion attacks.
For more info around Artifact Registry, you can go here.
To recap, these four services are the foundation for shifting security left that can help your organization develop code securely, which will strengthen your security posture against vulnerabilities that may show up during runtime that could be exploited by malicious entities.
Securing the build pipeline
When we talk about the build pipeline, we're looking at the Continuous Integration and Continuous Delivery, or CI/CD, pipeline. The CI/CD pipeline is where the code will be put all together. But this is where you can include additional steps to help secure the builds. Cloud Build and Cloud Deploy are two services that act as your orchestrators to run these pipelines that can include security steps.
Cloud Build
Cloud Build is a service that executes builds via Google Cloud compute resources. Because of that, Cloud Build can integrate with security features such as VPC Service Controls, IAM Permissions, and it can even run internally and ephemerally on your network.
Remember I mentioned SLSA in the beginning of this post? Cloud Build supports SLSA Level 3 builds for container images. It can also generate authenticated build provenance as well as provide security insights for built applications.
For more information around security insights for Cloud Build, check this out.
Cloud Deploy
Cloud Deploy can automate delivery of applications to a series of environments through defined stages. It supports continuous delivery directly into Google Kubernetes Engine (GKE), GKE Enterprise, and Cloud Run. Cloud Deploy provides enterprise security and audit as well as metrics for delivery which could be helpful when needing to look at logs for incidents.
Want to know more about Cloud Deploy? Check this page out.
Application runtime security
So after embedding security in code development, and adding security steps to the build pipelines, we should now think about security when the application is running. Google Kubernetes Engine (GKE) and Cloud Run, which Cloud Build and Cloud Deploy can integrate with, are the two services where applications can run.
Google Kubernetes Engine (GKE)
GKE is Google Cloud’s managed Kubernetes service. Google Cloud embeds security by providing features such as container security posture, insights around cluster settings and workload configurations and vulnerabilities. A dashboard is provided for security posture, which scans GKE clusters and workloads for insights and recommendations for hardening your environment.
It's worth mentioning that Google just announced General Availability for GKE Enterprise, which allows for increased development, deployment, and security, for business-critical workloads.
For a deep dive into GKE and what you can do with the service, go over to this page.
Cloud Run
Cloud Run is also a managed service in Google Cloud for running applications. Cloud Run provides a security panel which shows security insights against software components used in your application. These insights show valuable information such as SLSA build level compliance as well as vulnerabilities in services that are running.
Additionally, you can leverage Google Cloud’s Binary Authorization feature. Binary Authorization helps with ensuring usage of container images in GKE and Cloud Run through trust-based policies. These policies enforce usage of only trusted container images based on attributes you define. For example, you can use Binary Authorization for specific environment deployments, using a dev image for the dev environments and production container image for the production environments.
You can learn more about Cloud Run, here!
Many services working to secure your cloud landscape
To summarize what was covered, the SDS, is a collection of services in Google Cloud, that help secure applications end-to-end, from code development, to build time, and run time. The benefit of using these services are they are all cloud-based, which allow for a seamless experience for securing applications in your Google Cloud organization.
Want to learn more about Google Cloud and its different areas such as Data & AI or Security? You can further deepen your cloud skills with the Innovators Plus subscription to take advantage of cloud credits, 1:1 consultations with Google Cloud Experts like me, access to over 700 hands-on labs, skill badges, and courses, and more!
About the Author
Disclaimer
My postings reflect my own views and do not necessarily represent the views of my employer, Accenture, or Google Cloud. The information in this blog post is general in nature and does not take into account the specific needs of your IT ecosystem and network, which may vary and require unique action. You should independently assess your specific needs in deciding to use any of the tools mentioned. The tools called in this blog are not Accenture tools. Accenture makes no representation that it has vetted or otherwise endorses these tools and Accenture disclaims any liability for their use, effectiveness or any disruption or loss arising from use of these tools.
