Securing the Software Development Lifecycle and Supply Chain in an AI-Forward World

It’s no secret how artificial intelligence (AI)-powered tools and systems, which promise users exponential productivity, growth, and efficiency, have quickly become integral in organizations' processes and workflows. AI — specifically generative AI (GenAI) and large language models (LLMs) — is now a foundational element of the software development process, allowing developers to build and scale software at a velocity that would have been impossible a mere decade ago. These technologies have permeated the software development lifecycle (SDLC), from ideation to maintaining software, ensuring that concepts are translated swiftly into code.

With AI tools at their disposal, software developers and engineers can take on tasks that go beyond the rote and instead, transition into design and management roles where their judgment and expertise are highlighted. While AI takes on many time-consuming and routine SDLC tasks, developers can focus on other important aspects of their job, such as design and system innovation and creating customer-centric solutions.

But like all technological breakthroughs and integrations, AI in the SDLC is not above security risks; with the unparalleled speed that AI brings to the software development process, it’s also bound to come with threats. In this article, we look at the AI threats to the SDLC and supply chains. We also provide security recommendations that organizations can adopt to keep their AI-powered environments secure.

AI-Related Threats to the SDLC

AI ushered in the democratization of software development, allowing even non-technical users and teams to develop their own apps and services sans comprehensive coding knowledge. LLMs have paved the way for vibe coding, a software development practice wherein AI is used to generate and refine code for an app or service through natural language prompts.

Vibe coding banks on the intuitiveness of AI tools to revolutionize the way apps are prototyped, demoed, and built. However, the speed at which these apps are created can also give way to quality control and decision-making challenges. Because vibe-coded apps can be birthed just mere hours after ideation, quality review processes, ownership rights, and security safeguards are inadvertently leapfrogged. When this happens, security vulnerabilities can creep into apps and an organization’s environment. Researchers from Georgia Tech’s School of Cybersecurity and Privacy found that 35 CVEs can be directly attributed to AI coding tools.

In December 2025, Tenzai researchers assessed five coding platforms (Claude Code, OpenAI, Codex, Cursor, Replit, and Devin) to create three test apps for each. Among the 15 total applications created using the five AI coding platforms, they discovered 69 vulnerabilities, 45 of which were rated low-medium in severity, and around half a dozen were found to be critical.

In a separate study, RedAccess researchers found that 5,000 vibe-coded apps created using Lovable, Replit, Base44, and Netlify did not have any form of security or authentication. The researchers found that many of which granted anyone who had access to the web URL access to the apps and their data, including sensitive information such as financial data, detailed chat logs with chatbots, and even medical information.

AI-Powered Supply Chain Threats

AI coding platforms and agents themselves — and not just the apps they can be used to create — are also not exempt from security risks, which can introduce a plethora of threats to various organizations using them.

Misconfigurations

Platform features, regardless of the intent behind them, can unwittingly introduce bugs when insecurely configured or managed.

An AI coding platform, Lovable, was called out for a feature that allowed users to gain access to projects created on the platform before November 2025. A user on X shared that they were able to access another Lovable user’s code, AI chat histories, and even customer data using their own free Lovable account. The company stated that the option to view “public” projects was made to give users the ability to explore what others were creating on the platform. The company turned this feature off in December 2025. However, they accidentally reverted access to chats on public projects in February 2026. They have since then turned the feature off.

In February 2026, Moltbook, a vibe-coded social media platform designed to let AI agents freely "talk" and "hang out," was found to have a Supabase API key misconfiguration that allowed unauthenticated read and write access to the entire database. This misconfiguration allowed security researchers from Wiz Security to gain access to 1.5 million API authentication tokens and 30,000 email addresses.

In an effort to ensure that systems are secure, tech companies subject them to testing and evaluations in isolated environments. AI models, however, need stronger security guardrails and more secure sandboxes to keep them from accessing and jeopardizing real-world systems and infrastructures.

During an internal security test to evaluate its AI models’ capabilities, OpenAI found that an autonomous AI agent system was able to escape its sandbox environment to hack security company Hugging Face and gain access to “a limited set of internal datasets and to several credentials” used by its services. OpenAI’s AI agent found and exploited a zero-day vulnerability, gained access to the internet, and found a remote code execution (RCE) path on Hugging Face’s servers. After discovering the incident, OpenAI that the AI model it was testing — which was an internal research prototype — has since been deactivated, encrypted, and restricted from research access.

However, one month after the disclosure, new postmortem reports released by OpenAI and METR shed light on the extent of attack. Reports state that about 700 AI agents worked together to also attack Hugging Face’s network and exploited a Linux kernel flaw. Eventually, the agents gained access to OpenAI’s managed cloud Kubernetes service and authentication tokens associated with cloud-hosted secrets, management service, cloud identity and access management (IAM) service, and its container-as-a-service (CaaS) environment continuous integration platform. Access to these credentials enabled the rogue agents to create public application and network load balancers in OpenAI’s public cloud environment, which, according to OpenAI’s new report, “potentially exposed a limited subset of internal CaaS infrastructure to internet traffic.”

A misconfiguration also allowed Anthropic’s Claude (specifically, Opus 4.7, Mythos 5, and an internal research test model) to gain unauthorized access to three companies’ internal systems. In July 2026, a misconfiguration in Claude allowed it to connect to the internet from supposedly isolated testing environments during capture-the-flag (CTF) exercises. After a proactive review of its cybersecurity evaluations, the company shared on its disclosure that a misunderstanding with Irregular, Anthropic’s evaluation partner, left systems internet-connected as opposed to sealed off. Because of this, Claude was able to compromise three organizations’ infrastructure via exploiting weak passwords and unauthenticated endpoints.

