The software supply chain is considered one of the common threats in today's modern cloud-native development, which poses a high risk to any organization.

It is about consuming software packages, source code, or even APIs from a third-party or untrusted source.

The last thing we wish to do is to block developers from building new applications, but we need to understand the threats to the software supply chain.

What are the common threats?

There are a couple of common threats that can arise from a software supply chain attack:

• Ransomware – An example is the NotPetya malware and Maersk
• Data breach – An example is the Okta Hack
• Backdoor – An example is the SolarWinds backdoor
• Access to private data – An example is the GitHub OAuth tokens attack
• API vulnerabilities – An example is the BOLA (Broken Object Level Authorization)

As we can see, most supply chain attacks begin with a download of an untrusted piece of code, which leads to malware infection, or pulling data from an external API, which inserts unverified data into a backend system.

Steps to mitigate the risk of supply chain attacks

The modern development lifecycle is based on CI/CD (Continuous Integration / Continuous Deployment or Delivery), we can embed security gates at various stages of the CI/CD pipeline, as explained below.

Source Code

• Scan for software vulnerabilities (such as binaries and open-source libraries), before storing components/code/libraries inside VM or container images inside an image repository.
  
  Example of service:

  • Amazon Inspector – Vulnerability scanner for Amazon EC2, container images (inside Amazon ECR), and Lambda functions

• Scan your code stored in your repositories, to make sure it does not contain sensitive data (such as secrets, API keys, credentials, etc.)
  
  Example of tools:

  • git-secrets
  • Gitleaks
  • SecretScanner

• Run static code analysis on any developed or imported code, to search for vulnerabilities.
  
  Example of tools:

  • Snyk – Scan for open-source, code, container, and Infrastructure-as-Code vulnerabilities
  • Trivy - Scan for open-source, code, container, and Infrastructure-as-Code vulnerabilities
  • Chekov – Scan for open-source and Infrastructure-as-Code vulnerabilities
  • KICS – Scan for Infrastructure-as-Code vulnerabilities
  • Terrascan - Scan for Infrastructure-as-Code vulnerabilities
  • Kubescape – Scan for Kubernetes vulnerabilities

Repositories

• Create a private repository for storing source code, VM images, or container images
• Enforce authentication and authorization for who can access and make changes to the repository
• Sign all source code/images stored in the repository

• Audit access to the repositories

  Example of service for storing source code:

  • AWS CodeCommit

  Example of service for storing VM images:

  • Store and restore an AMI using S3

  Example of service for storing container images:

  • Amazon Elastic Container Registry

  Example of service for storing serverless code:

  • AWS Serverless Application Repository

Authentication & Authorization

• Configure authentication and authorization process (who has written permissions to the repository), and enforce the use of MFA.

  Example of service:

  • AWS Identity and Access Management (IAM)

• Store all sensitive data (such as secrets, credentials, API keys, etc.) in a secured vault, enforce key rotation, and access management to keys.
  
  Example of service:

  • AWS Secrets Manager

Handling data from external APIs

There are many cases where we rely on data from external third parties, exposed using APIs.

Since we cannot verify the trustworthiness of external data, we must follow the following guidelines:

• Never rely on unauthenticated APIs – always make sure the connectivity to the external APIs requires proper authentication (such as certificates, rotated API key, etc.) and proper
• Always make sure the remote API enforces proper authorization mechanism - if the remote API allows admin or even write access to anyone on the Internet, the data it provides is not considered trusted anymore
• Always make sure data is encrypted at transit – it allows to keep data confidentiality and provides a high degree of trust in the remote endpoint
• Always perform input validation and proper escaping, before storing data from an external source into any backend database For further reading, see:
• OWASP API Security Project

Summary

In the post, we have reviewed threats as a result of software supply chain vulnerabilities, and various tools and services that can assist us in securing the modern development process of cloud-native applications.

It is possible to mitigate the risks coming from the software supply chain, whether it is code that we develop in-house or code/binaries/libraries that we import from a third-party source, but we must always follow the concept of "Trust but verify".

References

• Build your secure software supply chains on AWS
• Supply Chain Security on Amazon Elastic Kubernetes Service (Amazon EKS) using AWS Key Management Service (AWS KMS), Kyverno, and Cosign
• NIST - Defending Against Software Supply Chain Attacks
• CNCF Software Supply Chain Best Practices

About the Author

Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.

Eyal is an AWS Community Builder since 2020.

You can connect with him on Twitter and LinkedIn.