Keeping up with supply chain threats is hard work and, unfortunately, never-ending.
There are some good frameworks out there that, when implemented, minimizes the risk of exposure. But for smaller organizations it can be a challenge to get the resources and time to implement them correctly. Not to mention keeping them maintained over time.
One such framework is NIST Cybersecurity Framework, another one is the emerging Supply chain Levels for Software Artifacts (or SLSA “Salsa”) - inspired by Google’s internal “Binary Authorization for Borg” - it takes an interesting approach of defining 4 distinct levels of security when it comes to supply chain security.
Below is my personal top-“if you haven’t done anything, you should at least do this” -list. Make sure you at least have this in place.
Make sure you know who submitted code to your application
It might sound trivial but failure to protect against this opens up your software to a common attack vector, make sure that you know who submitted changes to your code by using industry best practices. Use strong passwords, do not reuse passwords between different sites and systems and don’t forget to enable Two Factor Authentication (2FA) where possible. Make sure you handle off-boarding of users in a consistent manner. If possible keep account administration in one place by utilizing integration by OAuth / SAML or similar protocols.
Read more: SLSA Verified history
Automated and reproducible builds
Make sure that the software that you produce is produced in the same way every time. You don’t want to depend on individual developers remembering all different steps taken every time. Script the build process and use tools that automate this process such as Github Actions or build CI/CD tools such as Jenkins, Teamcity etc.
Further references: SLSA Scripted build / Build as code / Build service / Isolated
Collaborate / 2 Person review
Make sure that you have more than one pair of eyes on what gets accepted into your code base. There are many reasons why you should be vigilant here. The easiest, however good-intended reason is the fact that we all make mistakes - and having a peer to review your work, check for everyday mistakes is a cheap way of preventing costly downtime. It also has great side effects of knowledge transfer within the team, which in the long run makes your organization less vulnerable to people leaving, lessens impacts on long-term absence etc. The other major benefit of preventing any single individual from committing code without a peer review is that there is significantly less risk of two people becoming compromised and willfully committing vulnerabilities and malware.
Private Registry for dependencies
With millions of public open source packages accessible by your developers and automated environments, it’s imperative to stay in control over the packages in your supply chain. Using a private registry where you are in control of what components that your application is using is key to delivering a secure product every time, every build. There are other benefits as well, outages of public registries are known to happen, maintainers that without warning delete components that you rely on.
Patch, Patch, Patch
Keep an eye on vulnerabilities and update your code promptly. The risk of someone exploiting a known vulnerability increases exponentially over time if left unmanaged. Make sure that you have a process in place that requires you to take action once vulnerabilities are discovered. And make sure that everyone in your organization knows about it.
Tools such as Bytesafe let you manage found vulnerabilities in a structured way to make sure it is not overlooked or forgotten.
Read more on OWASP Top 10: OWASP Vulnerable and Outdated Components
Keep credentials Safe
Keeping secrets…secret can be challenging. A good starting point is to keep secrets separated from your code. Using a modern password manager with access control and audit logs is a good idea. OWASP has an entertaining project to highlight what you should not do when it comes to secrets called Wrongsecrets.
Encrypt everything
Well perhaps not everything, but make data integrity a priority. Both in transit and at rest. Make sure that your data stays safe. For organizations relying on cloud providers this should not really be a problem, most of the tools are at your disposal. If you are struggling with legacy systems, make sure to identify your assets and make a prioritized list that you can continuously improve on.
Learn more
If you are curious about understanding where you could improve your own security, we have developed a short assessment that gives you a few pointers and will guide you in the right direction, it’s free and available here:
