The Hidden Connection Nobody Saw Coming In The World Of Cybersecurity

The Supply Chain Meeting Identity

Most cybersecurity teams run two completely separate playbooks for two different types of attacks. On one side you have the software supply chain team. They manage SBOMs, verify checksums, and track vulnerable packages. On the other side you have the identity team. They handle SSO, conditional access policies, and privileged access management. Both teams are good at their jobs. Neither team is looking at what happens when the two attack surfaces collide. I spent three weeks last year chasing a compromise that started as a routine npm package update and ended with an attacker holding domain admin credentials. The package wasn't even the final weapon. It was the entry point. The real damage came because the build pipeline that consumed it ran under a service account that had write access to Active Directory. A low-privileged developer workstation account shouldn't have been able to do that. The permission chain had been accumulating additions over four years without anyone auditing the actual privilege scope. That is the hidden connection. The software supply chain is now the primary delivery mechanism for identity compromise, and most organizations still treat them as unrelated problems.

The Hidden Connection Nobody Saw Coming In The World Of Cybersecurity

The connection works like this. Attackers realized around 2020 that compromising a single developer account or injecting code into a popular open source package was cheaper and more sustainable than targeting large enterprise networks directly. You don't need to brute force a firewall when you can publish a malicious update to a package that three thousand companies automatically pull from. But publishing the package is only step one. The package needs to execute something, and execution requires credentials. That is where the identity layer enters. I ran into this specifically during a routine incident response engagement. A mid-size fintech company reported anomalous network activity from a build server. The server was running their CI/CD pipeline. The initial indicator was a JavaScript file that had been added to a dependency tree. The file itself was benign-looking. It made outbound DNS queries to a domain registered three days earlier. Standard DNS tunneling exfiltration. What made it dangerous was the context. That build server ran everything under a single service principal. The principal had permissions to deploy to production, write to the artifact repository, and authenticate against their cloud identity provider. The service principal also hadn't had its secrets rotated in eleven months. We rotated the credentials first. Then we spent two days mapping every system that principal could reach. It turned out the pipeline account could also query their internal LDAP server. The attacker had been using the DNS tunnel for twelve hours before anyone noticed. In those twelve hours they had enumerated group memberships, found a break in the segregation between the development LDAP tree and the production one, and grabbed credentials for a user who happened to have privileged access. The original supply chain compromise was the spark. The identity configuration was the fuel.

Here is what most teams miss when they look at this kind of incident. They focus on the compromised package or the malicious DNS query. They patch the vulnerability and move on. The actual lesson is that your build system, your package manager, and your identity provider are now part of the same attack chain. A vulnerability in any one of those three gives an attacker access to all three. The traditional perimeter model assumed that build infrastructure was isolated from production identity systems. That assumption died somewhere between 2019 and 2021 and nobody wrote it down anywhere. Let me give you a practical way to think about this. Map every CI/CD pipeline account in your environment. For each one, list the exact permissions it has across three categories: code repositories, artifact and package registries, and production infrastructure. Not what it is supposed to have. What it actually has. You will find accounts with write access to production systems that should only have read access. You will find accounts that can authenticate to your identity provider because someone configured a trust relationship five years ago and never revisited it. You will also find that the same account appears in multiple pipelines because reusing credentials is easier than managing separate ones. This mapping exercise usually takes a team two to three days if they are working from scratch. If you already have some automation for infrastructure-as-code auditing, you can cut it down to roughly six hours. The output is a list of pipeline identities ranked by blast radius. The ones with production write access and long-lived credentials go at the top. Fix those first. Rotate their secrets. Restrict their permissions to the minimum set required for their actual function. If a build account doesn't need to touch Active Directory, remove that access entirely. It will break something. You will fix the break. It is better than dealing with a breach.

There is a second layer to this that is harder to see. Package manifests themselves can carry identity-related payloads. I have seen cases where the malicious behavior was split across multiple package versions. Version one of a library downloaded a second-stage payload. Version two of the same library sent that payload to a command and control server. The two versions were published by the same maintainer account, which made the updates look legitimate. Your vulnerability scanner flagged neither version because the code looked syntactically clean. The threat was in the timing and the network behavior, which is something most SBOM tools cannot detect. The workaround I ended up using was network-level monitoring on the build segment. We placed a lightweight traffic monitor between the CI/CD network and the internet. It wasn't doing deep packet inspection. It was just tracking outbound connections from build containers and flagging any that didn't match known patterns for package registries, container registries, or deployment endpoints. When version two of that library tried to phone home, the monitor flagged it. The anomaly threshold was set at three standard deviations from baseline connection patterns. It caught things that signature-based tools missed because the C2 domain changed every forty-eight hours. There are limitations to this approach that you should know about. Network monitoring on build infrastructure generates a lot of noise. You will get false positives from legitimate tools that check for updates or report telemetry. I recommend starting with a two-week passive capture period before you enable any automated alerts. Let the baseline settle. You need to understand what normal looks like for your specific pipelines before you can reliably detect deviations. Also, this method won't catch attacks that stay entirely within your infrastructure. If an attacker gains access to a build environment and moves laterally to an identity store using internal protocols only, the outbound traffic monitor won't see anything.

For that scenario you need a separate layer of control. Treat every service account that touches your build system as if it has the same sensitivity as a domain admin account. That sounds extreme. It isn't. When an account can both sign software and authenticate to production systems, it is effectively a domain admin in everything but name. Rotate its credentials on a ninety-day maximum cycle. Store the secrets in a proper vault, not in environment variables or plaintext config files. Require multi-party approval for any permission change to that account. These controls add friction to the deployment process. They also make unauthorized access significantly harder to exploit at scale. The broader pattern here is that supply chain security and identity security have been converging whether your organization planned for it or not. Attackers followed the path of least resistance. The path goes through your package dependencies and ends at your privileged identities. Teams that keep those two domains separate in their security architecture are leaving a gap that anyone with basic reconnaissance skills can exploit. The gap isn't in the technology. It is in the organizational model. Building it closed requires the people who manage CI/CD, the people who manage IAM, and the people who monitor network traffic to share the same threat model and review the same incidents. That is the actual hard part. The technical controls are straightforward. The coordination isn't.