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 self-replicating malware campaign known as Mini Shai-Hulud has resurfaced, this time embedding itself across hundreds of npm packages. The threat actor behind it, identified as TeamPCP, has been linked to earlier waves of the same campaign, with this latest variant more capable than previous waves.

Researchers analyzing the payload found a worm that spreads autonomously, installs persistent backdoors at the operating system level, and is specifically engineered to survive the most common first response: removing the package.

How the attack works

The malware executes the moment an affected software package is installed, whether in a developer’s local environment or inside a CI/CD pipeline. A hook fires before any other step, giving the payload immediate access to the machine.

It harvests GitHub tokens, npm tokens, SSH keys, cloud provider credentials, and database connection strings. In automated build environments, it uses the pipeline’s own trusted identity to obtain publishing credentials, allowing it to push poisoned package versions to the registry under a legitimate maintainer’s name. The stolen data is sent to attacker-controlled GitHub repositories.

After it steals a publishing token, the malware checks every package that token can access, adds its code to those packages, and publishes new poisoned versions using the maintainer’s account. One infected CI runner — the machine or virtual server that automatically builds, tests and publishes code for a project — can therefore taint every package that runner is allowed to publish. It also searches a developer’s computer for other Node.js projects and copies itself into them, so a single infected install can compromise an entire workstation.

“If any of the affected packages ran in your environment, treat the machine or runner as exposed until secrets are rotated, persistence artifacts are removed, and recent publish activity has been reviewed,” Aikido Security researchers wrote in a blog post. 

Removing the package is not enough

Researchers found that a standard dependency rollback leaves the attacker’s access intact. The malware embeds backdoors in developer tool settings — notably .vscode/tasks.json and .claude/settings.json — which remain on disk even after the npm package is removed. Those files must be audited and cleaned to eliminate the attacker’s foothold.

The payload also installs OS-level background services: a systemd user service on Linux, a LaunchAgent on macOS. Both run a backdoor called kitty-monitor, which polls GitHub’s commit search every hour for signed remote commands. A second process, gh-token-monitor, checks stolen GitHub tokens every 60 seconds — alerting the attacker the moment one is revoked. An attacker can maintain access and monitor the victim’s response in near real time, long after the original infection has been discovered.

Multiple security companies have pointed out which popular dependencies are being targeted. In this wave, it’s been popular data visualization software, including Alibaba’s open-source AntV and TallyUI. The campaign also touched widely used utilities such as echarts-for-react (a React wrapper for ECharts) and timeago.js (a small JavaScript library that allows developers to format timestamps).

“Even if only a subset of those packages received malicious updates, the popularity of the package ecosystem creates meaningful downstream exposure for organizations that automatically pull new dependency versions,” wrote researchers from Socket, an application security company.

The campaign remains active. Because the worm propagates using tokens stolen from infected environments, the number of affected packages is expected to grow. Researchers have warned that any machine or pipeline that installed an affected version should be treated as fully compromised.

Last week, TeamPCP targeted other prominent software libraries with the malware, including TanStack, UiPath, and MistralAI.

The post Mini Shai-Hulud returns, compromising hundreds of npm packages appeared first on CyberScoop.