This is the first of several blogs we will do on securing Software Supply Chains (S3C) which will cover topics such as:
- Security and Compliance
This blog will outline how you can improve your Software Supply Chain Security practices to reduce the opportunities for a bad actor compromising your builds while you incorporate internal or external dependencies with your code. These include items such as libraries, scripts, etc and their source. It will also suggest tooling to help you achieve this. The suggested tooling is based on Jetstack’s extensive experience of assisting clients improve the security of their Software Supply Chains (SSC) .
Most companies have implemented some form of a software supply chain practice at this stage. These usually cover the basics of coding, storing, building, packaging, and artifact storage. Many have yet to make their software supply chain practice secure. Remember the SolarWinds Orion compromise or the infamous and widespread Log4J Log4shell vulnerability?
The CyberArk 2022 Identity Security Threat Landscape Report shockingly stated:
“64% of respondents could not stop an attack from a compromised software supplier. At the same time, 71% of organizations were victims of software supply chain attacks, resulting in data loss or asset compromise”.
Bad actors are becoming very efficient at exploiting these stage 0 vulnerabilities.
Designing security into a SSC practice should be done upfront, not as an afterthought. This will reduce the attack surface and vectors available to bad actors. See the SLSA website for examples of source and build attack vectors. It will also save a lot of time, effort, and pain for all concerned. It’s vital all stakeholders play their part and make it part of your company’s SSC culture from the beginning.
Mitigating dependency risk
The 16th century English philosopher Sir Francis Bacon wrote:
“Knowledge is power”
Ok, he wasn’t talking specifically about external dependencies but he could have been, in that the more you know about the dependencies you, ahem, depend upon, the better you can evaluate their security posture and the risk they pose if used within your organisation. It is not practical to manually review all the external libraries and Images you are probably using in your team, let alone company, so automation and tooling is key.
With that in mind I’ll discuss some actions you can take now which will greatly increase your knowledge of dependency usage, and as part of this discussion I will mention various tools that we in Jetstack have had success with in this space.
- Understand and manage where dependencies can be pulled from. Conduct an audit by scanning your source code repos and rather than allow direct pulling from upstream, public registries, introduce an internal, trusted registry service from which all external dependencies should be pulled. As well as JFrog’s Artifactory, the major hyperscalers (GCP, AWS, Azure) all provide private image and artifact registries which have the ability to proxy upstream sources as well.
- Every dependency that is pulled into your organization should be scanned for vulnerabilities on a regular basis. There are a multitude of open source and commercial tools for doing this. A typical approach is to include it as part of your Continuous Integration (CI) pipelines, however artefacts should be scanned regularly as new vulnerabilities are found all the time, so you can’t just depend on scanning as part of your build process.
- Keep a central inventory of what dependencies are used in which applications and in which environments. This information is invaluable when you need to quickly understand the implications of a particular Common Vulnerabilities and Exposures (CVE) for your organization. We have found OWASP’s Dependency Track and Defect Dojo tools useful for the purpose.
- When evaluating whether to use a particular open source project, if it is hosted on Github, use Scorecard to understand its security health. Also search for the project on deps.dev.
There are many tools, both open source and commercial, for scanning and evaluating images, code libraries and other artefacts. Here I’ve summarized some of these that we have had good experiences with in Jetstack:
- Artifact Registries
- Artifact inventory management:
- Evaluating an open source project:
Improving the security of your software supply chains can be quite an undertaking - there is a lot to understand and consider - we in Jetstack recognise this and so we provide a Software Supply Chain Security Assessment Consultancy Service where we will work with you to review your existing or planned Software Supply Chain Security implementation in order to provide insights and recommendations as to how you can correctly implement or improve it. In the meantime, you can check out our Supply Chain toolkit. This serves as an excellent starting point for anyone who wants to secure their software supply chain.
Implementing Dependency Validation as part of your Supply Chain Security is vital. Bad actors are targeting companies earlier and earlier in their development life cycle. This makes it even more important for companies to secure their SSC practice now rather than pay the price later.
Getting buy-in from all stakeholders up front as a culture change can be the hardest hurdle to overcome. Do your due diligence up front, and put in place the validation and controls as a matter of urgency. You won’t regret it.
There are some excellent initiatives out there you can refer to regarding Supply Chain Security including:
- Supply chain Levels for Software Artifacts SLSA (pronounced Salsa)
- OWASP Foundation Software Component Verification Standard.
- National Cyber Security Centre UK (NCSC) Supply Chain Security Guidance
- Centre for Internet Security (CIS) Software Supply Chain Security Guide
- NIST National Initiative for Improving Cybersecurity in Supply Chains (NIICS),
At Jetstack Consult, we’re often helping customers adopt and mature their cloud-native and Kubernetes offerings. If you’re interested in discussing this, get in touch and see how we can work together.