Supply chain attacks are often discussed after they have been identified: a malicious package, a vulnerable software update, a malicious extension, or a breach involving a trusted vendor. But before the incident reaches that stage, the early warning signs may not seem so obvious.
In underground arenas and markets, supply chain compliance does not always appear under a clear label. The post may not say “supply chain attack” at all. It may advertise access to GitHub, private repositories, source code, API keys, OAuth tokens, cloud credentials, CI/CD data, or vendor-related leaks.
Supply chain risk arises from where that access resides and what relationships of trust it affects.
A recent investigation by Flare’s undercover researchers shows that although it is very difficult to detect, there are often early warning signs in the underground of software supply-chain attacks even before they are published publicly as incident reports.
What is a Software Supply-Chain Attack
Software-supply chain attacks target trusted tools, vendors, software components, services, or processes that an organization relies on, rather than attacking the organization directly. In software, this may include compromising a third-party provider, developer account, source code repository, package registry, CI/CD pipeline, update mechanism, plugin, or SaaS integration.
The risk is that if attackers compromise something trusted within the delivery chain, they can gain access to downstream customers, users, or internal systems through legitimate-looking access, updates, code, or integration.
Where common access is associated with the supply chain
One of the strongest examples seen by Flare researchers involved a post (see screenshot below) that advertised access related to GitHub, including references to developer accounts, private repositories, access items, and source code exposure.
On its own, this may look like a typical access auction. But access to GitHub can be more than just access to code. It may expose secrets, deployment scripts, package publishing logic, cloud information, internal documentation, and CI/CD workflows.
This is where the supply chain angle comes into play.
If attackers gain access to a developer’s identity or secret repository, they can understand how software is built, which dependencies are used, where secrets are stored, and how updates are published. In some cases, that access can allow attacks on customers, downstream users, or other connected systems.
The Vercel incident in April 2026 is another useful example because it showed that a compromise involving a trusted third-party AI tool and SaaS access linked to OAuth can create broader security concerns (even if the affected company claims that sensitive customer data and source code were not accessed).
For analysts reviewing underground posts, compliance is not the event itself, which was already public, but the type of exposure it represents: trusted integrations, SaaS accounts, internal tools, environmental variables, and developer platforms linked by permissions that could be abused if one link in the chain is compromised.
That’s why underground posts talking about OAuth access, SaaS tools, environment variables, or developer forums are worth paying attention to, even if the original claim is limited or unverified.
From selling GitHub access to leaked vendor repositories, the warning signs are there – they’re just buried in forums and marketplaces that most teams don’t look at.
Flares are seen before they become incidents.
Start Monitoring Supply Chain Exposures for Free
Source code is not just intellectual property
Flare researchers also reviewed gaps involving alleged vendor data and source code exposures, including claims surrounding Sportradar AG that were later echoed in a public report on TeamPCP’s extensive procurement campaign.
The Sportradar case was linked to a vulnerable Trivy scanner and included the exposure of sensitive equipment such as database passwords, API key and private pairs, Kafka credentials, and monitoring tokens.
That is what makes the case relevant to the current breach: this type of data can reveal how the vendor’s systems are connected, which services and integrations are trusted, and which guarantees can create risks for partners or customers.
In a supply chain investigation, that information is important because the most dangerous part of a leak is not always the compromised database, but the access methods and trusted relationships that reveal it.
Sign up for a free trial to gain access if you are not yet a customer.
A similar point appears in the public report about TeamPCP and Mistral AI. In May 2026, reports stated that TeamPCP was selling hundreds of sites allegedly held by Mistral AI. Mistral disputed parts of the claim, but the case still shows why source code theft should not be viewed solely as an intellectual property problem.
Repositories may include information, architecture logic, internal service names, deployment workflows, API documentation, or references to clients and integrations.
Even if the leaked source code does not provide immediate production access, it can help attackers map the environment and identify future attack methods.
Package attacks show how access can be scaled
A similar analytical lens applies to the integration of ecosystem phenomena. Public reporting on Shai-Hulud (a self-propagating npm supply-chain attack that stole developer secrets and infected trusted packages) showed how compromised npm maintainer accounts and malicious package updates can be used to steal information, harvest CI/CD secrets, and distribute to all repositories.
What mattered was not just the malicious code itself, but the way in which trusted methods of publishing the package were abused.
Discussions about Shai-Hulud style work and competitive supply chain attacks were also observed. These posts weren’t as tangible as they lead to victims, but they’re useful as context for the threat. They show that actors observe social strategies of compromise and discuss how they can be reused, modified, or expanded.
Sign up for a free trial to gain access if you are not yet a customer.
The LiteLLM supply-chain incident provides another recent example. Public reporting defined by the non-authoritative PyPI package publishes links to a broader compliance approach involving developer and CI/CD environments. Because LiteLLM is being used as an AI gateway, this incident also shows how supply chain risk increases in AI infrastructure and developer tools.
Developer areas themselves are also becoming attractive targets. Recent reporting on malicious VS Code extensions has shown that trusted development tools can be a route to repositories and credentials. Extensions, plugins, and AI coding tools often sit alongside source code, terminals, tokens, and internal workflows, making them valuable even if they’re not part of the production infrastructure.
What can defenders take from this
The updated post does not prove that all downstream access sales are a threat to the supply chain. They show why security teams should ask better questions when they see posts that involve source code, developer accounts, SaaS access, API keys, OAuth tokens, package ecosystems, or CI/CD assets.
The important question is not just, “Was the data leaked?” And that, “Would this access affect the way reliable software is built, used, updated, or compiled?”
For defenders, this means that supply chain monitoring must include more than vulnerability disclosures and package warnings. Organizations should watch for exposed developer credentials, GitHub and GitLab access, package registration tokens, leaked repositories, CI/CD secrets, cloud keys, OAuth grants, and claims involving key vendors or software providers.
The value of underground monitoring is in spotting these early signs before they become a full-blown chain reaction.
Learn more by signing up for our free trial.
Powered and written by Flare.
