Securing your software supply chain

Challenge nameCloud(s)Challenge goalContributor
Securing Your Software Supply ChainGoogle Cloud, AWS, AzureImprove the security of your resume site by protecting your software dependencies from attack@forrestbrazeal

View or contribute to this challenge on GitHub!


The software supply chain is everything involved in getting code from your laptop to production: the code and configuration you write as well as any underlying packages and libraries they rely on (also known as “dependencies”). Securing the software supply chain, particularly these dependencies, from compromise is an emerging discipline in modern software development and infosec. The stakes couldn’t be higher - just check out this list of recent high-profile supply chain attacks.

In this challenge, you’ll extend your Cloud Resume Challenge project to add protections to your code and dependencies.

Helpful reading

Challenge steps

  1. Sign your Git commits to both the front end and back end resume repositories. You’ll need to set up a GPG key to do this. You’ll know it’s working when you see the “Verified” badge next to the commit in the GitHub console.
  2. Use status checks to ensure that only signed commits can be merged into your repository.
  3. Set up automated code scanning using GitHub’s CodeQL code analysis tool on GitHub Actions. Note that you will need to make your repositories public for this to work. You should automatically run the code scan any time a pull request is merged to your main branch and fail the merge if security issues at level “High” or higher are detected. You should also guard against dependency decay by running the scan on a schedule once per month. You will have to edit a config file to adjust the schedule.
  4. Generate an SBOM (Software Bill of Materials). An SBOM is a manifest that lists all the packages shipped in your container image or other code environment. As part of the build step in your back-end repository’s CI/CD pipeline, generate an SBOM attestation file for your deployment artifact using the open source tool Syft. (If you are shipping your code and dependencies as a zip file on AWS Lambda, not using a container image, you should still be able to point Syft at the unzipped deployment artifact to get an attestation.)
  5. Automate at least one additional vulnerability check in your CI/CD workflow. Using the package list in your SBOM, write some automation to run at least one other dependency check besides the GitHub automated scanning. Vulnerability databases are not always equally reliable, and it’s a good idea to check a couple of sources to provide defense-in-depth. Grype is a scanner that works well with Syft (and has its own GitHub Action). You could also consult an API such as OSV. Fail the build with an appropriate error message if you encounter a compromised dependency.
  6. [For container users only] Sign your container image using Cosign. If your Cloud Resume Challenge workflow involves building a container image, generate a KMS key on your cloud provider of choice using AWS KMS, Google Cloud KMS, or Azure Key Vault, then sign the container image with Sigstore’s Cosign tool before uploading it to AWS Elastic Container Registry (ECR), Google Cloud’s Artifact Registry, or Azure Container Registry. Make sure to include the Syft attestation from the previous step. This will verify for other consumers of this container that you have shipped the packages you said you shipped.
  7. [For AWS Lambda users only] AWS Lambda, which does not use a container-based deployment artifact by default, has its own code signing feature. Add code signing into your infrastructure-as-code definition for your API.
  8. Write up a blog post about what you learned! Include a diagram showing how code flows through your system and where attacks can be detected / mitigated. Reflect on where you may still have risks, and what other steps you might take if this were a more sensitive project, or involved multiple collaborators.