The Clean Source Principle and the Future of Identity Security

TL;DR Modern identity systems are deeply interconnected, and every weak dependency creates an attack path — no matter how strong any single platform appears. The Clean Source Principle and BloodHound OpenGraph make these hidden relationships visible, empowering defenders to treat Attack Path Management as an ongoing discipline rather than a one-time project.

Introduction

In his 2024 blog post, The Security Principle Every Attacker Needs to Follow, Elad Shamir proposed a deceptively simple rule: all security dependencies must be as trustworthy as the object being secured. However, this simple rule is violated constantly in modern enterprise environments. These violations are what give rise to attack paths.

In today’s security discourse, phrases like “identity is the new perimeter” are often repeated as though they capture the whole story. They suggest that if an organization hardens its identity provider, deploys MFA, and centralizes authentication, it will have contained its risk. The reality is far more complicated.

Identities never exist in isolation. They are embedded in a web of devices, platforms, agents, and other identities. These relationships, often hidden, sprawling, and poorly understood, are what adversaries exploit to move through an environment. A system may appear well-secured on its own, but if it inherits trust from another weaker system, it is vulnerable.

Most organizations do not realize the depth of their interconnections. They may invest heavily in hardening one platform, only to leave open attack paths through another. Without visibility into how dependencies actually link together, security leaders are left managing fragments of risk rather than the whole picture.

The Clean Source Principle provides a unifying way to understand these risks. Violations of the principle are what make modern attack paths possible. By examining how dependencies span across platforms and compound through transitive relationships, we can see why conventional strategies fall short, and why graph-based analysis is essential to bring these hidden risks into view. To illustrate this, let’s begin with a simple but powerful case study: how the security of a GitHub repository can be silently chained to platforms its administrators never intended to trust.

Case Study: GitHub’s Hidden Dependencies

Consider a GitHub Enterprise environment hosting an organization’s most sensitive intellectual property. Imagine a private repository containing unreleased source code or proprietary algorithms. At first glance, it appears to be a simple access control problem: secure the repository by tightly managing who has permissions.

For this example, we’ll use BloodHound’s new OpenGraph capability to visualize the configuration as we discuss it.

The Repository in Isolation
The repository appears to stand alone, protected only by the permissions we assign.

Mapping GitHub Access
Expanding outward reveals the GitHub users and teams who have access. Some accounts may have read permissions, others write, and a few may hold administrative control. The repository is no longer an isolated object; it is part of a web of relationships where each user or team becomes a potential dependency.

Revealing External Identities
Many of those GitHub accounts authenticate through an external identity provider such as Entra ID via SSO. Once those relationships are revealed, the dependency becomes clear: GitHub’s security is directly tied to the security of Entra.

Here, the Clean Source Principle comes into focus: GitHub is only as secure as the identity provider it depends on. If the IdP is compromised, so too are the GitHub accounts federated to it and by extension, the repositories they control.

Escalation: Entra Depends on Active Directory

At this point, we’ve shown that GitHub’s security is chained to Entra’s security through single sign-on. But the chain rarely stops there.

In many enterprises, Entra is not an independent identity system. Entra users are often synchronized from on-premises Active Directory. This means that a compromise of an AD account can cascade upward into Entra, and from there into GitHub.

The picture is now clear:

• GitHub’s security depends on Entra.
• Entra’s security depends on Active Directory.
• Therefore, GitHub’s security also depends on Active Directory.

This is the essence of a transitive security dependency. The administrator of the GitHub repository may never think about Active Directory when assigning access, but in practice the security of their most sensitive repository is only as strong as the related Active Directory domain.

The Probability Problem: Assume Breach

A thoughtful CISO might still push back: surely compromise of the one specific AD user synced to Entra is unlikely. Unfortunately, the data tells a different story.

In SpecterOps’ experience deploying BloodHound Enterprise across hundreds of environments, a striking pattern emerges: in roughly 95% of enterprises, the Domain Users group has an attack path to Tier Zero. In plain terms, virtually every user in the domain has some path, often short and exploitable, to compromise the entire AD forest.

This means that if attackers can compromise any AD user, they can find a path to every AD user. And because Entra identities are frequently synced from AD, compromise of AD translates directly into control of Entra accounts.

Even more concerning, we often find that highly privileged Entra accounts are synced from non-privileged AD accounts. From a Clean Source Principle perspective, this is a glaring violation: a weak, low-value AD account inherits the power to control an administrative identity in Entra. In this scenario, the attacker doesn’t even need to escalate to Tier Zero, compromise of a relatively unprivileged AD user may be enough to seize control of a global administrator in Entra, and from there, access to critical GitHub repositories.

Once inside Entra, the attacker inherits all the relationships we saw earlier. If an Entra user is linked to a GitHub account with write or administrative access to a sensitive repository, the repository is effectively compromised. This is why the Assume Breach paradigm matters: defenders must act as though an arbitrary AD user will be compromised at some point. When that assumption holds, the attack path to the GitHub repository is not a remote edge case, it is a certainty waiting to be exploited.

Addressing Common Objections

“We’re cloud-native. We don’t have AD.”

A small minority of organizations have escaped Active Directory altogether, usually because they were born recently in the cloud era. But even those organizations are not exempt from the Clean Source Principle.

Cloud-native enterprises almost always centralize trust into a single identity provider such as Okta, Entra, or Ping. This creates the same class of dependency problem: GitHub, or any other SaaS platform, is only as secure as the IdP it federates to. From a CIA triad perspective, SSO consolidates availability, integrity, and confidentiality risks into a single point of failure.

Escaping AD does not mean escaping dependencies. It only means that the dependency graph has shifted.

“We’ve implemented Zero Trust.”

Zero Trust is another common defense offered by security leaders. The problem is that the term is overloaded, it can mean anything from “we enforce MFA at login” to “we bought a vendor suite marketed as Zero Trust.” In practice, Zero Trust does not eliminate hybrid attack paths, for four reasons.

• Workstations remain the weakest link. Users still run browsers, click phishing links, and download malicious attachments. Regardless of whether devices are AD-joined, Entra-joined, or MDM-enrolled through systems like Jamf or Intune, they remain gateways to identity providers.
• The user access layer is highly interconnected. At Black Hat, SpecterOps researchers released JamfHound, and we are currently developing an Intune extension for OpenGraph. These efforts demonstrate that even in “Zero Trust” environments, device management systems themselves create new webs of trust relationships.
• Segmentation without visibility is a paper exercise. Customers who worked with Microsoft to implement Tiered Administration later used BloodHound to validate their approach with troubling results.  First, many attack paths were still present despite these efforts simply due to a lack of visibilty. They were working in the blind.  Second, small user permission modifications here and there combined to further erode the tiers that took over a year to put in place.    
• Identities in transit reconnect what segmentation attempts to divide. Cloud services must still be accessed from user devices. Sessions cached on those devices can be stolen to bypass MFA and other controls.

The net result: Zero Trust may constrain certain avenues of compromise, but it does not dissolve the transitive dependencies that generate hybrid attack paths.

“We’re migrating away from AD.”

This is another familiar refrain: AD is a legacy anchor, but in 12–18 months, it will be gone. In our experience, this rarely happens. AD’s gravitational pull is too strong, too many applications and devices are entangled with it.

Even for the few organizations that succeed in reducing their AD footprint, the fundamental problem does not disappear. It simply reconstitutes itself in other platforms. Intune, Jamf, Okta, and Ping all step into the same role that AD once played, becoming new hubs of centralized trust.At the end of the day, users will still have devices. Devices will still be compromised through phishing or client-side attacks. And those devices will still bridge access to identity providers. No matter what technology stack governs them, attack paths are inevitable when dependencies are invisible.

The Broader Lesson: Security Dependencies Are Eternal

The GitHub → Entra → Active Directory example is just one illustration of a larger truth: modern environments are built on layers of dependency, and those dependencies inevitably leak trust. Attack paths are not anomalies, they are symptoms of this structural reality.

It helps to think about these dependencies on two levels:

• Intra-platform dependencies exist inside a single system.
  • In Active Directory, the relationship between Domain Users and Tier Zero assets creates predictable attack paths. 
  • In GitHub, team structures and repository permissions can unintentionally grant excessive control.
