Mitigating third-party cyber risk by managing service accounts, tokens, shared secrets, and agents

In 2025 and 2026, several software supply chain incidents have compromised packages and repositories on several major platforms, including GitHub, npm, and the Python Package Index (PyPI). These campaigns begin with modifications in major software packages, which are then distributed to the software that requires them.

In many instances, especially when attackers deployed code based on worms like "Shai-Hulud" or "Mini Shai-Hulud," the malicious code infiltrated other packages through a self-spreading mechanism. By the time the attacks were contained, hundreds of packages were infected in each incident.

While the malicious payload can vary, the hackers usually target what are commonly called "secrets." These secrets are authentication tokens present on the user's machine, granting access to repositories and other assets or systems.

As developers are the primary victims of these campaigns, the attackers can use stolen secrets in two main ways. One, they can modify repositories and start new campaigns. And two, they can scan private codebases to obtain even more secrets, including details of service accounts and API tokens.

These tokens used by applications open the doors to corporate systems or cloud storage buckets, allowing the hackers to perform ransomware attacks. Even in the absence of write access, which prevents the encryption of the files for the traditional ransomware routine, read access is enough to extort the victim by threatening the business with a data leak.

Unfortunately, this is not the only way that such secrets can be exposed. Loose ends or just plain sloppiness can lead to API tokens or keys being present in public repositories or other similar places. A report detailing this exact phenomenon was published just a few weeks ago, researchers having found about 9,000 valid AWS keys found exposed in public repositories, with 526 of them giving root access to the respective environment.

Other parties might be unexpectedly involved in similar leaks, too. In 2023, Okta suffered a breach in their support case management systems, and the attacker was able to download logs containing session tokens. Even if these tokens are tied to user identities, they can work just like API tokens, as they are expected to be used by applications.

Unlike user credentials that use a login, a password, and a unique code or other secondary factor when Multi-Factor Authentication (MFA) is enabled, tokens and keys are meant for direct access, bypassing a multi-step authentication process.

Applications never forget their credentials, so rotating these codes and making them impossible to guess is easier than with passwords. But unlike leaked passwords, which will not work without MFA, unencrypted keys or tokens do not have built-in protection against leaks. That is what makes them so valuable for attackers. They can also be numerous and difficult to manage, so they don't get rotated or restricted as they should. They are also willingly shared by both parties for them to able to authenticate each other.

Despite these challenges, shared secrets are often at the backbone of our IT infrastructure, linking business applications to each other across the globe.

If you already understand how this came to be, you can skip to the last section where we share ideas to tackle this challenge. If you are unfamiliar with machine identities and related concepts, the next section explains how the way that we build and connect IT systems has been redefined in the last two decades, in no small part due to the cloud and Software-as-a-Service (SaaS) offerings.

The shift from the perimeter to the identity

In a sense, industry standards now expect IT infrastructure to be more restrictive than ever. Cybersecurity best practices recommend Zero Trust architectures, in which there is no "safe" network or implied trust, as was common in the past (and can still be found in many places). By default, a private system does not care about the origin of a connection, and no one has access. Every request must be authenticated.

Earlier security postures developed over time to improve flexibility without imposing complex security and infrastructure requirements. Systems could be hosted in the cloud or easily share data, regardless of their location, and APIs took care of standardizing data formats. Corporate systems could safely move out of the traditional perimeter after being updated to operate in this fashion.

While user identities work well for humans interacting with software, they are not very practical when it comes to computers to talking to each other, though. That is where service accounts, API keys, certificates, and other forms of authentication tokens for applications come in. These tokens began to silently and efficiently allow systems to access relevant resources. They exist to redefine what it means to be "trusted" for applications and systems. In turn, they also redefined what it meant to be connected.

Being "connected" today is having access to a service account or other credential that can authorize requests to a system or application. The range and reach of connectivity are determined by the privileges of this credential and the number of the third-party systems it grants access to.

With the rise of AI agents, the idea of "machine identities" gained attention as well. This concept is interesting because it emphasizes the true nature of these different authentication mechanisms: as credentials, they can be understood as identities for access control and behavior tracking.

