On Sunday evening a security company published an analysis of an intrusion it had found in its own network, and by Monday morning the American cyber security agency had issued an emergency directive ordering federal civilian agencies to disconnect or power down the affected product immediately. The product is a network monitoring platform used by tens of thousands of organisations. The attackers did not break into it. They got inside the vendor's build process and had their code signed, shipped and installed by the customers themselves. The SolarWinds compromise is being described as a supply chain attack, which is accurate and slightly too comfortable. What was actually compromised is the mechanism we spend our professional lives telling people to trust: apply updates from your vendor, promptly, and verify the signature.
What is known, three days in
Be careful with the detail at this stage; much of what circulates this week will be revised. What appears established is that a malicious component was inserted into a signed library shipped with several versions of the Orion platform released between roughly March and June of this year. Once installed, it waited, typically around a fortnight, then resolved a subdomain of an attacker-controlled domain to receive instructions, behaving in a way deliberately designed to look like normal product telemetry. Where the target was interesting, the operators moved from that foothold into the wider network. Where it was not, they appear to have done nothing at all, which is itself a discipline most intrusion sets do not show. The affected customer base is enormous and the number actually exploited is much smaller. Several United States government departments have been named in reporting, including Treasury and Commerce. Reporting points to a sophisticated state-sponsored actor, and official attribution has not been made. Expect the victim list to grow through January. The vendor has issued a hotfix and a further release. Patching is necessary. It is not remotely the whole response, and the organisations treating this as a patch event are the ones who will still be compromised in March.
Why it defeated the controls we recommend
Every layer that should have caught this behaved exactly as designed. The code was signed with the vendor's legitimate certificate, so signature verification passed. It was installed through the normal update process by administrators following policy. It ran on a server that is expected to talk to everything on the network, because that is what a monitoring platform does, and expected to talk outbound to the internet, because that is what update checks and cloud features do. Its network traffic mimicked the product's own protocol. It checked for analysis tooling and stayed dormant in environments that looked like a laboratory. The uncomfortable conclusion is that our trust model verifies provenance rather than behaviour. A signature tells you where code came from. It tells you nothing about what it does, and we have built an entire industry practice on the assumption that those two questions are the same.
The second stage is the part that matters
If you find only the backdoor, you have found the least valuable thing. The tradecraft reported this week includes the theft of credentials and, more seriously, of the signing material used by identity systems, which allows an attacker to forge authentication tokens and present themselves as any user, including administrators, without ever touching a password. Reports also describe attackers adding their own credentials to existing application identities so that access persists after the obvious accounts are cleaned up. That changes the response completely. Resetting passwords does not help against forged tokens. Removing the malicious component does not help if the attacker established independent access weeks ago. If you were running an affected version and there are indications of second-stage activity, the working assumption has to be that identity itself is compromised, and remediation means rotating signing certificates and application credentials, reviewing every recently added credential and federation trust, and, in serious cases, rebuilding the identity infrastructure rather than cleaning it. That is a large, expensive and disruptive judgement to make in the week before the holidays, which is presumably part of the point.
| Evidence area | Question to answer |
|---|---|
| Deployment history | Which versions ran, on which systems, and during which period? |
| Network records | What do available DNS and proxy records show about suspicious activity? |
| Identity changes | Were credentials, application identities or federation trusts changed? |
| Residual access | What independent access still needs investigation after the entry point is removed? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to do this week
Start with facts rather than reassurance. Establish which versions you ran and when, from your own deployment records rather than from the vendor's list. Apply the vendor's fixed release or isolate the server. Then go to the logs that actually answer the question: outbound DNS resolutions and proxy records for the published command and control domains, covering the whole period from March onwards, not just the last thirty days. Most organisations discover at this point that their DNS retention is two weeks, which is itself a finding worth recording. If you find evidence of second-stage activity, stop and get help. This is not a self-service incident. Then widen the question beyond this product, because the durable lesson is about a class of software rather than one vendor. Monitoring platforms, remote management and deployment tools, backup systems, endpoint agents, patch distribution, identity and privileged access products: all of them run with high privilege, install agents everywhere, hold credentials for the estate and talk outbound to the internet. That is the management plane, and it is the most concentrated risk most networks contain. Inventory it, and rank each product by what an attacker would gain from owning it.
Practical Guidance for Software Supply Chain Assessment
- Inventory the management plane first, not the application estate. Anything with agents everywhere, domain-level privilege or credential custody. Usually between eight and twenty products, and almost nobody has the list.
- Constrain outbound traffic from management servers. Explicit allow-lists to vendor update endpoints, everything else denied and logged. This one control would have neutralised the backdoor's activation for most victims.
- Separate administrative identity from the management tools that use it. Dedicated service accounts with scoped rights, no shared domain administrator credentials embedded in monitoring and deployment platforms.
- Extend DNS and proxy log retention to at least a year, now. The investigation this week is failing in many organisations for want of six-month-old resolution logs, and that gap costs nothing to close.
- Write the credential and certificate rotation runbook before you need it. Identity signing material, application credentials, federation trusts, service accounts. Assume you will one day have to do all of it in a weekend.
- Ask vendors specific build-security questions at renewal. Who can modify the build pipeline, how are build systems isolated and monitored, is the released artefact reproducible from source, how would you detect an unauthorised change. Vague assurance is a finding.
- Stage updates for privileged management software rather than applying on release. A short soak period in a monitored environment is not a panacea, and it is the difference between being in the first wave and the third.
- Keep a version and deployment history you can query. What was installed, where, from which date. The organisations answering this week's question quickly are the ones with configuration records, not the ones with the best tooling.
The Regional Angle
Four consequences deserve attention here, and the first is genuinely awkward. This compromise arrived inside the data centre. A great deal of regional infrastructure sits on premises or in local facilities precisely because of sovereignty and regulatory expectations, on the reasoning that data held locally is data under local control. That reasoning is sound about jurisdiction and says nothing about software integrity: the malicious component walked through the front door as a signed update, into servers in your own building, under your own administrators' hands. Local hosting protects against a legal risk. It does not protect against a compromised update channel, and boards who have been told the two are the same should hear otherwise this week. Second, expect the regulators to write. Sector authorities in the Gulf, in banking, telecommunications and critical infrastructure, have moved quickly on incidents of this profile before, and the standard request is a written confirmation of exposure with a short deadline. Prepare the attestation now, in a form you can reuse: products and versions deployed, dates, evidence reviewed, findings, actions taken, residual risk and owner. Teams that draft this once, carefully, spend the rest of the month on investigation rather than on correspondence. Third, many organisations here will struggle to answer the basic questions because the software was bought and is operated through a reseller or managed service provider. The deployment records sit with the partner, the download account is in the partner's name, the support entitlement may have lapsed at the last renewal, and the emergency hotfix is therefore not something you can simply download. Ask your partner today for the version history, the installation dates and confirmation of your entitlement to the fixed release, and if the answer takes more than a day, that is the more important finding. Fourth, the timing is hostile in a specific way. Mid-December is change-freeze season, audit season and, across the region, a period of national holidays and accumulated leave. The people who know your monitoring estate are on a plane or unreachable, and the change advisory board that would approve emergency isolation does not meet until January. Decide now, at executive level, that this qualifies for emergency change authority, and name the person who can authorise disconnection at two in the morning without a meeting.
The objection worth taking seriously
The strongest objection is that there was no reasonable defence available. A well-resourced state actor subverted a vendor's build pipeline and had its payload signed with a legitimate certificate. No customer security programme, at any budget, inspects a vendor's compiler infrastructure. Telling organisations to assess their software supply chain after an attack of this sophistication risks being advice that sounds serious and changes nothing, and it will produce a great deal of questionnaire traffic that improves no one's security. The second objection targets where the industry will now go. The push for software bills of materials and build attestations, which will accelerate sharply from here, would not have stopped this. A compromised build system produces a perfectly accurate bill of materials for a compromised product, signed with a valid key. There is a real risk that the response to this incident becomes a documentation regime, paid for by suppliers, consumed by nobody, that leaves the actual attack path untouched. Both criticisms are right about prevention and wrong about the objective. The objective is not to prevent a signed malicious update; it is to ensure that one does not translate into total compromise. Egress restriction on management servers, credential separation, detection of anomalous behaviour from privileged systems and a rehearsed identity rotation runbook are all achievable with existing budgets, and each of them would have reduced the blast radius considerably for most of the organisations that will be named in January. That is the honest version of supply chain security: not trusting less, but arranging matters so that misplaced trust in any single component does not cost you the network.
Common Questions
We ran an affected version. Are we compromised?
Probably not exploited. The backdoor was distributed widely and used selectively. Your investigation should be aimed at second-stage indicators, particularly in DNS, proxy and authentication logs, rather than at the presence of the component alone.
Is patching enough?
Only if there is no evidence of second-stage activity. Where there is, patching removes the entry point and leaves the attacker's independent access untouched.
Should we stop using the product?
That is an emotional response rather than a risk decision. A vendor that has been thoroughly examined and rebuilt is not obviously worse than an unexamined alternative with the same privileges in your network.
What should we expect over the next twelve months?
Expect the victim list to lengthen considerably in January and to include organisations that have not yet started looking. Expect formal attribution and a diplomatic response. Expect government procurement rules to begin requiring build-security attestations, and expect commercial customers to copy those requirements into contracts. Expect insurers to add supply chain questions to renewals. And expect the term zero trust, already overused, to be applied to this incident by every vendor with a product to sell, most of whom will mean network segmentation rather than the identity controls this actually calls for.
Software Supply Chain Assessment — we inventory the management plane, constrain what it can reach, and build the credential rotation runbook you will need the next time a trusted update turns out not to be.