The software supply chain has changed. Software used to be something we developed; now, it’s something we assemble from SDKs, open-source software, APIs, and so many other resources that we use to make our apps smarter, faster, and more interoperable. However, the downside of all this progress is that your software supply chain has become a black box, making it difficult to guarantee the integrity of all the artifacts in production or identify potential risks.
A single security flaw upstream could leave thousands, tens of thousands, or even millions of downstream users vulnerable. For instance, in the IconBust attack in 2022, attackers shared dozens of NPM modules containing malicious JavaScript code designed to harvest sensitive form data from apps and websites. NPM is the world’s largest and most popular open-source code repository, and the affected modules were downloaded over 27,000 times before they were discovered.
In a similar incident, over 2,500 NPM modules were found to be infected with CuteBoi, which takes advantage of unused server resources to mine Monero cryptocurrency. It’s impossible to know how many apps and software products now contain one of these malicious modules.
Do you know where all your software comes from? Releasing products with vulnerabilities—no matter how they got there—could have a major impact on a company’s reputation and even trigger regulatory fines or lawsuits.
Let’s have a quick look at why software today is so vulnerable, then explore four ways you can keep your organization—and your users—safe from today’s supply chain vulnerabilities.
Best Practices to Stay Protected
For each of the four most common areas where security issues can arise, we’ll share a few tips to help you identify these problems within your organization and maintain control over vulnerabilities in your software supply chain.
1. Verify Your Security Policy Configuration
Misconfigurations happen to all of us. In fact, in 2021, OWASP ranked security misconfiguration as the fifth most critical appsec risk, with over 73% of companies experiencing at least one critical security misconfiguration.
Why do misconfigurations happen? Sometimes they’re caused by a lack of training (or lack of current training), or when Ops team members are stressed and overworked. They can also be a result of assuming that “someone else” (such as your cloud provider) will take care of security.
For example, one product, a NoSQL database program, originally shipped with a default configuration that left the database completely open to unauthenticated users, leading to the exposure of more than 28,000 servers. In another case that made headlines, a multinational gaming and technology company sued its IT provider after an employee of the IT provider modified its security configuration, causing a data leak that affected 100,000 customers. Both the company and its IT provider were pointing fingers at each other when it came to taking responsibility for the leak.
Misconfigurations can lurk for a surprisingly long time before they are detected. For example, four South American airports were discovered to have compromised Amazon S3 bucket configurations, leading to the exposure of 3TB of data, around 15 million files, including PII and sensitive data belonging to airport employees.
Tips to address this challenge:
- Adopt a robust network infrastructure that is appropriate for today’s applications using all the tools at your disposal, such as segmentation, containerization, or cloud security groups (ACLs)
- Use tools that facilitate automation to simplify as many tasks as possible across development and production, such as automating security provisioning to sanitize configuration, implement greater uniformity, and verify optimal security settings.
2. Take a Cross-Siloed Approach
Despite best practices and DevOps methods, most organizations still work in silos. Sometimes, these gaps between different departments’ responsibilities create security issues. When multiple departments are involved, it can lead to a “buck-passing” mindset: Each department assumes a certain area is someone else’s responsibility.
While DevOps attempts to combat the traditional bifurcation between roles and approaches between Dev and Ops, the distinct approaches are often still visible in practice. Developers often see security as a separate function and simply adopt the best code to meet their needs, building functions and debugging where needed. Meanwhile, operations teams may not have tooling in place to maintain security during the development process, or may attempt to bring tools on board that inhibit or impede developers trying to do their work.
Tips to address this challenge:
- Create a multidisciplinary product team to share information, especially around dependencies and inherited vulnerabilities.
- Provide cross-functional training so that all team members are at least familiar with all aspects of the SDLC.
- Introduce a security champion program, creating a single point of contact for your development team while promoting security culture, awareness, and expertise across the entire SDLC.
3. Don’t Rely on Tribal Knowledge
The term “tribal knowledge” refers to the way things have always been done. The difference between tribal knowledge and best practices is that tribal knowledge is by definition undocumented; it refers to the unwritten rules of the organization’s culture and ways of working.
Sometimes these approaches remain undocumented for a reason: They’re not always the best ways of working.
Tribal knowledge can undermine cybersecurity in a few ways.
First, by definition, doing things “the way they’ve always been done” is a mindset that inherently resists change. And that’s a shame, because often, change toward best practices can yield significant improvement, particularly in security.
Development has changed in so many ways over the last few years. Tribal knowledge cannot keep up with the pace of change in today’s software development world—so by definition, it is fundamentally insecure.
Further, because tribal knowledge is undocumented, it centers expertise around a few key individuals. In some businesses, these individuals may even hoard this knowledge to ensure their own job security.
When it comes to the software supply chain, it is essential to instill—across all your teams—a mentality of documenting everything possible. Therefore, when it comes to tribal knowledge, your goal should be to create transparency. Approaches and techniques that work should be documented, preserving this information and transmitting it to existing and incoming employees. Those that don’t work should be replaced.
Tips to address this challenge:
- Listen to your team members; observe and document their workflows.
- Foster a culture of knowledge-sharing and improvement: Find out what’s really working—and then write it down!
4. Solve for Alert Fatigue
DevOps today comes along with many tools, each aimed at solving a specific problem. The issue is that many of these tools come with notifications, alerting the user when events occur; this can bring productivity to its knees. Ironically, the very tools that are supposed to make them productive can cut their productivity.
A very simple example: Slack, a productivity tool, constantly issues notifications that are designed to get attention and engage users instantly—no matter what they’re working on.
Often, the productivity benefits of DevOps tools are canceled out by the distraction they create. Instead of boosting developer productivity, these tools can create stress and confusion in developers’ minds, leading them to take shortcuts or not document procedures.
Tips to address this challenge:
- Protect developer workflows wherever possible, such as by choosing tools that integrate with existing workflows to avoid process switching.
- Implement automation wherever possible, such as automated provisioning to get developers up and running fast.
- Identify your primary sources of bottlenecks and streamline these first.
Introducing PBOM security standard
Many organizations underestimate their risk from software supply chain vulnerabilities. Sometimes that’s because they don’t have the full picture of their dependency on third-party, open-source, and other software.
Few organizations can be 100% sure that their software is free of supply chain vulnerabilities like IconBurst and CuteBoi. And while it’s becoming even more difficult to track and identify these risks, you certainly want to avoid the repercussions of releasing products with vulnerabilities that could impact your users.
To try to address the problem, some businesses have adopted software bills of materials (SBOM). The SBOM is essentially a list of all the ingredients that go into your software:
- Open-source libraries
- Vendor-provided packages
- First-party artifacts, i.e., original software your devs have created
The U.S. CISA calls an SBOM a “key building block in software security and software supply chain risk management,” and CISA Senior Advisor and Strategist Allan Friedman recently called SBOMs “key elements of software security [that] can mitigate the risk to the software supply chain and respond to new risks faster, and more efficiently.”
But while this is a step in the right direction, an SBOM is essentially a static list that may be sufficient for compliance but is not enough to guarantee security. You can’t count on it to give you a complete or reliable list of everything a piece of software has gone through.
For a more rigorous approach that keeps up with the way organizations develop software in the real world, OX developed pipeline bill of materials (PBOM) technology. A PBOM is a signed ledger of each pipeline build across the entire SDLC, including all version lineage, SLSA.dev, SaasBOM, security tool results, build hashes, and more.
PBOM technology goes much further than static SBOMs, giving you a real-time list of software lineage, from the first line of code all the way to release. That includes libraries and risks like licenses; out-of-date, poorly-maintained, and deprecated libraries; and more.
OX Security’s proprietary PBOM technology lets you fix risks post-production, or better yet, avoid them during coding. With integrated pipeline security, build integrity verification, and traceability, OX gives your developers the agility they need while minimizing the attack surface.
How can a PBOM keep your organization and users safer?
- Verifies the integrity and security of every single artifact – all software artifacts, binaries, packages, files, containers, and components – ensuring the provenance of each one and making sure nothing has been tampered with
- Gives you full visibility into every security issue that could affect your software, automatically tracking all pipeline branches, builds, pull requests, tickets, known issues and vulnerability management
- Provides clear, actionable risk prioritization that goes far beyond basic vulnerabilities, helping you ensure secure coding practices and tailor a strategic remediation strategy without hampering developer agility
With a PBOM that integrates directly into your development tools, workflows, and CI/CD pipelines, you’ll eliminate manual work while retaining full visibility into and control over your entire software supply chain attack surface.
OX is free for life for up to 20 developers. To get started for free, click here or get a demo with one of our product specialists. software
