Recent attacks against developer tools and build pipelines should change how business leaders think about cybersecurity. The software pipeline is no longer a back-office technical detail. It is part of the company’s operating risk.
For years, many organizations treated cybersecurity as a perimeter problem: protect the firewall, harden user accounts, train employees not to click suspicious links, and keep endpoint protection running. Those fundamentals still matter. But recent software supply chain incidents are a reminder that attackers are increasingly looking for a more efficient route into the business: the tools companies trust to build, test, and deploy software.
In late May, CISA warned organizations to check their software development environments after attacks involving CI/CD pipelines, code extensions, and GitHub workflows. Reporting from Cybersecurity Dive noted that CISA referenced both the “Megalodon” GitHub Actions campaign and a compromise involving the Nx Console Visual Studio Code extension. Separately, StepSecurity reported that the Megalodon campaign injected malicious GitHub Actions workflows into more than 5,500 public repositories in a six-hour window, with the goal of stealing cloud credentials, API tokens, SSH keys, and other secrets from build environments. The Nx Console advisory on GitHub listed version 18.95.0 as compromised and urged affected users to rotate credentials and review systems for indicators of compromise.
The technical details are important, but the business lesson is bigger: attackers are going after the trust layer.
Why This Matters Beyond Software Teams
A software pipeline is the path code takes from a developer’s workstation to a production system. It may include source code repositories, automated tests, build servers, deployment tools, package registries, cloud credentials, and third-party extensions. In a modern business, that pipeline may touch customer portals, billing systems, internal applications, analytics platforms, integrations, websites, and cloud infrastructure.
That means a pipeline compromise is not simply an engineering incident. It can become a business continuity issue, a data protection issue, a vendor risk issue, and a customer trust issue at the same time.
When attackers compromise a developer extension or a workflow file, they may not need to break into the production application directly. Instead, they can steal the keys that production systems already trust. They can alter the process that creates software updates. They can use legitimate automation to move faster than a human reviewer can react. And because build systems often run behind the scenes, the attack may look like normal maintenance until someone reviews logs, secrets usage, or unexpected workflow changes.
The Opinion: Executives Should Stop Treating Development Tools as “Internal IT”
Here is the uncomfortable part: many organizations have stronger controls over who can approve a $5,000 invoice than who can change a build workflow that has access to production secrets.
That imbalance made sense when software development was a smaller, more contained function. It makes far less sense now. Even companies that do not consider themselves software companies depend on software delivery. They integrate SaaS platforms, automate workflows, customize cloud environments, maintain websites, build reports, and connect operational systems. The tools that support that work may have privileged access to data, infrastructure, and business-critical systems.
Business leaders do not need to manage every technical control personally. But they do need to ask better governance questions. Who can approve changes to deployment workflows? Which credentials are available to build systems? Are third-party developer extensions allowed by default? How quickly can the organization rotate secrets if a developer laptop, browser extension, or code repository is compromised? Are development systems included in incident response plans, or are they treated as something separate?
The answer to those questions determines how much damage an attacker can do after the first foothold.
What Businesses Should Do Now
The right response is not panic. It is disciplined housekeeping around systems that have quietly become mission critical.
First, review access to source code repositories and CI/CD systems. Require multi-factor authentication, remove stale accounts, and make sure service accounts are owned, documented, and monitored. If outside vendors or contractors have access, include them in the review.
Second, protect workflow files like sensitive code. Changes to build and deployment workflows should require review from people who understand their security impact. Automated commits and changes from unfamiliar accounts deserve extra scrutiny, even when the message looks routine.
Third, reduce the number and power of secrets available to build systems. Many environments accumulate old tokens, broad cloud permissions, and unused deployment keys. Those secrets are convenient until they are stolen. Rotate them regularly, scope them narrowly, and remove anything that is no longer required.
Fourth, treat developer tools and extensions as part of the approved software estate. A code editor extension can be powerful enough to read files, interact with terminals, and access authenticated sessions. That does not mean every extension is dangerous, but it does mean businesses need a policy for what can be installed, how updates are handled, and what happens when an extension is found to be compromised.
Finally, include software development environments in incident response exercises. If a pipeline compromise happens, the company should already know who can freeze deployments, revoke tokens, inspect workflow logs, rotate cloud credentials, and communicate risk to leadership.
A Practical Leadership Takeaway
The lesson from these recent campaigns is not that every business needs a giant security team. The lesson is that trust has moved. It now lives inside repositories, build systems, extensions, automation accounts, and cloud tokens as much as it lives at the network edge.
For business owners and technology leaders, the smart move is to bring software delivery risk into normal security governance. Ask for a simple inventory of development tools. Ask which systems can deploy to production. Ask how secrets are stored and rotated. Ask whether suspicious workflow changes would be noticed quickly.
Those questions are not technical micromanagement. They are responsible oversight of systems that now carry real business risk.
If your organization is unsure how exposed its development and cloud environments may be, Pierce CC can help assess the controls, close the obvious gaps, and build a practical plan for stronger cybersecurity without slowing the business down.
