TeamPCP, the threat actor behind an unrelenting flurry of attacks on open-source software this year, has been active much longer than previously thought, according to research Oligo Security shared exclusively with CyberScoop.
The threat actor, which gained notoriety and has captivated threat hunters as it compromised and injected malicious code into more than 1,000 software packages in less than four months earlier this year, was also responsible for attacks dating back to 2020, Oligo Security found.
The security vendor’s research team found multiple attacks that bear the markings of TeamPCP, including a late 2025 campaign involving the exploitation of a ShadowRay vulnerability that resulted in the first self-propogating botnet running on hijacked AI infrastructure.
Evidence uncovered during that investigation into the ShadowRay 2.0 campaign was linked to more historical attacks originating from the same IPs, domains and other infrastructure TeamPCP used in attacks that captured widespread attention earlier this year.
“The scariest thing in this campaign is the speed at which the payloads evolved and changed and adapted to the environment they run in. We saw changes in the speed that we’re not used to seeing in these kinds of attacks. They’re usually slow, careful,” said Uri Katz, director of research at Oligo Security. “This was clearly with the help of AI — the payloads changed rapidly to adjust and change to the environment that they were trying to attack.”
One of the domains that Oligo Security identified in July 2025 was in the profile of TeamPCP’s official GitHub account, said Avi Lumelsky, AI security researcher at Oligo Security. “It’s public, they’re not even trying to hide their identity,” he said.
From there, Oligo linked TeamPCP to activity tracked under multiple names, including TA-NATALSTATUS and IronErn, spanning from 2020 to late 2025. Much of that activity was traced to the same IPs, domain names, a file server and command-and-control server, researchers said.
TeamPCP emerged publicly as a brand in late 2025. Soon after, “TeamPCP started to go really broad and do campaigns, which are much more noisy,” said Gal Elbaz, co-founder and CTO at Oligo Security.
Widespread adoption of AI and TeamPCP’s use of the technology supported this growth as the threat actor built a brand, got more active on social media and boasted publicly about its activities and claimed victims.
“The ability to control the infrastructure and orchestrate the attack with AI was also super new, and I’m sure it helps them,” Elbaz said.
“All of the companies in the world are in this race to adopt AI because they are afraid their business will die, and they understand, of course, the opportunity. But it’s also what gives the attacker this power to go into it,” he added. “If you don’t really have visibility in what’s going on there or how it behaves, that’s exactly what attackers are after.”
TeamPCP’s more recent attacks have capitalized on new security gaps created by developers’ increasing reliance on AI and the automated systems companies use to deploy code. The threat actor is also consistently wrecking the open-source frameworks and software packages these systems rely on.
“Most AI infrastructure is open source by design because nobody has the manpower and money to develop everything from scratch,” Lumelsky said.
“We love open source. We use many of these products ourselves, but it’s all about reading the documentation, and I think many of these tools place the responsibility of using it right and security on the user, and developers are not used to these new kinds of animals,” he added. “That’s why the trust can be exploited at scale.”
As it uncovered a long operational history spanning multiple campaigns, Oligo Security has gained more confidence in understanding how TeamPCP operates. It also means TeamPCP was likely involved in other attacks that haven’t been attributed to it yet or attacks that haven’t been detected.
“There’s a lot more out there that we haven’t caught or been able to prove up until now,” Elbaz said.
While AI is supposed to help defenders, it’s now creating more than twice as much noise as human-triggered incidents CrowdStrike detects as potentially malicious. The company’s threat hunting team and systems triaged an average of 14 million detection leads daily, resulting in about 36,000 customer alerts during the one-year period ending in June.
“AI agent-driven behaviors have surged past human triggers,” said Adam Meyers, senior vice president of counter adversary operations at CrowdStrike. “AI has driven the detections significantly above what humans are causing, and this gives you a sense of how frequently AI is being used, and really just that it’s being used everywhere.”
The threat posed by AI showed up incessantly during the past year, sparking alarming shifts and heightened targeting across software defects, open-source supply chains and AI tools themselves — all of which create greater difficulties for defenders, CrowdStrike said in its annual threat hunting report.
“The AI tools that are being implemented by every enterprise across the globe right now are also creating an extended attack surface,” Meyers said during a press briefing.
“AI is now a tool, a target, and a force multiplier for adversaries,” researchers wrote in the report, adding that AI-enabled malicious activity surged 89% during the past year as attackers used the technology to scale operations, hasten tradecraft and target AI infrastructure.
Attackers are using frontier AI models to uncover vulnerabilities and develop resources, including AI-generated scripts, payloads and commands that increase their effectiveness and efficiency. The technology also allows threat groups to design more creative ways to run automated attacks and boost impact by manipulating, interrupting or sabotaging AI systems and data.
“AI is both the weapon and the target,” Meyers said.
Most organizations don’t view it as such, and thus far haven’t secured or put proper guardrails around the AI tools they use or address the ways attackers can use AI against them, he added.
AI’s mark on vulnerabilities is particularly concerning, as reflected by what Meyers described as “one of the scarier stats” in this year’s report: 88% of vulnerabilities were weaponized through AI within 48 hours.
“This is creating a rich ecosystem of vulnerabilities for attackers to use against various systems,” he said. It also renders the 30-day patch window obsolete, forcing organizations to struggle under a new baseline patch cycle of 24 to 48 hours, according to Meyers.
The AI ecosystem also became the next software supply chain battleground during the past year, as evidenced by TeamPCP’s rampage through open-source software in the first half of this year.
The threat cluster compromised more than 300 software dependencies in one day, Meyers said.
AI tools are already in the crosshairs and the attack surface will continue to grow as agentic systems, AI application integrations and dependency managers for AI agents proliferate, the report concluded.
“The same AI tools driving modern businesses are creating under-defended attack surfaces that adversaries are exploiting,” Meyers said. “We have to secure AI. This is absolutely critical.”
The Cybersecurity and Infrastructure Security Agency published a guidebook for federal agencies Thursday to aid them on managing security risks with open-source software, touching on topics like patching and open-source AI models.
“As part of our statutory mission, CISA remains laser-focused on enhancing the nation’s cybersecurity by collaborating with government, industry and the open-source community to understand and securely use OSS,” said Chris Butera, acting executive assistant director for cybersecurity. “CISA encourages federal civilian agencies to review this guide and implement the principles and practices to improve risk management, better execute their mission, and better serve the public.”
The document, “Open Source Software: Security Principles and Practices,” touts the advantages of open-source software — which anyone can use, modify and share — as offering benefits in efficiency, cost, security transparency and more, but notes that it also has unique tradeoffs.
“All software carries risk, and OSS is no more or less risky than other software. The key distinction is that, with OSS, agencies can directly assess code quality and security, rather than relying solely on vendor assurances,” the guidance reads. “OSS is increasingly intertwined with emerging technologies such as artificial intelligence. Agencies that adapt to OSS’s unique characteristics will position themselves to meet future challenges and leverage new innovations.”
The guidance says that agencies need to take steps to evaluate the trustworthiness of an OSS project before approving an OSS component for use, and track OSS in their asset management repositories. It details how agencies should deal with patching, including when there’s a new OSS vulnerability that doesn’t have one. It offers advice on how agencies might contribute to OSS projects, produce them and secure rights for government reuse of code when contracting for custom software development. And it explains how it should approach open-weight AI models.
“Agencies should approach ‘open source’ AI systems differently from other OSS because open source licenses for AI software do not require the level of transparency needed to evaluate the trustworthiness of the software,” the guidance states.
Æva Black, an open-source security expert and former OSS lead at CISA, said she applauded her former agency for the guidance, telling CyberScoop that it “demonstrates a grounded understanding of the global, diverse, and participatory nature of open source software development, and provides essential guidance for federal agencies to safely use open soure during a crucial moment.”
She singled out its recommendations on the risks of deploying unverifiable open-weight AI models on sensitive networks.
“Due to recent advances in AI, particularly in large language models capable of finding and exploiting software vulnerabilities, vulnerability management is facing a global crisis,” she said. “Many proprietary software vendors are using this as an opportunity to spread ‘fear, uncertainty, and doubt’ about open source in order to capture public attention, and, I presume, public money — but when used responsibly and maintained collaboratively, I believe open source software is, and will remain, the safest and most cost-effective means for building large scale public infrastructure.”
CISA has produced a bevy of security guidance and updated advisory materials this week: on the creation of software bills of materials written in conjunction with other agencies and allied governments that won praise from experts; on the isolation of vital operational technology during a crisis, also written with other agencies and allied governments; and the release of updated secure cloud configuration baselines for Google Workspace.
Amazon’s security researchers say a hacking group tied to North Korea targeted small, little-noticed software packages more than a year before it struck one of the internet’s most widely used programming tools.
The company’s threat intelligence team said Wednesday at a media roundtable at its Arlington, Va., offices that the same group linked to the recent compromise of the open-source axios software library also planted malicious code in a package called typo-crypto in March 2025, a full year before the axios breach. Researchers found the connection while tracing domain records tied to the axios attack back to earlier activity.
“We believe the March 2025 typo-crypto campaign was a rehearsal,” said CJ Moses, Amazon’s chief information security officer, adding that the target’s small scale let the group test its methods “without putting that on the big stage.”
Amazon said the group also compromised two other packages, debug and chalk, in September 2025. Until now, those three incidents had not been publicly linked to the same actor. Security researchers track the group under several names, including UNC1069, Sapphire Sleet and Stardust Chollima.
Axios, debug and chalk are code libraries used by software developers around the world to build applications. Axios alone is downloaded more than 100 million times a week. “That number represents real organizations putting real code into production systems every single week,” Moses said.
In the typo-crypto case, the malicious file was named “core.js” and was made to look like a legitimate, unrelated package called core-js. Amazon said the file activated only when it received a specific numeric input, then reached out to a server controlled by the attackers to download a second piece of code. That second stage was written differently depending on whether the infected computer ran Windows, macOS or Linux. The code combined encoded text with a cipher, a method Moses said was meant to slow down analysis, including by AI-based review tools, without relying on heavy encryption.
Amazon said the typo-crypto package had few downloads compared with axios, debug or chalk. Researchers believe that initial target served as practice, letting the group refine its approach before turning to more widely used software. “They did what a lot of people do: crawl, walk, run,” Moses said.
In each of the four cases, Amazon said, the attackers built a relationship with a maintainer who already had access to a package, then used that access to publish an update containing hidden code. “They didn’t break through a window,” Moses said. “They basically earned the trust of an employee to hand them the keys.”
Cybersecurity firm Wiz separately found that about 1 in 10 cloud computing environments were affected by the debug and chalk incident within a two-hour span, a finding Moses cited to illustrate how fast the impact spread. “Going from there not being a vulnerability, to there being a vulnerability, to there being an exploited vulnerability … used to be days to weeks. Now it’s hours to minutes,” he said.
Rick Anthony, senior engineering manager at Amazon Web Services, said the research further shows how attackers face two basic problems in these types of incidents: getting malicious code into a package that will eventually run inside an organization, and keeping that code hidden from developers or security tools. He said groups are increasingly building reputations as legitimate contributors over time.
“Let me get my package deployed in as many places as possible so that I can spring the trap later,” said Anthony, describing the mindset behind the approach.
Researchers said generative AI has made it easier for attackers to produce code, documentation and contribution histories that look authentic. Anthony also described a technique in which attackers register package names that AI coding tools sometimes generate by mistake, so a developer following an AI suggestion could install malicious software without making any typing error of their own.
The findings come two years after a separate incident involving a program called xz-utils, in which an attacker spent time gaining the trust of the software’s maintainers before inserting a backdoor. Moses pointed to that case as an early example of a pattern now appearing “at scale” and tied to a nation-state.
Since that incident, separate groups have been running roughshod over open-source software. Another group known as TeamPCP has compromised and injected malicious code into more than 1,000 software packages over a four-month span this year.
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 AI-focused executive order President Donald Trump signed last month gave the Treasury Department, the National Security Agency, and the Cybersecurity and Infrastructure Security Agency (CISA) 30 days to establish a new “AI cybersecurity clearinghouse.” The deadline passed last week.
The clearinghouse is meant to coordinate the scanning, discovery, and validation of software vulnerabilities in critical infrastructure, and then prioritize how those vulnerabilities get patched and distributed.
It’s the right problem to solve. The question now is whether what is created will actually solve it.
The risk is that urgency produces something that looks like a clearinghouse, but functions like a committee: collecting information, convening meetings, and then stalling when it gets to the hard part.
Going beyond bug discovery is mission critical
It’s counterintuitive at a moment when AI-assisted vulnerability discovery is advancing rapidly, but the hard part is no longer just finding bugs. Those of us working at the intersection of AI and cybersecurity know where the real bottleneck is. HackerOne has seen it firsthand as a launch partner in Patch the Planet, OpenAI‘s initiative to use AI to find and fix vulnerabilities in critical open-source software at internet scale. The lesson underpinning that work, and informed by more than a decade of running vulnerability disclosure programs, is consistent: AI tools can surface vulnerabilities faster than anyone can act on them. What lags behind is everything that comes after discovery: deciding which findings are real, assessing severity in context, writing and testing a fix, and getting a patch accepted and deployed by the people responsible for maintaining the affected code.
Experienced human reviewers frequently disagree with AI-assigned severity ratings, because a model cannot see a project’s threat model or operational context. Software providers, especially the many volunteer open-source maintainers that so much of today’s digital infrastructure rely upon, face a relentless queue: verify the claim, assess the importance, write the patch, coordinate disclosure. AI has accelerated the incoming volume without yet equally accelerating our people and processes’ capacity to manage it. Better bug-finding tools mean you find more bugs. The improvements that really matter are the ones that help defenders push patches out and get them deployed faster.
That lesson should sit at the center of how the clearinghouse is designed.
If the clearinghouse focuses primarily on scanning coordination, which the executive order’s text emphasizes, it risks widening that gap rather than closing it. A body that finds more vulnerabilities but cannot move them to resolution is not a security win. At national scale, it is a backlog generator.
Laying a foundation for success
The administration can get this right, but it requires building the correct infrastructure now, not layering it on later.
The clearinghouse needs to do more than coordinate scanning. It needs to actually triage the results. Its core job should be filtering reports to identify which findings are truly credible, exploitable, and consequential for critical infrastructure. Using shared validation standards and risk-based prioritization, it can determine what warrants a national response. Otherwise, it’s just automating bigger backlogs.
Second, the clearinghouse also needs to tackle something more fundamental. Defenders don’t have the resources to respond to what gets reported. Vulnerabilities in critical infrastructure often live in open-source code maintained by small teams or individuals with no formal obligation to respond to disclosures and limited capacity to act quickly. The clearinghouse should work with the National Institute of Standards and Technology (NIST) to develop guidelines for open-source maintainers on structuring repositories and workflows to speed up patch review and deployment.
These guidelines should include how to use AI-assisted patching and clarify what downstream consumers of open-source code should do to help maintainers address vulnerabilities. Federal policy should create incentives for downstream users to share responsibility for remediation through funding, engineering support, AI-assisted patch development, and procurement requirements that reward participation in coordinated vulnerability response.
Third, the clearinghouse should treat software bills of materials (SBOMs), the structured inventories of the components that make up a software product, as foundational infrastructure. SBOMs are what make it possible to trace where a vulnerable component lives across the supply chain. Without them, validated findings won’t be fixed fast enough at scale.
Finally, the clearinghouse should measure success based on what is fixed, not based on what is discovered. Agencies need to publish data on validation rates, time-to-patch, adoption of fixes, and recurring classes of vulnerabilities. These metrics help AI systems, software vendors, and policymakers to continuously improve how vulnerabilities are addressed.
Most importantly: the agencies standing up this clearinghouse should resist the temptation to build its operational model from scratch. The private sector and the open-source security community have years of experience running exactly the kind of vulnerability intake, triage, and coordinated disclosure workflows the clearinghouse needs. The executive order wisely calls for voluntary collaboration with industry. That collaboration should be structural, not advisory, embedded in how the clearinghouse operates from the start, not bolted on after the architecture is already set.
The clearinghouse can work. But the challenge is no longer finding vulnerabilities. It is building a system that can turn discoveries into action. That is how its success should be measured.
Wade Woolwine is Senior Director, Product Security at Rapid7.
The headlines around Glasswing have focused on how quickly AI can surface vulnerabilities, which has naturally caught the attention of security leaders. In my conversations with teams and customers, the more useful discussion has been about what that speed means in practice for business protection, especially across open source risk, dependency choices, and software supply chain resilience. The deeper issue for security leaders sits elsewhere.
Software risk is becoming harder to manage across the full lifecycle, especially in open source dependencies, build pipelines, developer environments, and the operational processes that sit between disclosure and remediation. When vulnerabilities can be found faster and at greater depth, security teams need more than another source of findings. They need a stronger way to understand what they run, what they trust, what they can patch quickly, and where a single weak dependency can create disproportionate risk.
Faster discovery makes software supply chain resilience a more immediate leadership issue. CISOs need a clearer view of how dependencies are chosen, monitored, validated, and governed across production, build, and developer environments, especially as open source remains essential to modern software development.
Organizations already struggle to absorb vulnerability disclosures at the pace they are coming in, because when discovery gets faster, the operational gap widens between knowing there is a problem and being able to do something useful about it. That gap is especially serious in the software supply chain, where a single dependency can introduce risk into build systems, production workloads, developer endpoints, and the tools used to secure them.
This is why I would frame AI-driven vulnerability discovery risk as a lifecycle challenge. The pressure does not sit in one place, but across inventory, dependency decisions, threat intelligence, patching discipline, and validation – with people, process, and visibility shaping how well an organization can respond. Technology matters, but it cannot compensate for a weak operating model underneath it.
Open source still matters. Dependency choices matter more.
Open source remains essential to modern software development because it helps teams move faster and get products to market without rebuilding common functionality from scratch. The better response is to be more deliberate about where and how third-party code enters the environment.
Open source has always involved a trade-off between speed, efficiency, flexibility, and inherited risk, and that trade-off becomes harder to manage as AI makes code review deeper and faster. More flaws and supply chain compromises will likely be found in packages that teams have trusted for years, including transitive dependencies most developers did not knowingly choose. One only needs to look back a few weeks to find that the widely used Axios package suffered a supply chain compromise that bundled a Remote Access Trojan (RAT) charged with stealing secrets. That raises the value of understanding which dependencies are essential, which ones can be removed, which ones pull in large chains of transitives, and which ones are maintained by too few people to inspire confidence.
That work starts with a more disciplined question than “Is there a package that does this?” It starts with “Do we need this dependency, and do we understand the risk that comes with it?” The safest dependency is often the one that never enters the environment in the first place.
Why inventory has to go deeper than package lists
Supply chain resilience begins with knowing what you are actually running, which sounds straightforward until a critical disclosure lands in a package no one realized was in the environment three layers deep. Dependency graphs are deeper than most teams think, and transitive risk is where a lot of operational pain begins. A package chosen directly by a developer may bring in dozens of additional packages, each with its own maintainers, release cadence, security posture, and potential failure points.
A mature approach to inventory needs to move beyond a static package list, because CISOs need confidence in three views at once: What is declared in source, what is resolved and built, and what is actually running in production? Those views often drift apart over time, which means a package can be patched in source and still remain unpatched in a deployed container or runtime environment. An SBOM on its own will not close that gap; continuous, usable inventory will.
That inventory also needs clear ownership attached to it, because the moment a critical dependency is identified, someone has to decide what happens next, coordinate the change, and absorb the operational consequences. Security teams cannot do that well if responsibility is unclear, which is why ownership needs to be treated as part of resilience rather than an administrative detail.
Build pipelines and developer environments deserve the same scrutiny as production
Supply chain conversations still tend to start with production systems, even though recent incidents have shown how quickly compromise can move through the build layer, developer tooling, or the security tooling inside the pipeline itself. Those environments hold code, secrets, and trust relationships that attackers know how to exploit, while developer workstations often carry a rich mix of credentials and elevated privileges because speed matters to the business. Build systems are predictable and privileged, which makes them both valuable and vulnerable, but also easier to monitor.
Seeing those layers as part of the same attack surface means asking harder questions about how code enters the build, how package updates are governed, how actions and dependencies are pinned, what secrets exist in CI/CD, and what controls are in place on developer endpoints to detect anomalous behavior or stop high-risk package activity before it goes unnoticed.
You can gauge the maturity of the operating model with the answers to a few basic questions:
How tightly are dependencies controlled in CI?
How are package lifecycle scripts governed?
What secrets exist in CI/CD, and what protections surround them?
What visibility exists into anomalous behavior on developer endpoints?
How would the team detect or prevent high-risk package activity before it spreads?
If those answers are unclear, important parts of the model are still missing.
Why prioritization matters more as scanning accelerates
When software risk rises, the instinct is often to add another scanner because more visibility feels like progress. What matters more over time, though, is how well teams can prioritize the findings that follow, assign them to the right owner, choose the right mitigation, and prove that exposure actually went down. Broader scanning and faster discovery mostly add to the pile unless the operating model behind them is strong enough to turn findings into action. Feed more issues into a process that is already stretched and the backlog grows, priorities become harder to sort, and remediation slows in the places where speed matters most. The organizations that come through this period well will be the ones that treat supply chain resilience as a systems problem, with stronger intake, clearer governance, better intelligence, and faster paths from alert to action.
What stronger software supply chain resilience looks like in practice
A stronger response starts with a deeper inventory of dependencies across source, build, and runtime, so teams can see both direct and transitive packages and connect them back to real environments and real owners. Once that picture is in place, intelligence monitoring becomes far more useful when it runs continuously against credible signals on vulnerabilities, package risk, maintainer health, end-of-life software, and unusual changes in dependency behavior.
The same level of care needs to carry through into dependency governance, where better decisions depend on asking whether a new package is necessary, how much transitive risk it introduces, whether its maintenance model is healthy, and what policy governs its path into production. Build and developer controls belong in that same conversation, because version pinning, private registries, secret handling, script restrictions, immutable builds, ephemeral runners, and stronger endpoint monitoring all reduce the attack surface around the software supply chain.
Monitoring threat intelligence for notifications about new vulnerabilities and compromised packages and having a well defined and practiced process for scoping and remediating emerging threats becomes critical. Your supply chain vulnerability and compromise response should be practiced – just like your incident response plan – through table top exercises and simulated threat events. You don’t want to wait until the house is on fire to know how to execute an effective response.
Similarly, Engineering, DevOps, and Security teams should collaborate on establishing a trust and reputation scoring mechanism for supply chain dependencies. Being able to evaluate the speed of response, transparency of communication and updates, and ultimate resolution of the vulnerability or compromise speak volumes for how much you can trust the maintainers of the software you depend on. The OpenSSF Scorecard project offers a great place to start evaluating the open source packages you’re already using.
Organizations should also have a fallback plan for when obtaining a security patch is not available. Some options to consider include exploring other open source packages that perform similar functions, exploring other mitigations such as application firewalling, or even forking and contributing a security patch back to the community.
Validation closes the loop by showing whether the artifact came from where it was supposed to, whether the package has drifted in unexpected ways, and whether the mitigations applied are reducing live risk rather than simply documenting the process.
How CISOs should think about the next 12 months
The strain on security teams is only growing, and the potential for AI to relieve some of that pressure is understandably compelling, especially when boards, CEOs, and CFOs are asking how the organization plans to adopt it. That makes this a leadership question as much as a technology one. CISOs need a clear point of view on where AI can genuinely improve resilience, where it still introduces too much uncertainty, and how to explain those choices in business terms.
If software engineering teams are already adopting AI-assisted development, security teams should be part of that conversation early, especially around dependency management. I have seen teams begin connecting AI coding agents to vulnerability management workflows so those agents can interpret vulnerabilities found in the code base, assess reachability with more context, help plan remediation, and validate updates much faster than traditional handoffs usually allow. Used well, that can reduce drag across the workflow and help teams move faster on classes of issues that are currently slowing them down.
Getting there safely still depends on the foundation underneath it. A more resilient path starts with a clearer picture of the environment and a more complete inventory of dependencies across source, build, and runtime. From there, ownership needs to be explicit, threat and vulnerability intelligence needs to be embedded into how the organization prioritizes, and dependency sprawl needs to be reduced with more discipline around what actually enters production. The same mindset should carry through to the build layer and developer endpoints, where tighter controls and better visibility help reduce unnecessary exposure, while faster and more repeatable paths from disclosure to action make it easier for teams to respond before risk compounds.
That foundation will matter regardless of which AI model or platform becomes dominant six or twelve months from now. It will also matter if the next wave of AI makes backlog reduction, lower-tier remediation, or patch validation more practical. Organizations that know what they run and how they operate will be in a much better position to adopt those capabilities with intent.
The shift security leaders should make now
Security in an AI-accelerated world needs to be managed as a systems challenge, with supply chain resilience shaped by how well organizations connect software composition, exposure visibility, dependency governance, threat intelligence, build integrity, endpoint controls, remediation workflows, and validation. When those layers are treated separately, gaps open quickly; when they are tied together through a stronger operating model, teams are in a much better position to absorb faster discovery without losing control of the response.
For CISOs, that means continuing to use open source with a more deliberate view of dependency risk, reducing unnecessary packages where possible, knowing what is running and who owns it, and monitoring threat and vulnerability intelligence with enough discipline to act before the queue overwhelms the team. It also means paying closer attention to the attack surface across production, build, and developer environments, while treating AI as something that will amplify both the strengths and the weaknesses already present in the program. Faster discovery is here, and the organizations that handle it best will be the ones that can respond with the same level of discipline.
Login
