The difference matters because the search is not limited to an application's code. It includes development tool settings, systems used to automatically build and publish software, remote infrastructure, and artificial intelligence tool settings.
How a stolen asset leads to the next attack
An access key located on a developer's computer can grant access to a company's code. The same code can contain other keys for its infrastructure. A GitHub key can allow changes to additional projects, while a publishing key can allow someone to upload malware to a channel trusted by other developers.
So an initial incident on one computer can turn into an attack on the software development chain. Shai-Hulud doesn't need to compromise each system individually. It looks for the credentials that already exist and uses them to move on to the next point.
This information can be found in configuration files, command history, temporary tool files, automated deployment system settings, or program settings used by developers. Attackers don't need to know in advance which key is most useful. They can collect what they find and later examine where each one leads.
Why publishing keys need priority
A key that allows for the publishing of packages can turn the theft of an access token into the distribution of malware. If someone uses a trusted package to upload modified content, it can automatically reach developers, companies, and systems that download it.
That’s why companies should limit permanent publishing keys. Where possible, access should only be granted for a short period of time, and the identity of the user or service should be verified each time. Recent changes to Docker and GitHub Actions move in this direction, with stronger authentication and greater use of secure publishing.
Keys that cannot yet be replaced should be recorded, audited, held accountable, and changed when suspected of being compromised.
Not all exposed keys have the same weight
A company may find tens of thousands of exposed assets, but that doesn’t mean that all of them pose an immediate and serious risk. Some have already been disabled, while others only lead to test environments. Those that provide access to critical production systems, customer databases, development tools, management tools, or publishing mechanisms need to be treated differently.
Companies and security teams should first consider whether an asset is still active, what environment it leads to, what identity it represents, what it can do, what data or services it can affect, and who is responsible for invalidating or changing it.
A particular problem is shared keys that are used in more than one environment. A key found on a test system may also work in live services. Similarly, a key created for an automated process may be left on a developer's computer, with permissions that are no longer needed.
The extent of the problem
GitGuardian reports that 28,65 million new keys and other access credentials were added to public code changes on GitHub in 2025. That number was up 34% from the previous year. With such a volume, manually reviewing all the findings is unrealistic.
The recommended approach is to prioritize publishing keys and those that provide access to critical production systems first. Companies can then consider the rest based on whether they are active, where they lead, and what permissions they provide.
Detection, remediation, and prevention must be an ongoing process. Companies need complete visibility into where credentials reside, not just in central repositories but also on developers’ computers and automated development tools.
The goal is not to find a new Shai-Hulud search point every time. It is to have fewer active and reusable keys for such a program to steal.
Your comments will not be published if: