Supply Chain Attacks After SolarWinds: What Actually Changed

SolarWinds is now five years in the rear view mirror, which is long enough to ask honestly whether the industry’s response to that incident has produced meaningful change in how supply chain attacks unfold. The short answer is yes, but unevenly. The patterns that defined SolarWinds – persistent access through a trusted vendor update channel, slow detection, broad blast radius – have been disrupted in some ways and have evolved in others. What replaced them is not always better.

This is an honest assessment of what changed in supply chain attacks since SolarWinds, what defenders have actually managed to operationalize, and where the gaps that defined that incident remain unaddressed.

The artifact-signing improvements were real

The most concrete progress since SolarWinds is in software artifact signing. Code signing has been around forever, but the post-SolarWinds push expanded the practice into build-pipeline attestation, dependency provenance, and SBOM generation. Major open source projects integrated Sigstore-style signing into their release pipelines. Cloud providers shipped attestation features that let customers verify that a deployed binary came from a known build chain. The major Linux distributions tightened their package signing infrastructure.

None of this is glamorous, and the adoption is still incomplete, but the gap between five years ago and now is real. An attacker who wants to insert a backdoor into a vendor update today has more technical obstacles than they had in 2020. A backdoor inserted into the build chain has a better chance of being detected before broad distribution. A defender investigating an incident has more information about what was deployed and where it came from.

The honest caveat is that the verification side has lagged the signing side. Many organizations now consume signed artifacts but do not actually verify the signatures, or verify them but do not enforce the chain. The infrastructure exists. The discipline to use it consistently does not always.

The vendor risk question is still mostly unsolved

Vendor risk management programs were the most popular post-SolarWinds response, and they have produced the least durable improvement. The pattern was familiar. Procurement teams added long security questionnaires to the vendor onboarding process. Compliance teams collected SOC 2 reports and stored them in shared drives. Risk registers grew long.

None of that addresses what made SolarWinds work. The attacker did not compromise the customer’s vendor onboarding process. The attacker compromised the vendor’s build pipeline. A customer reviewing the vendor’s SOC 2 report did not have visibility into that. The questionnaire did not ask the right questions. The risk register captured the dependency on the vendor but did not change what the customer could do about it.

The vendor risk programs that have produced real value are the ones that moved past paperwork. They run continuous monitoring against the vendor’s exposed attack surface. They require timely notification of security incidents and run tabletops that include the vendor. They constrain what the vendor’s software is allowed to do inside the customer’s environment, regardless of what the vendor’s own security posture looks like. That last move – assuming the vendor will eventually be compromised and limiting blast radius accordingly – is the durable response.

The blast radius story is mixed

The single biggest amplifier of the SolarWinds incident was the privileged position of the Orion software inside customer networks. The compromised update went to organizations where the software had network reach and credentials to do enormous damage, because that was what the product needed to do its job.

Defenders have responded to this in two main ways. The first is by constraining what monitoring and management tools can reach inside the environment. The second is by trying to reduce reliance on agent-based tools in favor of agentless approaches that do not need privileged credentials.

Both responses have produced real progress and real friction. Constraining monitoring tools usually means accepting reduced visibility into parts of the environment. Agentless approaches usually mean more API integrations and more tokens to manage. Neither is a clean win. The teams that handled this best treated it as a continuous trade-off rather than a one-time architecture decision, revisiting the access posture of each privileged tool periodically.

The build pipeline became the new perimeter

One of the more interesting evolutions is the recognition that the build pipeline – the CI/CD infrastructure, the artifact registries, the secrets management around build – is its own perimeter and deserves perimeter-level investment. The pre-SolarWinds posture treated CI/CD infrastructure as an internal tool, with internal security applied accordingly. The post-SolarWinds posture, where it has been adopted, treats CI/CD as critical infrastructure with controls comparable to production.

The controls that survived in practice include short-lived credentials for build jobs, hardware-rooted attestation of build environments, segregation between build infrastructure and the rest of the corporate network, and tightly controlled approval for changes to the build pipeline itself. The mature programs run their CI/CD security with the same rigor they apply to production database access.

This is uneven across the industry. Some organizations have made the shift. Many still treat CI/CD as a developer convenience that lives wherever developers want it to live. The next big supply chain breach will probably come from one of the latter group.

