What the TanStack Attack Taught Us About Modern Supply Chain Risk

Software supply chain security requires continuous monitoring, verified remediation and incident response plans that teams rehearse.

• By Joe McManus
• Oct 12, 2026

What happens when third-party risk stops being a line item in a vendor review and becomes an active operational incident? A package, a dependency in a package, a workflow token, an OAuth grant, a CI/CD integration. Any one of these can become the foothold an attacker needs to get into your organization. But the uncomfortable truth is that the question was never really whether the vendor passed your risk assessment. It's whether your organization can detect, contain and recover once the trust you inherited from someone else gets abused. That is not to say that vendor reviews aren’t critical. They are, but also where third-party risk management begins rather than where security stops. 

Modern software runs on layers of inherited trust. We trust packages, credentials, APIs and the systems and people maintaining them.

The vendor questionnaire is just the beginning

For years, third-party risk management has run on a familiar loop: a vendor security questionnaire, a risk score, a color on a heat map, a signature on a risk acceptance form. It feels rigorous. These are key to understanding whether a new tool meets your minimum security standards or handles data in compliance with those standards. But modern software introduces another layer of risk that doesn’t fit neatly into that model.

Your third-party risk management (TPRM) process cannot protect against every package in your ecosystem. I’ll say the uncomfortable part - your developers are pulling in hundreds or thousands of packages, and even if they go through a review, their dependencies are not always being reviewed. Not following? Try running pip3 install matplotlib. Did you think you had to review all of those dependencies? Even if you review every dependency, you are updating and patching your dependencies and there is no practical way to conduct a manual TPRM on every single package your software stack is using at the speed those packages change, or you would never keep up with your patch hygiene. There is software that attempts to be your TPRM and there are things like cool-down periods that should help. Ultimately, this creates a fundamental tension: we cannot review our way out of software supply chain risk.

The attacks outnumber the defenders, and something will get through. It's the reason supply chain incidents keep catching well-prepared companies off guard. A questionnaire tells you what a vendor says about their controls at a point in time. It tells you nothing about what happens when one of their maintainers' credentials gets stolen and a malicious package version ships through a trusted pipeline six months later. If your security program's primary defense against that is a document review that happened once, you don't have a defense. You have paperwork.

The fix isn't a better questionnaire. It's treating software supply chain risk as an engineering discipline instead of a compliance function; something you monitor continuously, not something you assess once and file away.

Know what normal looks like before you need to

The single most useful thing any organization can do right now, before their next incident, costs nothing and requires no new tooling budget: baseline your environment. Know what your normal traffic, normal dependency graph and normal token usage actually look like. Simply put, if you don’t know what normal is, you will never know what abnormal is.

This sounds obvious, and that's exactly why it gets skipped. Most organizations discover during an incident, not before it, that what's documented on paper bears little resemblance to what's actually running in production. The first hours of any real incident get burned on a basic question: is this thing even in our environment? You cannot recognize abnormal behavior if you've never rigorously defined normal. That work has to happen on a quiet Tuesday, not at 2 a.m. during a live compromise.

Assume the miss, not just the hit

I got a harsh answer to that question in May. While out mountain biking (a different kind of risk management) in the desert on a Saturday morning, I got an alert on my phone, followed by an actual phone call. That was when I knew it was serious.

Grafana Labs was one of several companies, alongside GitHub, OpenAI, and Mistral AI, hit by the same campaign: a supply chain compromise that started with malicious versions of TanStack npm packages and spread through CI/CD credentials. We've already shared most of the technical details publicly, but there are a lot of takeaways from this incident, and the pattern it's a part of, that I believe should change how technology leaders think about risk, governance and readiness. Because the lessons apply well beyond one company or one npm package.
We had good detection. Our tooling flagged the malicious activity quickly. We moved to rotate every credential the threat intelligence told us could be affected. We still missed one.

That's the part worth sitting with. Good detection and a fast response are necessary, but they are not sufficient, because incident response under pressure is executed by humans working from imperfect information at speed.

Don’t just build a remediation checklist. Build the verification step that confirms the checklist actually worked. Build your process assuming that some percentage of your remediation steps will fail on the first pass and build in the follow-up checks that catch that failure before an attacker does. In our case, a second-pass token audit is now standard, not optional.

Decide your hard calls before you're making them under duress

When the ransom demand came in, threatening to release our source code, the decision not to pay was not one I wanted to be making for the first time in that moment. It's a decision every leadership team should make in advance, in a calm room, with legal, executive and communications stakeholders already aligned on the reasoning. The FBI's position is consistent: paying doesn't guarantee the data disappears, and it signals to every other threat actor that the tactic works. Whatever your organization concludes, the goal is to have already had that conversation before you're on a call with an attacker's deadline attached.

The same logic applies to a dozen smaller decisions inside an incident: who is authorized to talk to customers, who escalates to the board and when, what threshold triggers a CEO notification. If those answers are being invented in real time, you have already lost hours you didn't need to lose.

Technical controls without people controls will fail you

Most incident retrospectives focus entirely on the technical timeline. That's a mistake. The harder job during a multi-day incident is managing the humans running the response. Teams pull 20-hour days because they feel responsible. People stay on calls they don't need to be on because they're afraid of missing something. Judgment degrades quietly under sustained stress, long before anyone admits it out loud.

Build shift handoffs, mandatory breaks, and explicit check-ins into your incident process with the same rigor you apply to your technical runbooks. A tired team makes worse decisions, and worse decisions in an active incident cost more than the extra hours saved.

Rehearse until it's boring

Tabletop exercises get treated as a compliance checkbox at most organizations. They shouldn't be. The goal of a tabletop exercise is to make your response so routine that nobody has to improvise the basics while the actual incident is unfolding: who to call, how to reach an on-call engineer's manager directly when Slack goes quiet, how to export and securely store logs for a forensic review or legal discovery request. None of that is exciting. That's the point. You want your team to be bored with the process so they have bandwidth for the parts of the incident that actually require judgment.

If you want a starting point, take a public post-incident report, ours or anyone else's, and run your own team through it as a tabletop scenario. It's a faster way to find the gaps in your plan than any workshop.

There is no easy button for supply chain risks

I'd like to save every CISO reading this some time on vendor calls: I have not found a single product that solves supply chain risk on its own, and I'm skeptical that one exists. What actually reduces exposure is unglamorous and structural. Scope tokens down to the minimum lifetime and permission a task requires. Compartmentalize your CI/CD pipeline so a compromise in one place doesn't grant a path everywhere. Keep a human in the loop before any change reaches production, regardless of how trusted the source looks. Treat every upstream dependency the way you'd treat a package pulled from an operating system's public repository: verify it, don't assume it. All of that said, a layered security approach is never a bad thing; layering in one or more tools that attempt to secure the supply chain is worth doing, just don’t assume it is the easy button for TPRM.

The bigger shift

Governance, as most security teams have practiced it, is a list of things you're not allowed to do. That model doesn't scale against the pace of change in modern software supply chains, and it turns security into an obstacle that people quietly route around. The organizations that will handle the next incident better are the ones rebuilding governance as something tactical and continuous: policy enforced in code, identity and token usage mapped as a first-class asset and risk assessment that runs in something closer to real time than a quarterly review cycle.

We didn't get through the TanStack incident because we were smarter than the people attacking us. We limited the damage because we had done the boring preparation in advance, and because we chose to be transparent about what happened instead of managing the narrative. There will be another incident, at Grafana Labs or anywhere else. The only real variable is how much of the response you've already rehearsed before it starts.