Sponsored: Understanding CI/CD attack paths

Summary

Risky Bulletin - Sponsored: Understanding CI/CD Attack Paths (June 12, 2026)
Host: James Wilson (A), Risky Business Media
Guest: Jarrod Atkinson (B), CTO of SpecterOps

---

Episode Overview

This episode dives deep into the attack paths that threaten CI/CD (Continuous Integration/Continuous Deployment) environments, with a particular focus on GitHub’s central role in recent software supply chain incidents. Host James Wilson and SpecterOps CTO Jarrod Atkinson analyze how attackers pivot through GitHub to compromise organizations—not just by grabbing code, but by snatching credentials, escalating privileges, and leveraging automation pipelines. The discussion centers on the practicalities of attack path enumeration, common misconfigurations, and actionable advice for defenders.

---

Key Discussion Points & Insights

1. GitHub as a Critical Attack Pivot (00:00–02:00)

• GitHub is more than a code repository: It drives CI/CD pipelines and stores critical credentials.
• Attackers can use GitHub as a central launching point for broader network compromise.
• Main misconception: Private repos = safety. In reality, private or on-prem repos also have numerous access paths.
• Quote:

  “GitHub is this incredible pivot point for lateral movement… in an attacker's favor if you haven't taken the time to really work through what's possible.”
  (A, 00:57)

2. Initial Access: Beyond Public Exposure (02:00–03:30)

• Attackers exploit both public and internal exposures, often starting from compromised user credentials (e.g., via Active Directory).
• Default repository permissions can unintentionally grant broad access.
• Quote:

  “There's a setting in GitHub... called default repository permission, which allows you to accidentally set every single user... to have admin on every single repository.”
  (B, 02:41)

3. Anatomy of a GitHub Attack (03:19–06:12)

• Attack framework: Initial access → privilege escalation → lateral movement.
• Credential exposure (especially personal access tokens—PATs) is a classic vector.
• GitHub Actions & Pull Request Exploits:
  • Workflows can run untrusted code (e.g., via pull_request_target triggers) in your repo’s context—potentially exposing secrets or altering code/releases.
  • Real-world example: The Tanstack attack, where attackers poisoned caches or overwrote releases.
• Quote:

  “It's almost like someone you don't know at all shows up... and you sit them down at a corporate laptop with full credentials... It's this gnarly crossing of the trust boundaries...”
  (A, 05:06)

4. Privilege Escalation & Lateral Movement (06:12–08:18)

• GitHub Actions often have more permissions than needed (e.g., default write access), which attackers can exploit.
• Attackers can move from basic read access to write access—modifying artifacts used by others.
• Blast radius escalates with open-source code and shared dependencies.
• Quote:

  “You could leverage, essentially, read access and convert it into write access... then you could do like Tanstack, overwrite all of the releases.”
  (B, 06:18)

5. Credentials & Secrets in Pipelines (07:04–09:05)

• Repos often hold credentials for cloud platforms (AWS, GCP, Azure, etc.).
• Misunderstandings of branch protection or OIDC integration can leave pathways open.
• Defenders need to know which repos can assume roles in other platforms and enforce proper permissions.

6. Anecdote: Real-World Attack Path Enumeration (09:05–11:06)

• Red team case: Attackers started with a low-privilege GitHub token, found secrets (via secret scanning alerts), hopped into Jira, found Jenkins credentials, then located a powerful GitHub PAT, achieving administrative access.
• Interconnectedness: Many organizations’ directory, SSO, and source code systems are managed by silos that don’t communicate, creating hidden dependencies and attack paths.
• Notable quote:

  “The people that are in charge of AD and the people that are in charge of GitHub... they don't work together... The GitHub admins don't even know that they're dependent upon Active Directory upstream.”
  (B, 10:38)

7. Defender Recommendations: Mapping & Mitigation (11:06–14:19)

• Visibility is key: Enumerate permissions, secrets, OIDC flows, and branch protections.
• Tools like Bloodhound (and its Community Edition) can help map attack paths in GitHub, Azure, Okta, and AD.
• Community Edition gives visibility; Enterprise adds analytics and prioritized remediation guidance.
• Quote:

  “It's all about first seeing the problem and then you can start to chunk away at reducing the exposure of these repositories...”
  (B, 12:33)

