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 services:

• Amazon Inspector – Vulnerability scanner for Amazon EC2, container images (inside Amazon ECR), and Lambda functions
• Microsoft Defender for Containers – Vulnerability scanner for containers
• Google Container Analysis – Vulnerability scanner for containers
• 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
  
• Scan your binaries to verify their trustworthiness – especially important when you import binaries from an external source.

Example of services:

• Microsoft Azure Attestation
• Google Binary Authorization

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 services for storing source code:

• AWS CodeCommit
• Azure Repos
• Google Cloud Source Repositories

Example of services for storing VM images:

• Store and restore an AMI using S3
• Azure Compute Gallery

Example of services for storing container images:

• Amazon Elastic Container Registry
• Azure Container Registry
• Google Artifact 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 services:

• AWS Identity and Access Management (IAM)
• Azure Active Directory (Azure AD)
• Google Cloud 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 services:

• AWS Secrets Manager
• Azure Key Vault
• Google Secret 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
• Best practices for a secure software supply chain
• Monitoring the Software Supply Chain with Azure Sentinel
• Software supply chain security
• Perspectives on Security – Securing Software Supply Chains
• NIST – Defending Against Software Supply Chain Attacks
• CNCF Software Supply Chain Best Practices