These identities are what we should see as a "connection" today. Associating connectivity with VPN gateways, MPLS links, or dedicated cables running across the city no longer really helps us understand how interconnected our modern infrastructure is.

This high-level connectivity is robust, but we must keep the repercussions in mind, especially when systems are in cloud environments or in Software-as-a-Service (SaaS) platforms. IT infrastructure is about accessing the right data, wherever it is.

The data that is at risk of being exposed is the sum of everything that is accessible with the privileges of any account, including secrets and service accounts. Where the data is stored matters much less when authentication takes the place of the network as the main barrier.

Managing service accounts and API keys

As a rule, businesses and third parties should make an effort to employ the safest integration option available for their applications. Tenchi Security CTO Alexandre Sieira talked about the benefits of cross-account access all the way back in 2020, and those benefits are still there today.

Shared secrets are easier to configure but harder to manage. During incident response scenarios, service providers are generally forced to request that their clients rotate the secrets being used. If they choose to invalidate the key on their end, this will lead to downtime. It is also not uncommon for secrets to not be rotated properly, either because they are forgotten or because the old token or key is not invalidated after the change.

If shared secrets or keys are the only option, automatic rotations and storing secrets securely in the proper infrastructure (such as Amazon's Key Management Service or Google's Secret Manager) are a must.

Detection of service accounts

The first issue in managing service accounts is to be able to recognize them. In an ideal world, every account that was not meant to be used by a person would be appropriately flagged and treated accordingly.

While we unfortunately do not live in such a world, there are some tells that we can use to infer that a given account is a service account. For example, if every user must enable MFA, then accounts with MFA disabled are either noncompliant or are being used by applications.

Given appropriate permissions, cloud providers offer signals to help collect information like this. That is how Zanshin can safely and privately scan the user directories and identity management services to flag accounts that do not have MFA. Users with very old passwords or users who have both passwords and access keys are also potentially service accounts in disguise. Zanshin can flag these cases, allowing a business and its third parties to ensure that these accounts are properly configured and mapped.

Zanshin also detects unused accounts or access keys, indicating inactive users that should be disabled. This can happen when applications have been updated to use different keys or users are no longer working with the company.

Access control

One advantage of using service accounts or identities is that their permissions can be specific and restricted to the tasks the application is expected to perform.

Sometimes, applications are using a service account, as they should, but the account wasn't configured for that application. In these cases, a default service account with too many permissions is often used instead. Zanshin can flag this behavior in some environments (such as Google Cloud), as well as detect when accounts have wildcard permissions and other unsafe settings.

For tokens and keys, it can detect issues such as the lack of automated rotations or keys that do not follow minimum privilege policies. This, too, is done through the APIs made available for each platform.

As Zanshin performs these checks daily, it ensures ongoing compliance with security policy, unlike point-in-time assessments such as questionnaires or one-off audits. We talked about the benefits of inside-out monitoring at length in a previous article.

Securing repositories to protect secrets

While keys and tokens should not be present inside software source code, there are many reasons why this happens. While businesses can request that third parties keep tokens and keys out of the code, sharing source code to ensure that this policy is being followed brings its own set of risks.

For instance, a third party might feel uneasy with the idea that an incident in any of its clients will lead to their own source code being compromised because it had shared it with everyone. This can be a risk to both parties, as first parties should not want their third parties exposed to risks from their other clients, either.

This does not mean that nothing can be done to at least protect these secrets and the source code itself from leaking. Development platforms like GitHub, GitLab, and Bitbucket expose settings about the repository without exposing any source code, allowing a business to ensure that its third parties are doing what they can to protect their code.

Permissions to fork private repositories, insecure webhooks, and even the existence of public repositories when they shouldn't be there are all great signals that show how much a third party is being diligent about the security of their code. Zanshin has visibility over these and much more.

As with service accounts and tokens, it's also important to check the security of users who have access to the repository, which Zanshin is also able to do.

While this cannot prevent every incident, Zanshin has several other rules for defense-in-depth strategies, such as making sure that logging is enabled to detect and investigate incidents. While you can employ these ideas and collect signals in any way or request your third parties to do it for you, Zanshin offers automation, robust signal collection, reports, and guidance for both you and your third parties. You can request a demo to see it in action.

‍