Why supply chain risk management is a top priority

0

If you sell to the federal government, you need to take a closer look at your supply chain risk management process.

The software supply chain is, as most of us know by now, both a blessing and a curse. It is an incredible, labyrinthine and intricate (some would say messy) web of components that, when working as intended, provides the conveniences and magical benefits of modern life: information and connections from around the world, as well as music, videos, and other entertainment, all in our pockets. Vehicles with lane assist and crash avoidance system. Home security systems. Intelligent traffic systems. And so on.

But when one or more of these components have flaws that can be exploited by criminals, it can be risky and dangerous. This puts the whole chain at risk. You know, the weakest link syndrome. Software vulnerabilities can be exploited to disrupt the distribution of fuel Where food. It can be used to steal identities, drain bank accounts, plunder intellectual property, spy on a nation, and even attack a nation.

The security of every link in the software supply chain is therefore important – important enough to make it part of President Joe Biden’s Executive Order of May 12, 2021, “Improving the nation’s cybersecurity” (also known as EO 14028).

It’s also important enough to have been one of the main talking points at the RSA Conference 2022 in San Francisco. Among dozens of presentations on the topic at the conference was “Software Supply Chain: Challenges, Risks, and Strategies for Success” by Tim Mackey, Principal Security Strategist at Synopsys Cybersecurity Research Center ( CyRC).

Software Supply Chain Challenges

The challenges and risks are many. For starters, too many organizations don’t always check the software components they buy or pull from the internet. Mackey noted that while some companies do thorough background checks on suppliers before buying — covering everything from management team, finance, ethics, product quality and other factors to generate a vendor risk assessment score – this is not the norm.

“The rest of the world is going through, in effect, an unmanaged procurement process,” he said. “In fact, developers love being able to download anything from the Internet and integrate it into their code.”

While there may be regulatory or compliance requirements for these developers, “they’re generally not there from a security perspective,” Mackey said. “So once you’ve decided that, for example, an Apache license is an appropriate thing to use within an organization, if there are unpatched CVEs [Common Vulnerabilities and Exposures] attached to anything with an Apache license, that’s someone else’s problem. There are a lot of things that fall into the category of someone else’s problems.

Then there’s the fact that the vast majority of software in use today – almost 80% – is open source, as documented in the annual report. “Open source security and risk analysis” (OSSRA) from 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 reason: it’s usually free and can be customized to do what the user wants, within certain license limits.

But, as Mackey noted, open-source software is usually done by communities of volunteers – sometimes very small communities – and those involved may eventually lose interest or be unable to sustain a project. This means that if vulnerabilities are discovered, they will not necessarily be fixed.

And even when patches are created to fix vulnerabilities, they are not “pushed” to users. Users have to “check them out” 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 patch, leaving them exposed. The infamous cluster of Log4Shell vulnerabilities in the Apache open-source logging library Log4j is one of the most recent examples.

6 Considerations for Securing Your Software Supply Chain

Manage your supply chain risks

Managing this risk requires serious effort. Simply tracking the components of a software product can become very complicated very quickly. Mackey talked about a simple app he created that had eight declared “dependencies” – components needed for the app to do what the developer wants it to do. But one of those eight had 15 dependencies. And one of those 15 had 30 more. By the time it reached multiple tiers, there were 133, for a single relatively simple app.

Also, within those 133 dependencies were “multiple instances of code that had explicit end-of-life statements associated with them,” he said. This means that it was no longer going to be maintained or updated.

And simply tracking components is not enough. There are other questions organizations should ask themselves, according to Mackey. They include, Do you

have secure development environments? Are you able to restore the integrity of your supply chain? Do you regularly test for vulnerabilities and fix them?

“It’s very detailed stuff,” he said, adding even more questions. Do you understand where your code comes from and what the controls are? Do you provide a Materials Bill of Materials software (SBOM) for every product you create? “I can almost guarantee that the majority of people on this [conference] the show floor doesn’t do that today,” he said.

Security is a coordinated effort

But if organizations want to sell software products to the US government, these are things they need to start doing. “The terms of the contract for the US government are being rewritten,” he said. “That means all of you who produce software that will be consumed by the government have to pay attention to it. And that’s a moving target – you may not be able to sell the US government the way you have it. used to do.

Even SBOMs, while useful and necessary – and a hot topic in supply chain security software— aren’t enough, Mackey said.

Supply Chain Risk Management (SCRM) is really about a set of coordinated efforts within an organization to identify, monitor and detect what is going on. And that includes software that you create and acquire, because even if it’s free, it still has to go through the same process,” he said.

Among these coordinated efforts is the need to address code components such as libraries within the supply chain that are outdated and no longer maintained. mackey said developers those who aren’t aware of this will frequently send “pull requests” asking when the next library update is coming.

And if there’s an answer, it’s that the component is end-of-life was end-of-life and the only thing to do is move to another library.

“But what if it all depended on it?” he said. “It’s a perfect example of the kinds of problems we’re going to run into when we start managing software supply chains.”

Another problem is that developers don’t even know about certain dependencies that they incorporate into a software project and don’t know if these may have vulnerabilities.

“OSSRA report found that the best framework with vulnerabilities last year was jQuery [a JavaScript library]. Nobody decides to use JQuery, it’s child’s play,” he said, adding that this is also true for others, including Lodash (a JavaScript library) and Spring Framework (a framework container and an inversion of control container for the Java platform). ). “They all came for the ride,” he said. “They are not part of any surveillance. They don’t get fixed because people just don’t know about them.

NIST Guidance on Software Supply Chain Security

There are many other necessary activities in SCRM that collectively aim to make the reliability of a software product much more likely. Many of them are contained in the software supply chain security advice released in early May by the National Institute of Standards and Technology (NIST) in response to Biden’s OE.

Mackey said this means organizations will need their “procurement teams to work with the the government team to define what the security requirements are. These requirements will then inform what the IT team is going to do, i.e. what a secure deployment means. So when someone buys something, that information is passed to procurement for validation. »

“A vendor needs to be able to explain what their SBOM is and where they got their code from, because that’s where the fixes need to come from,” he said.

Finally, Mackey said the biggest threat is the tendency to assume that if something is secure at one time, it always will be.

“We like to put checkboxes next to things – move them to the ‘Done’ column and leave them there,” he said. “The biggest threat we have is that someone is going to exploit the fact that we have a tick on something that is actually something dynamic, not something static that deserves a tick. It’s the real world. It’s messy, really messy.

Do not wait; start today

How prepared are software vendors to implement the security measures that will eventually be imposed on them? Mackey said he’s seen reports showing that for some of these metrics, the percentage is as high as 44%. “But around 18% is more typical,” he said. “People are getting a bit of the message, but we’re not there yet.”

So for those who want to sell to the government, it’s time to move on. “Time is running out,” Mackey said.

Learn how to manage your supply chain risk

Learn more

Share.

About Author

Comments are closed.