SolarWinds shifted the conversation in 2020. Five years on, the conversation has lapped the practice. Most organizations still do not have real supply chain controls. They have questionnaires, a copy of a SOC 2 report, and an SBOM they cannot parse. That is not supply chain security. That is procurement with a security lipstick.
What has actually changed
The executive orders landed. NIST SSDF and the Secure Software Development Framework are now referenced in federal procurement. CISA pushed hard on attestation and SBOM formats (SPDX, CycloneDX). The Kaseya, 3CX, and MOVEit incidents reinforced the pattern: the compromise is upstream of your perimeter and EDR will not see it coming.
What has not changed: most mid-market and enterprise security teams still treat supply chain as a vendor risk management checkbox. That was never enough, and it is especially not enough now.
SBOM: useful, often misused
An SBOM is an inventory. It tells you that Acme Product 4.2 ships with Log4j 2.14.1 and OpenSSL 3.0.7. It does not tell you whether the vendor has patched, whether they used a private fork, or whether they shipped it securely. Treat the SBOM as raw material:
- Ingest vendor SBOMs into the same system that tracks your own vulnerability data. Unread SBOMs are filing cabinets.
- Join against KEV and EPSS. When Log4Shell-grade events happen, you want to answer "which vendors shipped us this?" in minutes, not weeks.
- Require SBOMs in contracts for critical software, but do not pretend requiring is receiving.
Vendor risk management versus vendor security assessment
These are different jobs and most programs conflate them.
- VRM is about the business relationship: onboarding, continuity, financial stability, data handling. Largely a procurement function.
- Vendor security assessment is a technical review: architecture, identity integration, logging, IR obligations, actual controls. It belongs in security.
A 200-question SIG questionnaire filled in by a vendor's sales engineer is neither. Prioritize: tier your vendors by access to data or infrastructure, and actually review the top 20. For the rest, a minimum control baseline in the contract is better than a questionnaire nobody reads.
Open source dependencies
For most organizations, the software supply chain risk is not commercial vendors. It is the five thousand open source packages your developers pulled from npm, PyPI, and Maven Central last quarter. The 2024 xz-utils backdoor was a near-miss that took three years of patient social engineering and was caught by one attentive engineer. Assume the next one is not caught.
Practical controls:
- A software composition analysis tool with real developer workflow integration — Snyk, Dependabot, Semgrep Supply Chain, or equivalent. Not another dashboard.
- Internal package proxies (Artifactory, Nexus) so you are not pulling directly from public registries at build time.
- Dependency pinning and lockfiles as hard requirements. Floating versions in production is how typosquat attacks succeed.
- Signed artifacts (
Sigstore,cosign) and provenance metadata (SLSA) for your own builds. The ecosystem is finally usable.
Your own build pipeline is part of someone else's supply chain
This is the part most teams miss. If you ship software, your build pipeline is a supply chain risk for your customers. The SolarWinds compromise worked precisely because the attackers modified the build environment, not the source. Look at yours with the same skepticism you apply to vendors:
- Who has access to push to the build system? When was the last time you reviewed it?
- Are builds reproducible? Can you detect a modified artifact?
- Are secrets scoped and rotated? CI runners are an enormously juicy target.
- Do you sign releases and publish provenance? Your customers will start asking.
Your security posture is now the maximum of your own controls and the minimum of your vendors' controls. The second number is usually lower.
The takeaway
Pick one concrete improvement per supply chain domain for the next quarter: an SBOM you actually ingest, one tier-1 vendor you technically reassess, one open source control you enforce in CI, and one hardening task on your own build pipeline. Five years of supply chain rhetoric has produced a lot of slides and not a lot of controls. Make your next year more honest than that.