Centrally Managing Artifact Registry Container Image Vulnerabilities on Google Cloud: Part Two

In part one of this two part article we looked at how we could use Pub/Sub and Cloud Functions to aggregate container image vulnerabilities from Artifact/Container Registry across multiple projects and write them to a centralized location. The purpose of this was to provide a way to centrally manage all image vulnerabilities across an organization without the need to have access into every project using container images.

In our demonstration we used a Google Cloud Storage bucket for the storage location. In the real world, you would want to use a solution such as Security Command Center or your own SIEM.

In this second part, we are going to modify the Cloud Function that we created in part one to write the vulnerabilities directly into Security Command Center (SCC). We will also discuss how you would approach writing to your own SIEM.

The architecture will look like this:

A source in Security Command Center essentially acts as a container for security findings. SCC has a number of built in sources, such as Security Health Analytics, Web Security Scanner and Event Threat Detection. Additionally, a number of 3rd party sources are also available. We will create a custom source to act as a container for our container image vulnerability findings.

IMPORTANT: Sources and Findings cannot be deleted. Once created, they will continue to exist within your organization account and cannot be removed. It is recommended that you use a sandbox domain for any testing.

First, a quick bit of set up. We’ll need to enable the SCC API on our source project. Run the following in Cloud Shell.

gcloud config set project <project-id-source>
gcloud services enable securitycenter.googleapis.com

Now, let’s create the custom source. Unfortunately the creation of sources is not supported by the gcloud client, so we need to use the SCC REST API via a client library. We will create a Python virtual environment, install the SCC client library and run a short Python script to create the custom source. Run the following in Cloud Shell:

pip install virtualenv
virtualenv env
source env/bin/activate
env/bin/pip install google-cloud-securitycenter

We will need the organization id for the next step. Run the following gcloud command in Cloud Shell and copy the id for the domain you are using. We will refer to this as <org-id> in our scripts.

gcloud organizations list

Create a file in the Cloud Shell Code Editor called create_source.py in your home directory, paste in the following code and replace <org-id> with your organization id:

Before we can run this, the Security Command Center API does not permit user accounts, so we need to run in the context of a service account. We will use the one we created in part one. First, we need to grant it IAM permissions to be able create SCC sources and findings. You will require the values for <service-account-source> and <project-id-source> from part one. If you don’t have them, you can easily go back to the project in cloud console and view the service accounts to get the service account name.

gcloud organizations add-iam-policy-binding <org-id> \
--member=serviceAccount:<service-account-source>@<project-id-source>.iam.gserviceaccount.com \
--role=roles/securitycenter.adminEditor

Create and download a service account key with:

gcloud iam service-accounts keys create sa-creds.json \
--iam-account=<service-account-source>@<project-id-source>.iam.gserviceaccount.com
export GOOGLE_APPLICATION_CREDENTIALS=./sa-creds.json

Now we can execute our Python code:

python3 ./create_source.py

Copy the output of the command as this contains your new source id in the format:

organizations/<org-id>/sources/<source-id>

We don’t need the service account keys anymore, so let’s tidy that up:

rm ./sa-creds.json

Now we’re ready to go and update our Cloud Function to write vulnerability occurrences as findings in SCC instead of writing to the GCS bucket. In cloud console, go to the source project from part one and navigate to Cloud Functions. Click on the function “image-vuln-cf-trigger” and then click Edit.

Expand the Variables, Networking and Advanced Settings section and choose the Environment Variables tab. Add a runtime environment variable with the name SOURCE_ID, and the value of the source you just created in the format organizations/<org-id>/sources/<source-id>.

Click Next.

In the main.py file, replace the existing code with the following:

And replace requirements.txt with:

google-cloud-securitycenter
google-cloud-containeranalysis

Click Deploy.

Push an Image to Artifact Registry and View Findings in SCC

We are now ready to test pushing an image and viewing the vulnerabilities in SCC.

In Cloud Shell create a file called DOCKERFILE with the following code:

FROM nginx

On the command line run:

gcloud auth configure-docker us-central1-docker.pkg.dev
docker build --tag nginx-scc .
docker tag nginx-scc us-central1-docker.pkg.dev/<project-id-source>/<repo-name>/nginx-test-scc:staging
docker push us-central1-docker.pkg.dev/<project-id-source>/<repo-name>/nginx-test-scc:staging

Now we can go to the console and view the pushed image in Artifact Registry in the source project. Click on the image name and notice the vulnerabilities found (the scan may be in progress).

You can click through and examine each of the vulnerabilities found for the image.

Now navigate to SCC in the Security section of cloud console and switch to the organization level. Click the Findings tab and you should see a number of new findings created from the vulnerabilities found in the image scan. You can click to view each finding and view the source properties to see information such as severity, CVSS score and links to the affected image.

You can also click on View By “source type” to filter only Container Image Vulnerabilities.

Summary

Now that you have all of your image vulnerabilities published as findings in SCC, you can manage them like all other findings, adding security marks to the finding and setting it inactive once the vulnerability has been patched. Each finding provides information on the image affected, the project and the CVE information. SCC provides an easy way to list all vulnerability findings that are still active, giving an organization wide view of all of the unpatched vulnerabilities for the container images in Artifact Registry across all your projects.

In this two part article, we started with GCS as our storage solution, and moved to SCC. However, it would be relatively straight forward to modify our Cloud Function to write the vulnerability to your on-prem SIEM or to a Big Query dataset. You can find the vulnerability occurrence schema here.

Security Command Center API | Google Cloud