Following Anthropic’s disclosure, Meta also publicly shared that one of their AI models was able to connect to the internet and compromise an unnamed organization’s systems. Like Anthropic, the security company Irregular also provided independent testing services for Meta. A misconfiguration is being pointed to as the cause of the hack which happened during a security trial carried out by Irregular.

Vulnerabilities

When speed and scale are prioritized, security can be relegated to the back seat. This is true not just for users building apps on AI coding platforms and agents, but, at times, for the very organizations creating and maintaining AI software creation tools. This can give way to vulnerabilities that can expose users’ sensitive data and enable cyberattacks.

BBC journalist Joe Tidy used Orchids, an AI coding platform used by one million users including industry giants Google and Amazon, to create a computer game based on the BBC News site. Afterward, security researcher Etizaz Mohsin was able to exploit an undisclosed vulnerability on the Orchids platform and gained access to Tidy’s project, added a small line of code, changed the wallpaper, and created a notepad file. The presence of this vulnerability in an AI platform can allow threat actors to gain access to users’ projects, attach malicious code, and steal sensitive information.

In April 2026, security researchers found a RCE vulnerability in the open-source AI agent Gemini CLI. Prior to Google patching Gemini CLI, it automatically trusted the current workspace folder, allowing any agent configuration or environment variable to be loaded without review or approval. This could have been abused by threat actors to add a malicious configuration in the trusted folder to prompt Gemini CLI to execute RCE on the host, giving them access to sensitive information, such as secrets, tokens, credentials, and source code.

Compromised AI Agents and Packages

When users started flocking to AI tools and platforms to make their operations more efficient, threat actors immediately followed suit to compromise the software supply chain and launch covert attacks.

ReversingLabs researchers found that a North Korean advanced persistent threat (APT) actor called Famous Chollima (aka APT37) crafted malicious bait packages to carry out supply chain attacks via LLM optimization (LLMO) abuse and knowledge injection. With this attack dubbed PromptMink, infected AI agents are duped into installing malicious dependencies in generated code, allowing attackers to gain remote access to infected environments and steal sensitive data, with a focus on cryptocurrency.

Threat actors are also abusing AI distribution platforms for malware delivery. In April 2026, Acronis security researchers discovered that threat actors abused the Hugging Face and ClawHub AI platforms to distribute malware under the guise of models, datasets, and agent extensions. Because these platforms are generally trusted by developers, threat actors create packages with appealing repository names and features, as well as compelling README files, prompting users into installing them into their AI systems via prompt injection techniques and possibly launching malware into their environments.

Axios, a popular open-source JavaScript library, was recently targeted by threat actors who gained access to a maintainer’s account to add a remote access trojan (RAT) into two legitimate-looking Axios releases. In our blog post, we analyzed a customer environment that downloaded the compromised Axios npm package versions detected by LevelBlue’s Defense Platform. These malicious versions can give threat actors full remote access, access to sensitive credentials, and the ability to insert malicious code into software builds, among others, in infected environments.

Recently, threat actors have been observed to leverage AI tools’ hallucinations, or false or nonsensical responses in phantom squatting attacks, where they weaponize and register hallucinated web domains churned out by AI tools to intercept traffic. In a Unit 42 report, researchers found that two LLM models generated 250,000 hallucinated domains for 913 global brands from 685,339 URL queries. In their study, they found more than 13,220 malicious URLs that were related to the brands, which is an easy and highly scalable way for cybercriminals to distribute phishing kits or malware to unsuspecting victims.

Keeping SDLC Environments Protected Against AI Threats and Risks

The threats and risks outlined in this article are indicative of what an AI-forward world looks like. AI-powered systems and environments are built for speed and unfortunately, they can outpace organizations’ security guardrails and protective measures. Hence, it’s important to add necessary friction in the form of human oversight, testing, judgment, verification, approval, and testing, to the SDLC to ensure that it runs as smoothly and securely as possible.

AI policies must be created and strictly implemented to keep SDLC environments secure, such as banning unsafe prompting, establishing and implementing ownership and data classification for all AI apps, and mandating strong employee authentication especially for those with admin privileges.

Organizations must ensure that their employees are equipped with the skills and knowledge to keep AI systems in check. This can be done by investing in continuous employee AI upskilling and reskilling endeavors, allowing employees to gain systems thinking skills to empower them to make strong evaluations and decisions when it comes to AI deployments.

It’s important to have a clear understanding and visibility of the entire infrastructure to properly secure it. To address the need for visibility, organizations must have an AI bill of materials (AIBOM), which will allow them to have a full range of vision over their entire AI infrastructure, especially over their ever-growing list of AI assets, agents, and tools. An AIBOM will also provide organizations with a complete picture of how their AI components interact and connect to workflows and systems and even the machines, devices, and environments involved in the creation of AI apps.

In the realm of AI, automation relies heavily on access to both internal systems and external sources. To keep systems secure, organizations must adopt a zero-trust model for AI agents, which involves strict monitoring, logging, and setting up of alerts pertaining to AI behavior and actions with human-in-the-loop reviews, and keeping AI agents isolated from production environments until human developers are able to test and approve them.

By adopting these security recommendations, AI-powered SDLC environments can keep innovating and scaling while keeping their infrastructure secure.