• Inter-platform dependencies span across systems. GitHub federating to Entra, Entra syncing from AD, or Jamf enforcing policies on Mac workstations are all examples. These connections multiply the attack surface, because the security of one platform now inherits the weaknesses of another.

And here lies the uncomfortable insight: the combination is more dangerous than either system in isolation. An Active Directory environment riddled with attack paths is dangerous. A GitHub organization with overly broad permissions is dangerous. But when GitHub becomes dependent on AD through Entra, the risk compounds.

The Clean Source Principle tells us that if a dependency is weaker than the object it secures, an attack path exists. Intra-platform and inter-platform dependencies both violate this principle, and adversaries exploit both. What makes inter-platform dependencies especially dangerous is that they are often invisible to the teams who own each platform. A GitHub administrator may never realize their repository’s security hinges on an AD user they’ve never heard of.

The lesson is stark: dependencies are eternal. Active Directory may shrink, Intune or Okta may grow, Jamf may dominate in MacOS environments, but the attack paths will keep re-emerging wherever dependencies are hidden or misaligned. The only way to manage identity risk is to make these dependencies visible, across and within platforms, and to continually validate that the Clean Source Principle is not being violated.

OpenGraph as the Future-Proof Strategy

BloodHound was originally built to map Active Directory. That model exposed a reality defenders had long suspected but could never fully prove: nearly every AD environment is saturated with attack paths. For years, that visibility alone transformed how enterprises understood identity risk.

But the most critical risks are no longer contained within a single platform. They emerge in the spaces between platforms; GitHub federating to Entra, Entra syncing from AD, Jamf enforcing policy on Mac devices, Okta brokering authentication across SaaS. These hybrid paths are what turn isolated weaknesses into enterprise-wide compromise.

This is why we built BloodHound OpenGraph. OpenGraph extends BloodHound beyond AD, allowing defenders to model any platform, capture its internal access control model, and then connect it to the systems around it. Whether you are running Intune, Jamf, Ping, Okta, or GitHub Enterprise, the same principle applies: your security is only as strong as the platforms you depend on, and those dependencies can be visualized, queried, and managed in the graph.

The key differentiator is not just the ability to add new platforms, but the ability to see hybrid attack paths. Hardening AD alone or tightening GitHub permissions alone is insufficient if the platforms are chained together. The combination is more dangerous than either in isolation. OpenGraph allows defenders to surface those chains, understand their full impact, and prioritize breaking the most dangerous paths first.

Most importantly, OpenGraph is a future-proof strategy. The leviathan of today may be Active Directory; tomorrow it may be Intune, Okta, or something yet to emerge. But the problem is eternal: security dependencies accumulate, and attackers will always exploit them. By abstracting the platform and focusing on the relationships between systems, BloodHound ensures defenders will never be left blind to the next identity core.

Conclusion: From Principle to Practice

The Clean Source Principle gives us a simple but powerful lens: security dependencies must be as trustworthy as the objects they secure. When that rule is violated, attack paths emerge. Our exploration of GitHub, Entra, and Active Directory shows how easily these violations occur, and how they compound across platforms.

The lesson is clear: you cannot treat identity risk as a one-time project or as a siloed control. Dependencies are structural. They evolve as your platforms evolve, and they re-emerge wherever trust is concentrated. Hardening alone will never be enough, and you cannot even see these security dependencies without the visibility that BloodHound provides.

This is why Attack Path Management must be treated as a practice. Like vulnerability management or detection engineering, it is not a box to check, it is a discipline that requires visibility, prioritization, and continual validation. Our Attack Path Management maturity model makes this explicit: organizations must progress from simply seeing attack paths, to understanding their dependencies, to actively constraining and removing them as part of routine operations.

BloodHound OpenGraph provides the foundation for this practice. It surfaces both intra- and inter-platform dependencies, reveals hybrid attack paths that no human could model alone, and ensures that as the identity ecosystem shifts, defenders are never blind to the new leviathan.

The time to build this practice is now. Attackers are already exploiting hybrid paths; every dependency you fail to see is one they will. By adopting Attack Path Management as a routine discipline, organizations can finally get ahead of this structural problem, cut off entire classes of attack, and take control of their own identity risk.