Securing the software supply chain in the cloud
Tags: aws, cloud, devops, opensource
Published: 2022-12-10 11:25:47

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](https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/)  
* Data breach – An example is [the Okta Hack](https://www.okta.com/blog/2022/03/updated-okta-statement-on-lapsus/)  
* Backdoor – An example is the [SolarWinds backdoor](https://resources.infosecinstitute.com/topic/sunburst-backdoor-malware-what-it-is-how-it-works-and-how-to-prevent-it-malware-spotlight/)  
* Access to private data – An example is the [GitHub OAuth tokens attack](https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/)  
* API vulnerabilities – An example is the [BOLA (Broken Object Level Authorization)](https://securityboulevard.com/2021/10/a-deep-dive-on-the-most-critical-api-vulnerability-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](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) – 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](https://github.com/awslabs/git-secrets)  
	* [Gitleaks](https://github.com/zricethezav/gitleaks)  
	* [SecretScanner](https://github.com/deepfence/SecretScanner)  
* Run static code analysis on any developed or imported code, to search for vulnerabilities.  
	Example of tools:  
	* [Snyk](https://github.com/snyk/cli) – Scan for open-source, code, container, and Infrastructure-as-Code vulnerabilities  
	* [Trivy](https://github.com/aquasecurity/trivy) - Scan for open-source, code, container, and Infrastructure-as-Code vulnerabilities  
	* [Chekov](https://github.com/bridgecrewio/checkov) – Scan for open-source and Infrastructure-as-Code vulnerabilities  
	* [KICS](https://github.com/Checkmarx/kics) – Scan for Infrastructure-as-Code vulnerabilities  
	* [Terrascan](https://github.com/tenable/terrascan) - Scan for Infrastructure-as-Code vulnerabilities  
	* [Kubescape](https://github.com/kubescape/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](https://docs.aws.amazon.com/codecommit/latest/userguide/security.html)  

	Example of service for storing VM images:  
	* [Store and restore an AMI using S3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-store-restore.html)  

	Example of service for storing container images:  
	* [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security.html)  

	Example of service for storing serverless code:  
	* [AWS Serverless Application Repository](https://docs.aws.amazon.com/serverlessrepo/latest/devguide/security.html)  

### 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)](https://aws.amazon.com/iam/resources/best-practices)  
* 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security.html)  


### 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](https://owasp.org/www-project-api-security/)  

## 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](https://d1.awsstatic.com/events/aws-reinforce-2022/DPP235_Build-your-secure-software-supply-chains-on-AWS.pdf)  
* [Supply Chain Security on Amazon Elastic Kubernetes Service (Amazon EKS) using AWS Key Management Service (AWS KMS), Kyverno, and Cosign](https://aws.amazon.com/blogs/opensource/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](https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf)  
* [CNCF Software Supply Chain Best Practices](https://project.linuxfoundation.org/hubfs/CNCF_SSCP_v1.pdf)  

### About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog [Security & Cloud 24/7](https://security-24-7.com/) and the author of the book [Cloud Security Handbook](https://amzn.to/3xMI4Ak), with more than 20 years in the IT industry.  
Eyal is an [AWS Community Builder](https://aws.amazon.com/developer/community/community-builders/) since 2020.  
You can connect with him on [Twitter](https://twitter.com/eyalestrin) and [LinkedIn](https://www.linkedin.com/in/eyalestrin/).