Can There Be Trustworthy Software Supply Chains?

By Matt Gillespie

Supply chain security depends on its weakest link, a problematic reality for software because so many links are hidden from view.

When the software vendor acts as the root of trust for its customers, verifying product authenticity is more or less equated to verifying safety. But that system of belief breaks down if the vendor itself is compromised, as when SolarWinds’ trusted components proved untrustworthy after a cyberattack in early 2020.

Because the root of trust was itself the target, the attack surface included everyone who depended on it. That dynamic recalls the value of the Russian aphorism, “Doveryai, no proveryai”—trust but verify.

Exert Governance over Vendor Relationships

The SolarWinds hack was not unique, but its high profile and government impact can be expected to release the hounds of lobbying and legislation, which may demand stricter practices at large independent software vendors and improve supply chain safety.

Even so, as always, ultimate responsibility for everything installed on a network falls to the owners of that network, so let the buyer beware.

In verifying a software maker’s supply chain security practices, customers must work around visibility limitations placed there to protect sensitive security details and intellectual property. The chief way of doing so is to create and enforce procurement standards that place formal due diligence requirements on software suppliers.

A simple example is to engage only with software suppliers that have documented, robust practices in place to avoid, detect and respond to supply chain attacks.

That requirement may be part of a broader one for documenting the overall practices software vendors use to ensure product security, from static code analysis to black-hat testing.

Investigating the certifications a vendor holds for regulatory frameworks such as PCI or HIPAA can also be useful. The audits that software companies must pass for such certifications attest to sound internal governance over security systems and procedures.

Protections built into contracts are also part of supply chain threat mitigation. Language may govern how quickly the vendor must report security breaches after their discovery, for example. In some cases, an indemnification provision may give customers added protection from potential security-related financial losses.

Redouble Efforts to Be Scrupulous About IT Hygiene

Surveying the scores of applications already deployed highlights the limitations of procurement measures alone.

System bloat is an uncomfortable reality in most large organizations, where layers of software can accrete over time to create an overlapping, unmanageable thicket. Because disentangling and decommissioning applications must compete for time and resources with more forward-looking projects, piecemeal environments with too many pieces are common.

Setting aside the unique threat of unsupported legacy software, even fully patched, up-to-date applications are susceptible to supply chain attacks.

Therefore, adapting a zero-trust orientation of sorts to the supply chain, all software should be regarded as a threat, so that removing software from the production environment is properly regarded as removing a potential threat. With that orientation in mind, the financial and business value of projects to decommission software become more apparent and easier to justify.

 

Attention to supply chain risk can also inform corporate policies and standards that require software and services to be validated by the IT security organization on an ongoing basis.

Scrutinizing the pedigree of every application, microservice and plugin is likely impossible, and that goal is more obtainable for some solutions than others.

For example, major providers of CRM, ERP or enterprise database software provide more robust assurances than smaller vendors of more limited means. That reality does not disqualify smaller providers, or even favor larger ones, but it does highlight the value of a formal approach to supply chain risk, which may draw from frameworks such as the NIST Cyber Supply Chain Risk Management (C-SCRM) project.

In addition, quantifying the supply chain risk associated with individual technology ingredients may be a valuable tool to help analyze the internal threat landscape, validate vendors and support objective comparisons between solutions.

Validate and Adapt Cyber Measures that Protect the Supply Chain

One defining characteristic of supply chain attacks is their sophistication; in most cases, the adversary is a nation-state. Guarding against and detecting them is difficult—the SolarWinds compromise was not found for months—in any of the thousands of affected organizations.

In response, existing security standards should be reassessed through the lens of threats from the supply chain, bearing in mind that, in terms of IT and security operations, measures to address software supply-chain risk overlap with those for other threats.

Supply chain compromises may be detectable by the threat-hunting practices that are becoming common in large organizations. For example, a trojan that was secreted away inside a software update might itself remain well hidden, while its behaviors (or those of remote command and control) may be more detectable.

An attack may be revealed by unusual patterns of data access, signs of lateral movement or evidence of data exfiltration.

The intelligence gathering and behavioral analysis role of threat hunting works alongside measures that actively interfere with attacks. IPS tools can disallow suspicious activities, while data exfiltration may be thwarted by configuring safe lists on routers and firewalls that limit the domains where even trusted applications can send data.

Proactively guarding against supply chain attacks combines business measures such as vendor due diligence with technology measures based on tools and best practices, for a jointly assured security posture.

Matt Gillespie is a technology writer based in Chicago. He can be found at www.linkedin.com/in/mgillespie1.