If you aren’t deeply technical, think of npm (Node Package Manager) as the world’s largest digital hardware store, but for software. You want to build a treehouse, or patch a wall, or replace a lightbulb with a more energy-efficient version…you go to the hardware store and grab your parts. It’s like this for developers, but for building software applications.

When developers build modern apps, the industry has advanced so much that they don’t need to manually build every single thing from scratch anymore. They import free, pre-built components (called “packages” or “dependencies”) from a registry called “npm” that hosts a bunch of useful tools to handle routine tasks so developers don’t have to re-do it every time there’s an app update.

You can check out some subreddits, like ProgrammerHumor, for raw takes in how we feel when news like this inevitably hits.

As we wait for our industry to land on a consensus around the total number of affected packages, let’s use one of the most popular packages as a simplified example to demonstrate the potential reach of how far one can go. Datadog has a csv showing 433 packages, SafeDep has a count around 353 packages while Aikido is estimating 868 packages, and the reality is that we’ll see how this count changes as everyone learns more.

TypeScript is one of the most downloaded packages on npm. In 2026 alone, it was downloaded 260.8 MILLION times from July 28 – August 3.

Most people don’t know what TypeScript is, but if you’ve ever submitted an online form, checked out on an e-commerce site, or used web apps like Slack or Microsoft Teams, you’ve relied on code built with it. When a utility at that scale has a vulnerability, it’s a systemic risk to the digital infrastructure millions of people–both technical and non-technical–interact with daily.

Every time an enterprise builds software, deploys an update, or runs an automated server check, their deployment systems fetch the package automatically. 

So when we see 260.8 million downloads, it shows how deeply embedded these components are in our entire global digital infrastructure ecosystem. It also shows the dependencies our digital systems have built that require subject matter expertise to maintain and navigate as we continue to grow in our distributed online workflows. 

And TypeScript is one of 3.1 million active packages available for use from npm. Furthermore, web apps aren’t made with just 2 or 3 packages. There was a security conference in 2019 held by the Advanced Computing Systems Association nonprofit, USENIX, where Markus Zimmermann of Technical University of Darmstadt (Germany) essentially explained that an average package implicitly brings in 79 indirect dependencies. 

The Structural Reality: When your core applications implicitly rely on dozens of nested dependencies, a single compromised link in the chain creates a massive blast radius. This expands your audit footprint far and wide, painting a clear picture of our interconnected digital web and highlighting why relying blindly on “vibe coding” introduces hidden vulnerabilities that non-technical leaders are rarely equipped to detect before it’s too late.

What’s interesting is that security vulnerabilities like this aren’t new for a lot of modern dev teams, but we might be at a point of software development where businesses will see an uptick in these types of incidents more and more and regret that they let their technical teams go.

Sometimes, business leaders don’t know how to appreciate when things are quietly working or that a very specific team has been the reason they’ve been able to avoid major issues.

In fact, we’re all hearing about it today (August 4, 2026), but there’s a message board in the Non-Human Identity Management Group from THREE days ago (I think the forum uses UTC time) that specifically calls out security issues caused by npm supply chain worms.

• Title: “npm supply chain worms: what IAM and security teams need to know“

I won’t spend time breaking down the step-by-step remediation or how the attack unfolded; security researchers over at Aikido Security and BleepingComputer have already published excellent technical post-mortems detailing the exact vectors. And Datadog has an entire timeline log of their discovery with suggestions on how people can check to see if they are impacted.

Instead, I want to talk about what moments like this mean for business leaders, and how executive teams should be stepping up right now. 

When a major supply chain vulnerability drops, your engineering team doesn’t need micromanagement–they need coverage and resources.

Here is how leadership can support technical teams during outage issues, data security incidents, or software attacks:

• Pave the Runway for Immediate Audits: Give your dev teams the explicit green light to pause non-critical feature shipping so they can audit dependencies, lock package versions, and patch build pipelines without panic. As the technical team, it sucks when you get on a panicked “All Hands on Deck” call and it seems like everyone is aligned with the next operating procedures. Verbally, you get the go-ahead to do what you need to do…only for a business leader to forget what they verbally wanted/approved later. And no one likes being thrown under the bus.
  • Send a quick note–it can be a Slack message, email, etc.–it just needs to be documented somehow so that the technical teams feel reassured that the business leaders are on the same page and mean what they say.
• Fund Technical Debt & Security Tooling: Supply chain attacks happen in the hidden layers of your infrastructure. If your team has been asking for dependency monitoring or automated security scanning, fund it today.
• Shield the Team from Noise: Communicate clearly with stakeholders and clients so your developers can focus on remediation rather than status updates. Let your clients know you may be asking them for redundant info they’ve already answered before, but it will help you crosscheck logs. As part of this, give them a heads up on what to expect and an ETA for when you’ll have more info for them:
  • For example: Issue them new credentials, swap our their tokens, revoke ALL permissions so they’ll lose all access…
  • “We’re working to rollback to a clean version. It’s going to take us about 2 hours to disable and test everything, I’ll have more info for you at 10:30 am PST.”