8. Practical Takeaways for CISOs & Security Pros (14:19–15:30)

• GitHub environments are now high-value, high-risk targets.
• Many organizations are unaware of misconfigurations or exposures until compromise occurs.
• Action items:
  • Start with enumeration—even with free tools—to get initial insights.
  • If numerous issues appear, seek deeper analytics and remediation support.
• Quote:

  “There’s myriad ways in which it can go wrong. And I think often with GitHub you don't know you've done it wrong until you compromise.”
  (A, 14:23)

9. Bloodhound-Specific Insight: PWN Requestable Repos (15:01–15:30)

• Bloodhound flags repos that are “PWN requestable”—i.e., susceptible to pull request-based attacks.
• Quote:

  “You could like literally say show me all the repositories where the is PWN requestable property is true and then that would point that out to you and hopefully the answer is zero, but if it's... more, then you can go figure it out.”
  (B, 15:01)

---

Notable Quotes

• “GitHub is this incredible pivot point for lateral movement...”
  (A, 00:57)

• “There's a setting in GitHub... called default repository permission, which allows you to accidentally set every single user... to have admin on every single repository.”
  (B, 02:41)

• “It's almost like someone you don't know at all shows up... It’s this gnarly crossing of the trust boundaries...”
  (A, 05:06)

• “You could leverage, essentially, read access and convert it into write access and then you could do like Tanstack, overwrite all of the releases.”
  (B, 06:18)

• “The people that are in charge of AD and the people that are in charge of GitHub... The GitHub admins don't even know that they're dependent upon Active Directory upstream.”
  (B, 10:38)

• “It's all about first seeing the problem and then you can start to chunk away at reducing the exposure of these repositories...”
  (B, 12:33)

• “There’s myriad ways in which it can go wrong... you don't know you've done it wrong until you compromise.”
  (A, 14:23)

---

Timestamps for Key Segments

• [00:00–02:00] GitHub as a supply chain risk and attack pivot
• [02:00–03:30] Private vs. public exposure; permissions pitfalls
• [03:30–06:12] Anatomy of GitHub attacks (initial access/escalation/lateral movement)
• [06:12–08:18] Privilege escalation via GitHub Actions and workflow abuse
• [08:18–09:05] Lateral movement through secrets and pipelines
• [09:05–11:06] Real-world red team example: Chaining compromises across SaaS
• [11:06–14:19] Defender advice: Enumeration, mapping, and Bloodhound capabilities
• [14:19–15:30] Takeaways for CISOs and specific mitigation for PWN requestable repos

---

Conclusion

This episode highlights the complexity and urgency of securing GitHub and CI/CD pipelines in the modern enterprise attack surface. Enumerating and understanding attack paths—using tools like Bloodhound—are vital first steps, especially in environments where responsibilities are split and interconnected chains of compromise are not always visible. The practical advice and real-world examples make this discussion essential listening for those responsible for application and supply chain security.

Action for listeners:
Start mapping your GitHub attack paths today—before an adversary does it for you.

Transcript

[A]

Foreign hey everyone, I'm James Wilson from Risky Business and welcome to this sponsored interview where I'm joined by Jarrod Atkinson, the CTO of Spectrops. Spectrops, of course, make Bloodhound, the really awesome attack path enumeration tool. And this discussion with Jared is actually focusing in on GitHub and the central role that has played recently in a lot of the supply chain attacks we've seen unfold. And we approach this from the perspective of applying that attack path enumeration lens to GitHub as a critical part of understanding and being able to secure not just GitHub as the place where code is stored, but GitHub as either the thing that is driving your automated CI CD build test, deploy pipelines, but sometimes that's actually where the pipeline itself is. And I found this conversation very interesting because I hadn't fully considered just the all the many and varied ways in which an attacker can get access into your GitHub repo, but then also the many different forms of credentials that they can then find there and move onwards from. It's like GitHub is this incredible pivot point for lateral movement that just opens up a huge amount of flexibility that is frankly in an attacker's favor if you haven't taken the time to really work through what's possible and what mitigations can you do. So I'll drop you here into this chat where Jared starts to talk about how kind of exactly to that point that there's too much or it's too easy to focus on just this idea of, well, if my GitHub repos aren't exposed publicly, if they're kept private, then I've got nothing to worry about. But that's just not the case. There's so many ways they can get into a private repo, into an on prem repo this that it really made me sit back and think, wow, this is an extensive problem. Really hope you enjoy this conversation.

