Welcome to AppSec Unlocked, the podcast that demystifies application security one episode at a time. My name is Edwin Kwan and I'm your host for today, and we're looking at the 5 Steps for Securing Your Software Supply Chain.
The Growing Threat of Supply Chain Attacks
Before we dive into our five steps, let's set the stage. In today's software development landscape, we're seeing a massive shift towards the use of open-source components. In fact, developers typically write less than 15% of the code for their applications, with the rest coming from open-source libraries and frameworks.
While this approach accelerates development and promotes innovation, it also introduces significant risks. According to the annual software supply chain report, we're seeing an alarming 742% year-over-year growth rate in software supply chain attacks.
We've also witnessed the rise of "protestware," where developers intentionally sabotage their own open-source components. Remember the colors and fakers components incident? It resulted in a widespread denial of service attack.
But it's not just the software that's at risk. Developers themselves are becoming targets, with malicious programs being installed on their machines when they download seemingly innocent open-source components.
So, how do we protect ourselves and our organizations from these threats? Let's dive into our five crucial steps.
Step 1: Maintain a Software Bill of Materials (SBOM)
Our first step is to maintain a Software Bill of Materials, or SBOM. Think of this as a comprehensive ingredient list for your software. It should include all open-source components and their versions used in your applications.
Having an SBOM is crucial because it allows you to quickly understand your organization's exposure when new vulnerabilities are discovered. It's like having a map of your software ecosystem - when danger strikes, you know exactly where to look.
Additionally, each application should have a designated owner. This ensures clear accountability and makes it easy to determine who's responsible for maintaining the code when issues arise.
Step 2: Perform Due Diligence - Scan for Vulnerabilities
Next up, we need to perform thorough due diligence on all open-source components used in our applications. Just as we vet commercial software and suppliers, we need to apply the same rigor to open-source components.
This is where Software Composition Analysis (SCA) tools come into play. These tools can scan your applications for known vulnerabilities. Many organizations deploy these tools in their build pipelines to catch issues before they make it to production.
However, given the trend of attacks targeting developer machines, it's crucial to perform these scans even before components are downloaded onto developers' machines. And don't forget about your production applications - regular scanning is necessary to detect newly discovered vulnerabilities.
Beyond scanning, due diligence also involves sourcing components from reputable sources and avoiding unpopular or single-developer components. Remember, popular components benefit from more public scrutiny, making it more likely that vulnerabilities will be detected and fixed quickly.
Step 3: Have a Centralized Artifact Repository - Use Only Approved Software
Our third step is to establish a centralized artifact repository. This acts as a single source of truth for all approved components that have been scanned for malware and vulnerabilities.
A centralized repository provides assurance that you're downloading components from their official source, helping to prevent typo-squatting and dependency confusion attacks - two popular methods used in software supply chain attacks.
Many organizations use SCA tools with built-in rules or policies to automatically determine when a component is approved for use. Some even use their centralized repository to limit the number of open-source suppliers, focusing on using only the highest quality components for each functionality.
Step 4: Always Use Latest - Don't Use Stale Components
Step four is all about staying current. When using open-source components, always aim to use the latest version. This ensures you have the most recent bug fixes and security patches.
But it's not enough to start with the latest version - you need to be proactive about updating components in your production applications whenever newer versions become available. Patch management is crucial in managing your software supply chain, and it's an area that can quickly spiral out of control if neglected.
If you let your components get stale, it can be incredibly challenging to remediate when a security issue is discovered. You might find yourself facing numerous breaking changes in the newer, fixed version that also need to be addressed.
Some successful approaches I've seen include:
1. Implementing a policy where teams must update all stale components when making new changes
2. Setting aside dedicated time each month for updates
3. Automating upgrades using tools like GitHub's Dependabot
Step 5: Run a Web Application Firewall (WAF)
Our final step is to implement a Web Application Firewall, or WAF. There are times when fixed versions of open-source components aren't immediately available after a security vulnerability has been disclosed. There are also instances where your development teams need additional time to implement a fix.
In these scenarios, a WAF can act as a crucial line of defense, securing your organization while the fix is being applied. It's like having a security guard at the door while you're upgrading your locks.
Conclusion
And there you have it - five crucial steps for securing your software supply chain. Let's recap:
1. Maintain a Software Bill of Materials (SBOM)
2. Perform due diligence and scan for vulnerabilities
3. Use a centralized artifact repository
4. Always use the latest versions of components
5. Implement a Web Application Firewall
As our dependency on open-source components continues to grow, implementing these steps will be crucial in securing your organization's software supply chain.
Remember, unlike the code your developers write, you have little visibility into the secure development practices of open-source developers. By following these steps, you're taking proactive measures to protect your applications and your organization.
Share this post