Copyright Ion Channel 2020
Software Supply Chain Risk Management
Problem & Opportunity
Lack of visibility and positive control of risks in third party software, including vendor products and
contractor deliverables. Code developed outside enterprise boundaries is subject to opaque
security criteria, and there are dangerous discontinuities between the emergence of risk in the
software supply chain, the customer’s awareness of those vulnerabilities and supplier provision
of remediated updates.
Software inventory and third party risk management is today where manufacturing inventory
management was in the 1980’s:
1. Very little positive control of what flows in from vendors to customers.
2. Very little visibility into their own (or suppliers) internally built software – customers
don’t know what’s in the software that suppliers have delivered, so there’s no way to
manage the risk of compromised dependencies.
3. No actionable time metrics associated with notification and remediation of
compromised deliverables. Lacking visibility, customers don’t know when and how
their suppliers’ products went bad. They don’t know how long it took suppliers to
detect or respond. And they don’t know when a compromised deliverable was
updated to a non-compromised deliverable. Without a stopwatch on these supply
chain events, it’s not feasible for customers to build and enforce contractual
guarantees and remedies, to effectively manage third party risk, or to raise the bar
for their suppliers based on time to remediation.
Even customers with sophisticated in-house cyber capabilities have not implemented effective
risk management for software suppliers, which includes vendors, contract or outsourced software
developers. Cyber certification regimes like DoD’s CMMC
for defense suppliers are a point-in-
time compliance drill – a snapshot – that gives suppliers a gold star for three years, with no
assurance that any given product will be remediated and updated within hours, days, weeks,
months or never
.
Enterprises must define and enforce actionable supply chain criteria for software running on their
infrastructure – vendor, contractor and internally developed code – and make sure that these
criteria are continuously and consistently enforced.
Transparency: Software Inventories and Bills of Materials
The first tactical step is relatively simple: know what you have.
Given the volume and velocity of
software dependency attacks – compromise of third-party software components of supplier code
– it is table stakes to require a Software Bill of Material (SBOM) from software vendors, contract
software developers and internal developer teams. This data should be structured, machine-
readable and must contain all direct and transitive dependencies (components of components) in
a software product or build. In forward-leaning industries like financial services, this is already
Cybersecurity Maturity Model Certification, https://www.acq.osd.mil/cmmc/
SAP had a critical vulnerability listed and unpatched for over 7 years:
https://www.zdnet.com/article/50000-enterprise-firms-running-sap-software-vulnerable-to-attack/
Sun Tzu Quote: “If you know the enemy and know yourself, you need not fear the result of a hundred
battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If
you know neither the enemy nor yourself, you will succumb in every battle”
