keepcalculator

06 Numbers and Powers

How to Secure the Supply Chain from Code to Cloud

Card No. 06·64096 · Updated · Standard formula, shown below

This guide walks you through securing your software supply chain from the moment code is written to the moment it runs in the cloud. You’ll learn concrete steps to protect against compromised dependencies, tampered builds, and unauthorized deployments, assuming you have basic familiarity with version control, CI/CD, and cloud platforms.

What You’ll Need

  • A source code repository (e.g., GitHub, GitLab, Bitbucket)
  • A CI/CD pipeline (e.g., GitHub Actions, GitLab CI, Jenkins)
  • Access to a cloud provider (AWS, Azure, GCP) or container registry
  • Package manager for your language (npm, pip, Maven, etc.)
  • Basic command-line skills

Step-by-Step

  1. Inventory your supply chain. Create a list of all components: source code, dependencies, build scripts, container images, CI/CD configuration, and deployment manifests. Use a software bill of materials (SBOM) tool to generate a machine-readable list of all open-source and third-party components.
  2. Harden your source control. Enable branch protection on your main branch. Require pull request reviews, status checks, and signed commits. Use SSH keys or deploy keys with least privilege, and rotate them regularly. Disable force pushes and ensure only authorized users can merge.
  3. Implement secrets management. Never store API keys, passwords, or tokens in code or CI/CD variables. Use a dedicated secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, cloud-native equivalents) and reference secrets by ID. Rotate secrets automatically where possible.
  4. Scan dependencies continuously. Integrate software composition analysis (SCA) tools into your CI pipeline. Run vulnerability scans on every commit and pull request. Set a policy to fail builds if critical or high-severity vulnerabilities are found. Keep dependencies updated with automated dependency bots.
  5. Use signed and verified dependencies. Prefer packages from official registries with checksums. Verify package integrity using lockfiles (e.g., package-lock.json, Pipfile.lock). Enable package signing where supported. Avoid fetching dependencies from untrusted URLs or git repositories.
  6. Build in a clean, isolated environment. Use ephemeral build containers that are destroyed after each build. Do not reuse build agents. Pin the base image and all build tools to specific versions. Run builds with least-privilege service accounts.
  7. Sign your artifacts. Sign container images and binary artifacts using a signing tool (e.g., cosign for OCI images, GPG for packages). Store signatures in a tamper-evident registry. Verify signatures before deployment.
  8. Scan container images for vulnerabilities. Use image scanning tools (e.g., Trivy, Grype, Clair) in your CI/CD pipeline. Scan for OS and application-level vulnerabilities. Also scan for misconfigurations like running as root or having unnecessary packages.
  9. Secure your CI/CD pipeline. Limit who can modify pipeline definitions. Use separate service accounts for builds and deployments with minimal permissions. Enable audit logging. Protect against secret exfiltration by not echoing secrets in logs.
  10. Implement policy as code. Use tools like OPA (Open Policy Agent) or Kyverno to enforce security policies on deployments. For example, require that all images come from an approved registry, have a valid signature, and do not run as root.
  11. Deploy with immutable infrastructure. Use infrastructure as code (IaC) tools like Terraform or CloudFormation. Never manually modify production environments. Apply changes through approved pipelines with peer review. Use canary or blue/green deployments to reduce risk.
  12. Monitor and respond. Enable runtime security monitoring on your cloud workloads. Use tools like Falco or cloud-native security groups to detect suspicious activity. Set up alerts for unauthorized changes, unusual network traffic, or privilege escalation. Have an incident response plan that includes rolling back to a known-good version.
  13. Audit and improve regularly. Conduct periodic security reviews of your entire supply chain. Update your SBOM after each release. Reassess third-party risk. Stay informed about new vulnerabilities and attack vectors.

Common Mistakes

  • Only scanning dependencies at release time, not during development.
  • Storing secrets in CI/CD variables or environment files.
  • Using the same credentials for build and production access.
  • Ignoring vulnerabilities in transitive (indirect) dependencies.
  • Not signing artifacts, so tampering goes undetected.
  • Allowing developers to bypass the pipeline for hotfixes.
  • Forgetting to secure the CI/CD tool itself (e.g., leaving it publicly accessible).

Tips

  • Start small: secure one project end-to-end before rolling out to all.
  • Automate everything: manual steps are error-prone and often skipped.
  • Use a software bill of materials (SBOM) to track components and licenses.
  • Leverage cloud-native security services (e.g., AWS Inspector, Azure Defender) for easier integration.
  • Keep your security tools updated; new vulnerabilities are discovered daily.
  • Educate developers on secure coding practices and why supply chain security matters.

Troubleshooting

Build fails due to vulnerability scan. If a critical vulnerability is found, first check if a patched version exists. If not, assess if the vulnerability is exploitable in your context. If it’s not exploitable, document the risk and request an exception. If it is exploitable, consider using a different library or implementing a workaround.

Signed artifact fails verification. Ensure the signing key is properly stored and accessible to the verification tool. Check that the artifact was signed with the same key you’re verifying with. If using a key management service, verify permissions and that the key hasn’t been rotated.

Pipeline secrets not available. Verify that the secret is defined in the correct scope (e.g., repository vs. organization). Check that the pipeline has permission to access the secret. If using a secrets manager, confirm the service account has the necessary IAM role.

Container image scan times out. Large images or many layers can cause timeouts. Optimize your image by using smaller base images, removing unnecessary packages, and using multi-stage builds. Increase the scan timeout if needed.

Deployment fails policy check. Review the policy rules and the deployment manifest. Common issues include using an unapproved registry, missing image signature, or running as root. Adjust the manifest to comply or update the policy if it’s too restrictive.

Frequently Asked Questions

What is a software supply chain?

It’s the entire set of processes and components that go into building and delivering software: source code, dependencies, build tools, CI/CD, containers, and deployment infrastructure.

Why is supply chain security important?

Attackers increasingly target upstream components (like open-source libraries) to compromise many downstream users at once. A single vulnerable dependency can lead to data breaches, ransomware, or service disruption.

What is an SBOM and why do I need one?

An SBOM (Software Bill of Materials) is a list of all components in your software. It helps you track vulnerabilities, ensure license compliance, and quickly identify affected systems when a new vulnerability is disclosed.

How often should I scan my dependencies?

At minimum, scan on every commit and pull request. Also, schedule regular scans (e.g., weekly) to catch newly published vulnerabilities in already-approved dependencies.

Can I secure the supply chain without using third-party tools?

Yes, but it’s harder. You can manually review dependencies, pin versions, and use built-in cloud security features. However, automated tools greatly reduce human error and are recommended for any serious project.

What is the difference between signing and scanning?

Scanning checks for known vulnerabilities in your components. Signing verifies that an artifact hasn’t been tampered with since it was built. Both are essential; scanning tells you if something is dangerous, signing tells you if something is authentic.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →