Malware targeting AI coding assistants and software developers’ automated workflows is spreading into more environments with more capabilities, placing defenders at a growing disadvantage.

A malware strain dubbed Sandworm_Mode, first discovered by Socket in February, represents a growing threat to software development. According to a CrowdStrike report, the self-propagating worm can spread through code repositories with minimal detection, raising alarms about software supply chains.

The malware’s capabilities are extensive, but not especially unique compared to the series of supply-chain worms known as Shai-Hulud, and more recently Mini Shai-Hulud.

“This is the new trend,” Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, told CyberScoop. “This is something we’re seeing more and more. It’s the new hotness right now.”

Sandworm_Mode targets and steals sensitive data, including credentials, keys and secrets that unlock paths to additional services and dependencies throughout the AI toolchain. This includes AI assistants, cloud providers, API keys for nine major LLM providers, CI/CD pipelines and automated systems that build, test and publish code.

These actions blend in with tens of thousands of other commands occurring daily in any given environment infused with AI development tools. 

“Trying to find the signal of something malicious happening is very difficult because there’s so much noise out there,” Meyers said. 

The worm also paces itself, setting multi-day delays to separate initial access from follow-on malicious activity — creating a gap in victims’ telemetry windows, which makes it even more challenging for defenders to detect and attribute the chain of infection properly. 

“AI agents are pulling down all of these different dependencies continuously throughout the day,” Meyers said. “When you’re looking downrange from the perspective of the security operations team, you’re just seeing everybody pulling down these dependencies, and these dependencies self-unpacking and executing, so it just gets really, really noisy to try to find something bad happening.”

The malware covers its tracks further with a bit of a mean streak, by automatically destroying compromised environments if it can’t spread or accomplish its objectives.

“It’s well thought-through, and well developed, so somebody spent some time caring and feeding this thing,” Meyer said.

Despite CrowdStrike’s four-month review of Sandworm_Mode, the cybersecurity firm has yet to gain a firm handle on its intent, but Meyers said it is designed to attain a strong foothold, which could enable long-term access.

CrowdStrike hasn’t determined who is responsible for the malware, yet Meyers said he doesn’t think TeamPCP, a threat group that’s been on a rampage through open-source software this year, is involved. 

“It could be a nation-state threat actor, or it could be an e-crime actor that’s looking to use this to then sell access to other organizations,” he said. “We don’t really know what the intention is.”

The state of Sandworm_Mode and whether it remains active is also unclear. CrowdStrike said it continues to observe recently active malicious supply-chain packages that follow similar but technically divergent patterns.

Ultimately, “the world has changed,” Meyers said, adding that many attackers are pursuing similar paths in the AI toolchain, requiring defenders and threat hunters to place a greater focus on this burgeoning mode of aggression.

The post Malware is targeting AI tools in software development environments appeared first on CyberScoop.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.

Isaac Burton // For as long as we have known about prototype pollution vulnerabilities, there has been confusion on what they are and how they can be exploited. We’re going […]

The post Hit the Ground Running with Prototype Pollution   appeared first on Black Hills Information Security, Inc..