The open source dependency angle is different

SolarWinds was a commercial software supply chain attack. The dependency-confusion attacks, typosquatting attacks, and direct package compromises of the last few years are the open source equivalent, and they have a different shape. The attackers are working at much larger volume against much smaller individual targets. The economics are different. The defenses are different.

The defenses that have worked in this area are mostly about reducing the trust placed in individual packages. Locked dependency files. Reproducible builds where possible. Internal mirrors of public package registries with vetting controls. Allowlists for new dependencies. The major language ecosystems – npm, PyPI, Maven, Cargo – have all tightened their own controls over the last few years, but the responsibility for vetting what gets pulled into a build still sits with the consuming organization.

The teams that have brought this under control treat new dependencies as significant decisions, not casual additions. They have a policy for who can add a new dependency, what review is required, and how the dependency is tracked. They are also realistic that no policy survives contact with developer urgency, so they invest in tooling that makes the secure path easy enough that the policy is actually followed.

Detection capabilities improved less than the marketing suggests

The honest assessment of detection improvements is mixed. SIEM vendors expanded their supply chain detection capabilities. EDR products added behavior signatures that look for known supply chain indicators. SaaS security platforms ship dashboards that track third-party connections.

The catch is that the detection that mattered in SolarWinds – noticing that a trusted process was doing something it should not – is still hard. The attackers used the legitimate credentials of the compromised software to do work that, in any individual moment, looked like normal administration. The behavioral baselines were not strong enough to catch the divergence, and they mostly still are not. Detection has improved for the specific patterns that SolarWinds used. The general problem of detecting subtle abuse of trusted access is no easier than it was.

The teams that have improved their detection meaningfully invested in identity-centric monitoring – treating each privileged account, including service accounts, as a unit of behavior worth modeling – rather than in network-centric or endpoint-centric tooling. That is where the visibility gap was, and that is where the closing of the gap has produced real value.

Regulators are leaning in

The regulatory response to SolarWinds and the subsequent incidents has been substantial and is still building. The US executive order on cybersecurity, the EU Cyber Resilience Act, NIST SSDF, and various sectoral regulations have all moved in the direction of putting concrete supply chain security requirements on both software vendors and their customers. The SBOM requirements that started as a recommendation are progressively becoming a contractual and regulatory norm.

For software vendors, the practical effect is that having a defensible supply chain story is no longer optional in many markets. For customers, the practical effect is that they can demand more from their vendors and expect to receive it. The regulatory tailwind has accelerated changes that were already underway and pushed some that had stalled.

What still keeps defenders up at night

A few patterns are visible in current incident reporting that worry experienced defenders, and they have not yet been clearly addressed by the post-SolarWinds response.

The first is build infrastructure run by third-party services. CI/CD as a service, when compromised, has the same multiplier effect as a compromised vendor update channel. The visibility into the service provider’s security posture is limited, and the customer has even less control than they would over an on-premises build pipeline.

The second is the long tail of small vendors. The big vendors have improved. The small vendors – the niche SaaS, the regional integrators, the long-tail open source maintainers – are mostly in the same posture they were in five years ago. Attackers know this and are increasingly targeting the smaller links.

The third is post-compromise persistence in trusted update channels. Several incidents in the last two years have involved attackers who established access months before they used it, deliberately staying quiet to avoid the post-SolarWinds detection improvements. The detection of dormant supply chain compromise is still mostly aspirational.

The honest framing for the next five years

Supply chain security has gotten meaningfully better in some specific dimensions and not in others. Artifact signing and SBOM generation are real wins. Vendor risk management as practiced in most organizations is still mostly theater. Build pipeline security is the front line that defenders need to invest in next. Detection of subtle compromise of trusted access remains the hardest unsolved problem.

For a security leader assessing their current program, the useful question is whether the supply chain controls in place would have caught SolarWinds or the more recent incidents. If the controls are essentially the same paperwork-driven vendor risk management that existed in 2019, the answer is no, and the next five years will look like the last five unless something changes. The teams that have made real progress treated SolarWinds as a forcing function to rebuild their controls rather than as an excuse to grow their questionnaires.