[B]

What I read is people are often thinking about it from how are things exposed on the Internet? And they're maybe underestimating the exposure within an enterprise. So like traditionally we've had this assumed breach mentality, right? Which is eventually your users are going to be compromised and so you should at least act as if they are. And then what, what are the downstream consequences of that? And so the idea is, is that if I compromise your active directory computer or your active directory identity, that's where you're generally speaking logging into your GitHub account from. And so I can leverage that to gain access. And so of course that like, external side, where like, you know, a repo is accessible from the Internet, or maybe somebody's personal access token has been exposed in some data dump or something like that, that's, that's really bad and we need to be worried about that. But, but we shouldn't stop there. We should continue to look at how are we managing permissions to different repositories. What is the default resting permission? There's a setting in GitHub, for instance, called the default repository permission, which allows you to accidentally set every single user in your GitHub organization to have admin on every single repository.

[A]

That's not a good thing to be justified.

[B]

It's not the default, by the way, but it is possible. And so if you have that, then basically any access into your active directory environment can lead to access to all of your repositories. And obviously that would, would not be a great thing.

[A]

Let's get down into the detail. Like what does it actually, what's the, what's an anatomy of GitHub attack? I mean, we see these acronyms like OIDC tokens and pats and things like Talk, talk me through this.

[B]

Yeah, maybe we could, we could use kind of the tried and true taxonomy of like initial access privilege escalation and then lateral movement. Maybe it's kind of like a framework. So imagine that initial access, a lot of times there's credentials that are being just exposed accidentally. So you have a public repository and you accidentally put a personal access token in there for, for whatever reason, that would be one way somebody would get initial access. The PWN request is a little bit more surreptitious, especially if you don't, if you're not familiar with the details of it. One of the, one of the big problems is that one of the points of GitHub is to make code publicly available, right? So open source, the idea is you're making your code publicly available and often you will have like a GitHub action workflow, so some sort of CICD pipeline workflow that you're implementing. And there's several different ways that you can kick off these workflows. One of them is upon pull request, but there's a second kind of like version of the pull request trigger, they call it called pull request target. And what that means is that when you make a pull request, the GitHub action workflow will not run in like your forked version of the code. So let's say you have, you have a code repository. I'M trying to contribute to it as an external party. Typically if when I run the workflow, it would run in the context of my repository, which I control and I already have access to. But this pull request target will say I'm actually okay with, or you're okay with my code running in the context of your repository. And so that becomes, that becomes bad if I'm also providing. Providing you're also using like pulling my. And checking out my code and then doing some sort of work with it. Right. And then I could, I could poison you, basically.

[A]

Exactly. And to put this into like, perspective of folks that might not be as familiar with the mechanics of how, you know, pull requests and things like that and what they are, I think of this as. It's almost like someone who you don't know at all shows up to the corporate office one day and says, hey, I've got some feedback about your product and I want to give you some, you know, some product ideas and you sit them down at a corporate laptop with like full credentials logged into the active directory and say, just, you use this laptop to give us that feedback. Right. Because it's this gnarly crossing of the trust boundaries where you're literally taking untrusted code from someone who knows who they are, but then you're running automated workflows that are going to cross the boundary from that untrusted code into your trusted code and potentially secrets and even more damaging things like shared caches, which is how. Who was it that was the Tanstack attack, It was poisoning that cache. Right. So it's just super important that folks understand that this is a literally trusted, trusted boundary. Automated things are happening. Secrets are across both of those boundaries and potentially longer lived artifacts as well. So that's why this is just so many dragons.