• SLA Review: While your engineering team is busy resolving the security incident, now would be a good time for your business unit to review your Service Level Agreements (SLAs) and any policies for the agreed-upon uptime so you can check how much downtime/offline bandwidth you have to work with before needing to reimburse clients. SLA uptime is the amount of time you essentially guarantee that your system will be up and available for client use. This means there’s a certain amount allotted for downtime that you bake into the year.
  • For example: 99.9% uptime = Your system is “allowed” to be down for 8h 45m 57s each year, and the client agreed to this in the contract.
  • The industry “Golden Standard” is the promise of “Five Nines”: 99.999%.
    • 99.999% = 5m 16s
    • 99.99% = 52m 36s
    • 99.9% = 8h 45m 57s
    • 99.5% = 1d 19h 49m 45s
    • 99% = 3d 15h 39m 30s
  • Speak the lingo:
    • Learn more about percentage calculation. If you don’t have a percent specified in your contracts, make this one of your tasks to tackle moving forward. Pick a percentage that gives your team some breathing room and is realistic for the kind of software maintenance required.
• Ask Your Team Leads What Else They Need From You: Sometimes your team just wants to know you understand it’s not a simple fix. Even if your team removes the infected packages, since the malware gained access through legit GitHub Actions workflows, you’re going to have to assume everything is compromised–including your CI/CD runner (automated pipeline tasks).
  • For example: Your team might realize some things later that they didn’t think of right when you originally asked.
  • Apparently, rotating keys triggers the malware payload from the npm supply chain attack. If the malware’s active processes are not terminated first or the payload isn’t removed, there’s a process that kicks off from credential-revocation watchers, so it’s like the attacker event keeps going.
  • This might be something your team discovers the hard way or through peers, and they will need your help handling external escalations and will probably want to sign up for some additional licenses to help prevent the same thing happening in the future.

Incidents like this are a loud reality check for the current tech landscape.

Right now, the trend is to assume AI tools and “vibe coding” can replace core subject matter expertise. What happens when everything your business depends on has been vibe coded? Would anyone on your team even realize there was a malicious dependency injected into your build pipeline, and do you have anyone with the muscle memory to escalate to?

AI tools are fantastic for speed, but they do not replace architectural intuition, deep security domain knowledge, or real-time situational awareness.

I know the landscape can look bleak at times. I’ve heard of one too many biz dev guys who took the ChatGPT output as their magic pill without understanding it was giving them word salad or even knowing how to tell ChatGPT that it was wrong. There are definitely some business leaders who (prematurely amped up by their sudden illusion of expertise as fueled by AI-assisted tools) mistakenly assume they no longer need software engineers.

And if I may, here’s my adaptation from the original:

The market for software engineers might feel tough right now, but hang on, friends! 

My estimate has always been that it’s going to take a bit of time for businesses to realize this, but in a couple years, businesses that over-indexed on quick AI shortcuts will be scrambling to hire experienced developers to fix, audit, or completely rebuild their fragile, “vibe-coded” systems. If developers can keep their skills fresh, they will be in high demand again.

In fact, we’re already seeing some impacts of organizations that didn’t realize how much token usage would cost them–the latest corporate trend, “tokenmaxxing”.

I know shiny and new things can sound like a dream-come-true. And I know that when technical issues happen, there’s an impulse to jump in and immediately try to find out “who did what”.

What often happens is when someone wants to help but doesn’t have the technical skills, they think expressing constant worry and concern helps show they care. It’s what they can do, but sometimes, the answer is actually doing nothing. Asking for constant updates can feel like you’re doing a good job “staying on top of it”, but it ends up causing friction with the teams who need to be trusted to do their jobs. 

For example:

• Broad messaging to buy the team more time
• Drafting a post-mortem or incident report that you can help fill in with details
• Realizing there are communications templates you would have liked to use but need to make
• Making food delivery credits available for teams on-call to respond to the incidents
• Or even reassuring your teams no one is in trouble because this is the cost of doing business in software.
  

Real leadership is about creating the structural conditions for technical excellence to thrive, and this might look differently than default jumping into the codebase or assuming that you know best:

• Audit Your Reliance on Shadow Code: Ask your teams to catalog where generative AI tools are being used across your build pipelines, ensuring critical logic is peer-reviewed by human subject matter experts.
• Invest in Continuous Education: Tech stack architectures evolve fast. Give your developers dedicated, paid time to stay sharp on security best practices, dependency management, and threat modeling.
• Formalize Your Incident Playbooks: Don’t wait for a high-severity alert to figure out who communicates with customers or legal. Build, test, and refine your operational response protocols during peace time.
• Measure Quality Over Pure Velocity: Stop evaluating engineering success purely by feature deployment speed. Reward code stability, security audits, and proactive technical debt cleanup.