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.

A defense technology company with Department of Defense contracts exposed user records and military training materials through API endpoints that lacked meaningful authorization checks, according to an account published by Strix, an open-source autonomous security testing project.

The issue affected Schemata, an AI-powered virtual training platform used in military and defense settings. According to Strix, an ordinary low-privilege account was able to access data across multiple tenants, including user listings, organization records, course information, training metadata and direct links to documents hosted on the Schemata’s Amazon Web Services instances.

Strix said the exposed materials included a 3D virtual training course for naval maintenance personnel with documentation marked confidential and proprietary, a course containing Army field manuals on explosive ordnance handling and tactical deployment, and hundreds of user records linked to bases and training enrollments. Additionally, the exposed information included names, email addresses, enrollment details and the military bases where U.S. service members were stationed. 

Schemata acknowledged the affected endpoints were exposed May 1, after what Strix described as a 150-day disclosure process. Strix said it verified remediation before publication and published its account earlier this week, 152 days after its initial disclosure attempt.

The reported vulnerability did not require a complex exploit. Strix said it used a low-privilege account to watch normal browser traffic, identify API endpoints exposed through the application, and request high-value data using the same session. According to Strix, those requests returned records from outside the account’s own organization, suggesting the API was not properly enforcing tenant boundaries or user permissions.

In multi-tenant software, authorization controls are intended to ensure users can access only the data and functions assigned to their account or organization. The failure described by Strix would represent a basic breakdown in that model. The firm said some routes also appeared “write-enabled,” meaning a malicious actor could potentially modify or delete courses through update or delete requests, though the account does not say Strix performed destructive testing.

Strix did not respond to CyberScoop’s request for comment. 

Schemata’s platform serves military and defense training environments, where user identities, assignments and course enrollments can reveal sensitive operational context. Even when information is not classified, records showing where service members are based, what training they are enrolled in and which materials they can access may create risks if exposed outside intended channels.

In a statement posted on the company’s website, Schemata said it did not have “evidence that any third party exploited the vulnerability to access customer data.”

The disclosure timeline also raises questions about how companies handling sensitive government-related data receive and respond to vulnerability reports. Strix said it first contacted Schemata on Dec. 2, 2025. According to the account, Schemata’s CEO initially responded, “I would love to hear what the vulnerability is, but I assume you want to get paid for it. Is that the play?”

Strix said it clarified the same day that compensation was not required and that its priority was user safety. It said it sent multiple follow-ups from Dec. 8-29, warning that the vulnerability was critical and asking where to send details. Five months later, after telling Schemata that researchers were publishing the information publicly, Schemata responded, acknowledged the exposed endpoints and said it would patch the issue immediately.

“After we received actionable details about the vulnerability and confirmed the security researcher appeared to be legitimate, our team remediated the vulnerability the same day, and the researcher independently verified the fix before publishing their findings,” Schemata’s statement reads. “We appreciate the security researcher bringing this to our attention and their contribution to the security of our platform.”

Schemata said it’s working with cybersecurity consultants to assist with its response and improve its security posture. The company also said it is in contact with government authorities about the vulnerability.

Defense contractors that handle Controlled Unclassified Information, or CUI, must report cyber incidents to the Department of Defense Cyber Crime Center (DC3). The center did not respond to CyberScoop’s request for comment. 

According to contracting data, the company holds $3.4 million in contracts with the Department of Defense. In May 2025, Schemata announced $5 million in venture funding from several firms, including Andreessen Horowitz. 

The post A DOD contractor’s API flaw exposed military course data and service member records 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..