The challenges and risks are abundant. For starters, too many organizations don’t always vet the software components they buy or pull from the internet. Mackey noted that while some companies do a thorough background check on vendors before they buy—covering everything from the executive team, financials, ethics, product quality, and other factors to generate a vendor risk-assessment score—that isn’t the norm.
“The rest of the world is coming through, effectively, an unmanaged procurement process,” he said. “In fact, developers love that they can just download anything from the internet and bring it into their code.”
While there may be some regulatory or compliance requirements on those developers, “they typically aren’t there from the security perspective,” Mackey said. “So once you’ve decided that, say, an Apache license is an appropriate thing to use within an organization, whether there are any unpatched CVEs [Common Vulnerabilities and Exposures] associated with anything with an Apache license, that’s somebody else’s problem. There’s a lot of things that fall into the category of somebody else’s problem.”
Then there’s the fact that the large majority of the software in use today—nearly 80%— is open source, as documented by the annual “Open Source Security and Risk Analysis” (OSSRA) report by the Synopsys Cybersecurity Research Center.
Open source software is no more or less secure than commercial or proprietary software and is hugely popular for good reasons—it’s usually free and can be customized to do whatever a user wants, within certain licensing restrictions.
But, as Mackey noted, open source software is generally made by volunteer communities—sometimes very small communities—and those involved may eventually lose interest or be unable to maintain a project. That means if vulnerabilities get discovered, they won’t necessarily get fixed.
And even when patches are created to fix vulnerabilities, they don’t get “pushed” to users. Users must “pull” them from a repository. So if they don’t know they’re using a vulnerable component in their software supply chain, they won’t know they need to pull in a patch, leaving them exposed. The infamous Log4Shell group of vulnerabilities in the open source Apache logging library Log4j is one of the most recent examples of that.