[B]

Yep. And one of the big problems is that when you run these GitHub actions, by default they're going to have write access to the repository. And in order to make a pull request, you do not require write access. So that's literally privilege escalation. Right. So you could leverage, essentially read access and convert it into write access and then you could do like Tanstack. I think one of the things that they did is they, they overwrote all of the releases. And so when you were relying on their code as a, as a downstream user, you were referencing a release that you thought was stable and reliable and had been tested and it got overwritten with this malicious code. And so now you are accidentally running malicious code, which then affects not just Tanstack, but it affects you as the user and the more broadly that software. Trivi was a similar example, I think, where the more broadly that software is being used, the more the blast radius of that kind of incident becomes.

[A]

Yeah, yeah, Talk us through some of the other lateral movements that can happen from within GitHub outside, because I imagine there's credentials here for deploying to cloud, potentially.

[B]

Sure, sure.

[A]

You know what else is in here?

[B]

Typically the whole thing comes around to, on the GitHub side at least, it comes down to what is the context in GitHub that I have to achieve in order to assume that role in the foreign platform. So it could be AWS, it could be GCP, it could be HashiCorp Vault, for instance, it could be Azure. And typically that context is going to be like a repository, it might be a branch, there's a couple other examples and then which GitHub users actually have the ability to achieve that context. And so that, that goes down to what permissions do users have on the repository? What are the branch protections that are in place that stop certain people from being able to do certain things without, you know, two party review and all that kind of stuff. Often what we find is that organizations have branch protections, but they don't necessarily understand all the complexities of how the branch protections work. And so they think that it does one thing, but it does something slightly different and it doesn't actually protect kind of that OIDC connection as well as they might hope.

[A]

Yeah, yeah. I mean, and look, all the things you just mentioned there, it's the classic Swiss cheese of. It's not like one easy exploit of one part of a GitHub workflow that's going to get you this access. Increasingly it's, you know, how do you get that initial access? Is it a PWN request? Is it a stolen credential? Can you move laterally into some sort of repo access? Can you put some sort of bad artifact in place? Whether it's modifying a workflow, whether it's putting something in a cache. Right. How does that, how does that then make its way into a pipeline that's got these OIDC tokens and then you can move along. Right. It's the classic thing of it's moved from here to here to here to here to here. So how should a CISO cybersecurity professional be thinking pragmatically through this? And you know, hopefully what we've just talked about makes them sit up and go, oh my goodness, I need to look into this. But like, where do they begin?

[B]

Is it okay if I tell you an anecdote about the point that you just made before the question?

[A]

Please do.

[B]

Yeah. So we, Spectre Ops has a red team, and I believe this is in our State of APM State of attack path management report that we released, kind of like a description of how this actually played out. But we were conducting a red team and we had some goal, some objective that we were trying to gain access to. And we had initial access on a computer that had a GitHub token. And so we were able to get access to GitHub, but it was a relatively unprivileged user. But we had access to a repository that had one of those secret scanning alerts. And so we were able to take that secret scanning alert that gave us access to jira, right? And so we were able to log into JIRA and we were able to find a JIRA ticket that had like a Jenkins token in it. And we were able to go to Jenkins and then the Jenkins pipeline, we found some pipeline that had a GitHub personal access token. And that personal access token was for a GitHub admin. And so we were able to go from like an ad computer to GitHub to Jira to Jenkins, back down to get the same GitHub organization, but as a privileged user. And then we were able to kind of like achieve that ultimate objective which gave us access to every, every repository and therefore all the foreign connections and all that kind of stuff. So this, that's the type of problem that we're trying to conceptualize here, which is all these things are interconnected in ways that nobody even concept, like nobody has any idea, right? We, we talk about federation, right? For instance, like identity federation. What we find is that the people that are in charge of AD and the people that are in charge of GitHub at organizations, they don't know each other, right? Like, they don't work together. They usually are very segmented from each other. And the GitHub person might know, for instance, that they use Okta for SSO into GitHub, right? Because they had to set that up. But what they don't know is that Okta has like password synchronization down to ad. And so the idea is that if I compromise your active directory, then I now have control over your Okta, and if I have control over your Okta, I have control over your GitHub. And so the GitHub admins don't even know that they're dependent upon active Directory upstream. And so that becomes a massive problem.

[A]

Yeah, yeah, man. It's wild how these step by step by step things just move laterally and get incrementally more and more and more credentials and onwards to victory. So what can any given CISO and cybersecurity defender do about this? What's the practical pragmatic advice here?

[B]

Yeah, so at SpectreOps we have Bloodhound, which is our main enterprise product. We even have Bloodhound Community Edition which is free and open source. And we've created a Bloodhound open graph extension that allows you to kind of gather all this information about your GitHub organization or GitHub Enterprise account and start to look at what repositories do I have? Are those repositories susceptible to these PWN requests, for instance, as initial access? If this user is compromised, what repositories do they have access to? Are those branch protection rules on these very sensitive GitHub repositories? Are those actually doing the job that we expect them to be doing? Right. We also have for instance those OIDC models built into where you can start to ask questions like which repositories are being used to authenticate downstream to Azure and which users have upstream have access to that repository such that they can abuse that and then what does that look like on the Azure side? So really it's about collecting the information, gain the visibility, having some of these hygiene type situations, it's relatively easy when you know what you're looking for to avoid those PWN requestable situations, for instance, but also understanding where do I have exposed secrets, where do I have over permissioning, where users have more users have access to interact with the repository than is necessary. It's all about first seeing the problem and then you can start to kind of chunk away at reducing the exposure of these repositories or these sensitive workflows.

[A]

Right. And the load bearing if in that statement there was if you know it's easy to mitigate these threats if you know where to look. And folks, I just don't think they know how to look. And as I understand it, that's sort of the core strength of Bloodhound is it will enumerate all these attack paths for you and it sounds like it's going to go thoroughly through not just your ad, but also your GitHub and all those other things that we've been talking about and actually point out, you know, like here's where you need to look. The Community Edition, the Open Source Edition. Are there any Sort of limitations around that or is it, you know.

[B]

Yeah, so the limitations are that we don't give you what we call findings, which are the Bloodhound enterprise. One of the general ideas behind that is that we do zone isolation. So imagine that in Active Directory we have tier zero, which is your domain admins, your domain controllers, anything that's kind of like adjacent to that. And we say show me all of the routes that would allow somebody that's not in tier zero to get into tier zero. And then we give you remediation guidance that says here's how you prioritize these, here's the steps you should take when you eliminate these. That same concept applies to GitHub and Azure and Okta, so on and so forth. In Community Edition you can have the data and the visibility, but what types of questions and how you analyze that data is kind of on you to figure out. There's some helpers there, but generally speaking it's kind of your job to investigate. So it's a visibility capability on the community side, not necessarily an analytical.

[A]

Right, that makes sense. And obviously there's a huge value add there in that analytics capability. So I get why that's in the Enterprise, but I think that the message here for folks should be, look, your GitHub environment is something that is now top of. It's the brightest spot on the radar for an attacker at the moment. There is just myriad ways in which it can go wrong. And I think often with GitHub you don't know you've done it wrong until you compromise. It's very, very hard to get the visibility that'll help you understand this. And so there's sort of no excuse why folks can't go out there and get started. At least with the Community edition of Bloodhound to start doing this enumeration, at least get those initial signals and if it comes back with a whole bunch of stuff, then that's probably your signal that you might need a little bit more help.

[B]

Oh yeah, and for, for GitHub in particular, that, that PWN request problem, for instance, we have a property that says is PWN requestable? I couldn't think of a better, better name for it, to be honest. So, so you could like literally say show, show me all the, all the repositories where the is PWN requestable property is true and then that would, that would point that out to you and hopefully the answer is zero, but if it's, you know, in one or more, then you can go figure it out.

[A]

Yeah, hopefully it's zero, but I bet it's not.

[B]

Oh, yeah, yeah, yeah.

[A]

Jared, this has been a lot of fun to thank you so much for dropping by and having this chat with me.

[B]

Yeah, I appreciate it, James. Thank you.