赞助内容：理解 CI/CD 攻击路径

大家好。

Hey, everyone.

我是Risky Business的James Wilson，欢迎收听这次赞助访谈，今天我邀请到了SpecterOps的CTO Jared Atkinson。

I'm James Wilson from Risky Business, and welcome to this sponsored interview where I'm joined by Jared Atkinson, the CTO of SpecterOps.

SpecterOps开发了非常出色的攻击路径分析工具Bloodhound，这次和Jared的对话重点聚焦在GitHub上——它最近在许多供应链攻击中扮演了核心角色。

SpecterOps of course make Bloodhound the really awesome attack path enumeration tool and this discussion with Jared is actually focusing in on GitHub and the the central role it has played recently in a lot of these supply attacks we've seen unfold.

我们从攻击路径分析的角度来看待这个问题：GitHub不仅是代码存储的地方，更是驱动你自动化CI/CD构建、测试和部署流程的关键环节，有时候，整个流水线甚至就直接运行在GitHub上。

And we approach this from the perspective of, you know, 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, GitHub as either the thing that is driving your automated CICD build, test, deploy pipelines, but sometimes that's actually where the pipeline itself is.

这次对话让我觉得特别有启发，因为我之前根本没有意识到，攻击者能通过这么多不同的方式进入你的GitHub仓库，更没想到他们能在里面找到如此多样的凭证，进而横向移动。

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 the many different forms of credentials that they can then find there and move onwards from.

GitHub其实是一个绝佳的横向移动跳板，一旦你没认真梳理过潜在风险和应对措施，它就会给攻击者带来极大的便利。

It's it's like GitHub is this incredible pivot point for lateral movement that 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.

接下来我会让Jared来谈谈一个常见的误区：很多人觉得只要把GitHub仓库设为私有，不对外公开，就万事大吉了。

So I'll drop you here into this chat where Jared starts to talk about how, kind of exactly to that point that 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, that it it really made me sit back and think, wow, this is an extensive problem.

希望你们喜欢这场对话。

Really hope you enjoy this conversation.

我注意到，很多人只关注外部网络上的暴露风险，却低估了企业内部的潜在威胁。

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 assume 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?

举个例子，如果你的Active Directory账户或电脑被攻陷了，那通常也就是你登录GitHub的入口。

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 and some, data dump or something like that, that's that's really bad and we need to be worried about that.

但我们不能只停在这里，还得继续审视一下，我们是怎么管理各个仓库的权限的，默认的权限设置到底是什么。

But we shouldn't stop there, we should continue to look at how are we, managing permissions to different repositories, what is the the default resting permission.

比如 GitHub 有个叫‘默认仓库权限’的设置，一不小心就会把你们组织里所有用户都设成所有仓库的管理员。

There 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.

这肯定不是好事，不是说‘不小心’就没事了。

That's not a good thing to be just No, accidentally it's not.

不过顺便说一句，这默认不是这样，但确实能这么设置。

It's not the default, by the way, but it's, but it it is possible.

如果你开了这个选项，那只要有人攻入了你的 Active Directory 环境，就能直接访问所有仓库。

And so like, 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.

咱们来具体聊聊，GitHub 攻击到底是怎么发生的？

Let's get down into the detail of like, what does it act what's the what's an anatomy of GitHub attack?

我们总听到 OIDC 令牌、攻击路径这些术语，你给讲讲这些到底是什么意思。

I mean, we see these acronyms like OIDC tokens and paths and things like, talk talk me through this.

是的

Yeah.

我们可以用一套成熟的做法来分类，比如初始访问、权限提升，然后是横向移动。

Maybe we could we could use kind of the tried and true taxonomy of like initial access, privilege escalation, and then, lateral movement.

是的

Yeah.

是的

Yeah.

这其实就像一个框架。

It's kind of like a 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.

Pwn请求这种手法更隐蔽一些，尤其是如果你不太了解它的具体细节的话。

The pwn request is a little bit more surreptitious, especially if you don't, if you're not familiar with the details of it.

GitHub 的一个主要目的就是让代码公开，对吧？

One of the one of the big problems is that one of the points of GitHub is to make code publicly available, right?

开源的理念就是把代码公开，而且你通常会设置一个 GitHub Action 工作流，也就是某种 CI/CD 流程。

So open source, the idea is just 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 that you're implementing.

触发这些工作流的方式有好几种。

And there's several different ways that you can kick off these 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.

这意味着，当你发起拉取请求时，GitHub Action 不会在你自己的分支上运行。

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, you're also using, like pulling my and checking out my code, and then doing some sort of work with it.

对吧？

Right?

那我 basically 就能害到你了。

And then I could I could poison you, basically.

没错。

Exactly.

为了让大家更清楚，特别是那些不太了解拉取请求这类机制的人，我来打个比方。

And to put this into, like, perspective of folks that might not be as familiar with the the mechanics of how, you know, pull requests and things like that and what they are.

这就像是一个你完全不认识的人，突然跑到公司，说：‘我对你们的产品有些建议，想提一提。’然后你直接让他坐到一台已经登录了公司域账户、拥有全部权限的电脑前，说：‘你用这台电脑给我提建议吧。’

I 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 feedback about your product and I want to give you some product ideas, and you sit them down at a corporate laptop with full credentials logged into the active directory and say, just use this laptop to give us that feedback, right?

因为这本质上是严重越界了——你居然在直接运行一个完全陌生的人提交的、不可信的代码。

Because it is this gnarly crossing of the trust boundaries where you're literally taking untrusted code from someone, who knows who they are.

对。

Yep.

但接着你还会运行自动化流程，这些流程会把来自不可信代码的干扰带入你的可信代码，甚至可能波及密钥、共享缓存这类更危险的东西，这到底是谁干的来着？

But then you're running automated workflows that are gonna 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?

就是那个 TAN 栈攻击。

That was the TAN stack attack.

对吧？

Right?

他们是在污染那个缓存。

It was poisoning that cache.

所以大家真的得明白，这本质上是可信与不可信之间的界限，自动化操作正在跨越这条线，密钥和其他长期存在的数据都可能被牵连。

So it's just super important that folks understand that this is a literally trusted, untrusted boundary, automated things are happening, secret are across both of those boundaries, and potentially longer lived artifacts as well.

没错。

Yeah.

所以这就是为什么这里面藏着这么多隐患。

So that that's why this is just so so many so many dragons.

对。

Yep.

其中一个大问题是，当你运行这些 GitHub Actions 时，默认情况下它们拥有对仓库的写入权限。

And one of 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?

所以你可以利用只读权限，把它变成写入权限，然后像 TANSTACK 那样，他们干的一件事就是覆盖了所有发布版本。

So you could leverage, essentially read access, and convert it into write access, and then you could do like TANSTEK, think one of the things that they did is they they overwrote all of the releases.

当你作为下游用户依赖他们的代码时，你以为自己引用的是一个稳定、可靠、经过测试的版本，结果却被恶意代码替换了，于是你不知不觉就在运行恶意代码，这不仅影响了 TANSTACK，也影响了你本人。

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 were accidentally running malicious code, which then affects not just TANSTAT, but it affects you as the user.

而且这种软件用得越广，比如 Trivy 就是类似的例子，这类事件造成的波及范围就越大。

And the more broadly that software, Trivy was a similar example, think, where the more broadly that software is being used, the more the the blast radius of that kind of incident becomes.

没错。

Yeah.

确实如此。

Yeah.

你能不能讲讲，从 GitHub 里面还能怎么横向渗透到外部系统？

Talk us through some of the other lateral movements that can happen from within GitHub outside.

我猜这里应该存着部署到云平台的凭证吧？

Because I I imagine there's credentials here for deploying to cloud potentially.

当然。

Sure.

当然。

Sure.

通常来说，这里还会有什么别的东西？

You know, what what else is in here typically?

归根结底，在 GitHub 这边，关键是你得拿到什么样的上下文权限，才能在外部平台冒充那个身份？

The whole thing comes about 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?

比如 AWS、GCP、HashiCorp Vault，或者 Azure 都有可能。

So it could be AWS, it could be GCP, it could be HashiCorp Vault, for instance, it could be Azure.

通常来说，这个上下文就是某个代码仓库，也可能是某个分支。

And typically, that that context is going to be like a repository, it might be a branch.

还有其他几个例子。

There's there's a couple other examples.

但更重要的是，哪些 GitHub 用户真正拥有达成这种环境的权限。

But and then 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.

他们以为分支保护能实现某种效果，但实际上它的作用略有不同，也没能像他们期望的那样有效保护 OIDC 连接。

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 it as they might hope.

是的。

Yeah.

对。

Yeah.

说到底，你刚才提到的这些情况，就像瑞士奶酪一样，不是靠 GitHub 工作流里某一个简单的漏洞就能获得访问权限的。

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 GitHub workflow that's gonna get you this access.

现在越来越关键的问题是，怎么才能获得最初的访问权限？

Increasingly, it's, you know, how do you get that initial access?

是通过一个普通用户的请求吗？

Is it a pawn 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?

这些手段是怎么渗透到那些带有OIDC令牌的流水线里的？然后你就能继续推进了，对吧？

How does that act 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 it's the classic thing of it's it's moved from here to here to here to here to here.

那么，CISO和网络安全专家该怎么实际地应对这个问题？

So how should a CISO cybersecurity professional be thinking pragmatically through this?

希望我们刚才聊的这些能让人意识到：天哪，我得赶紧查一查这个问题了，但具体该从哪儿下手呢？

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 where do they begin?

在回答你这个问题之前，我可以跟你讲个相关的亲身经历吗？

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

当然可以。

Yeah.

我们SpecterOps有个红队，就在我们发布的《攻击路径管理现状报告》里，其实就提到过类似的情况。

So we SpecterOps 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.

当时我们开展红队演练，目标是拿下某个系统，最初我们通过一台电脑获得了访问权限，那台电脑上存着一个GitHub令牌。

But we were conducting a red team and we had some goal, some objective that we were trying to gain access to, and we we had initial access on a on a computer that had a, GitHub token.

于是我们成功登录了GitHub，但那个账号权限很低。

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 a seek one of those secret scanning alerts.

我们利用这个告警，成功拿到了Jira的访问权限。

And so we were able to, take that secret scanning alert, that gave us access to Jira, right?

于是我们登录了 Jira，找到了一个包含 Jenkins 令牌的工单。

And so we were able to log in as log in to Jira and we were able to find a Jira ticket that had like a a Jenkins token in it.

接着我们进了 Jenkins，通过那个令牌发现了一个流水线，里面居然藏着一个 GitHub 个人访问令牌，而且还是管理员权限的。

And we were able to go to Jenkins, and then the Jenkins token, Jenkins pipeline, we found some pipeline that had a GitHub personal access token, and that personal access token was for a GitHub admin.

就这样，我们从一台域控电脑出发，一路经过 GitHub、Jira、Jenkins，最后又回到了同一个 GitHub 组织，但这次已经是管理员身份了。

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 of 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, like nobody has any idea, right?

比如我们常说的身份联邦，你知道吧？

We we talk about federation, right, for instance, like, Identity Federation.

我们发现，负责 Active Directory 的人和负责 GitHub 的人，根本互不相识。

The, 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.

GitHub 的人可能知道他们用 Okta 做单点登录，毕竟这事儿是他们自己搭的。

And the GitHub person might know, for instance, that they use Okta for SSO into GitHub, right, because they had to set that up.

但他们不知道的是，Okta 其实会把密码同步到 Active Directory 里。

But what they don't know is that Okta has like password synchronization down to AD.

所以，如果我攻陷了你的 Active Directory，那就等于控制了你的 Okta。

And so the idea is is that if I compromise your active directory, then I now have control over your Okta.

而一旦控制了 Okta，也就等于控制了你的 GitHub。

And if I have control over your Okta, have control over your GitHub.

所以 GitHub 的管理员根本想不到，他们的系统居然依赖着上游的 Active Directory。

And so the GitHub admins don't even know that they're dependent upon Active Directory upstream.

这就成了一个巨大的隐患。

And so that that becomes a a massive problem.

对。

Yeah.

是的。

Yeah.

对。

Yeah.

天哪。

Oh, man.

真是难以置信，这些系统一个环节接一个环节地横向蔓延，一步步积累更多权限，最终达成全面控制。

It's it's wild how these, like, step by step by step things just just move laterally and and get incrementally more and more and more credentials and onwards to victory.

那么，作为CISO或者网络安全人员，面对这种情况到底能做些什么呢？

So, you know, what can any given CISO and cybersecurity defender do about this?

有什么切实可行的建议吗？

Like, what's the what's the practical pragmatic advice here?

没错。

Yeah.

在SpecterOps，我们有一个主要的企业级产品叫Bloodhound。

So at at SpecterOps, we have Bloodhound, which is our our main enterprise product.

我们甚至推出了Bloodhound社区版，免费开源，还开发了一个Bloodhound开放图谱插件，能帮你收集GitHub组织或GitHub企业账户里的所有相关信息，看看你到底有哪些代码仓库。

We even have Bloodhound Community Edition, which is free and open source, and we've we've created a Bloodhound open graph extension that allows you to kind of gather all of this information about your GitHub organization or GitHub enterprise account, and start to look at what repositories do I have?

比如，这些仓库是不是容易成为PON攻击的入口？

Are those repositories susceptible to these PON requests, for instance, as initial access?

如果某个用户被攻破了，他能访问哪些仓库？

If this user is compromised, what repositories do they have access to?

这些关键的GitHub仓库设置了分支保护规则，但这些规则真的在起作用吗？

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?

我们还内置了OIDC模型，可以帮你问：哪些仓库正在用来向Azure做身份验证？

We also have, for instance, those OIDC models built in to where you can start to ask questions like which repositories are being used to authenticate downstream to Azure?

哪些用户有权限访问这些仓库，从而可能滥用这种权限？

And, and which users have upstream have access to that repository such that they can abuse that?

一旦出现这种情况，到了Azure那边会是什么样子？

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 phone 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, you know, 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 these repositories or these sensitive workflows.

没错。

Right.

关键在于，如果你知道该从哪儿下手，这些威胁其实很好应对。

And and, you know, the the load bearing if in that that that statement there was if you you know, it's easy to mitigate these threats if you know where to look.

但我感觉，很多人根本不知道该怎么找。

And and folks, I I just don't think they know how to look.

据我理解，Bloodhound的核心优势就在于，它能帮你梳理出所有潜在的攻击路径，而且不只是你的Active Directory，连GitHub和其他我们聊过的系统，它都会彻底扫描，明确告诉你问题出在哪儿。

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 gonna go thoroughly through not just your AD but also your GitHub and all those other things we've been talking about actually point out, you know, like, here's where you need to look.

社区版和开源版有没有什么限制？还是说

Community the Community Edition, the open source edition, are any sort of limitations around that, or or is it, you know

是的。

Yeah.

所以限制在于，我们不会在社区版中提供所谓的‘发现结果’，而这是Bloodhound企业版的核心功能之一——即区域隔离。

So the the limitations are that we don't give you what we call findings, which are the the Bloodhound Enterprise, one of the general ideas behind that is that we do zone isolation.

举个例子，在Active Directory里，我们有零级权限，比如域管理员、域控制器，以及所有与此相关的资源。我们会帮你找出所有非零级用户可能通往零级权限的路径。

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.

同样的逻辑也适用于GitHub、Azure，还有Okta这些平台。

That that same concept applies to GitHub and Azure and, you know, Okta, so on and so forth.

在社区版里，你可以看到所有数据和整体情况，但怎么提问、怎么分析这些数据，就得你自己来琢磨了。

In Community Edition, you get 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 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

对，没错。

Right.

这确实说得通。

And that that makes sense.

而且很明显，这种分析能力价值很高，所以我理解为什么这功能只在企业版里提供。

And and, you know, obviously, there's a huge value add there in that analytics capability, so I get why that's in the enterprise.

但我想对大家强调的是，你的 GitHub 环境现在已经是攻击者最关注的目标了。

But I think that the message here for folks should be, look, you know, your GitHub environment is something that is now on top of of, you know, 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're compromised.

要获得能帮你看清这些问题的可见性，真的非常困难。

It's very very hard to get the visibility that'll help you understand this.

所以，大家完全没有理由不先从 Bloodhound 社区版开始，至少做一遍资产梳理，先拿到一些初步的信号。

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, you know, 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.

哦，对。

Oh, yeah.

特别是 GitHub，那个 Pwn 请求的问题。

And and for for GitHub in particular, that that pwn request problem.

比如我们有个属性叫 'is pwn requestable'。

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.

你可以直接查所有 'is pwn requestable' 为真的仓库，这样就能立刻发现问题所在。

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.

是的。

Yeah.

希望是零，但我猜肯定不是。

Hopefully it's zero, but I bet it's not.

是啊

Oh, yeah.

没错

Yep.

对

Yeah.

好的，贾里德。

Alright, Jared.

和你聊天真的特别开心。

This has been, a lot of fun to talk to you, man.

非常感谢你抽时间来和我聊这些。

Thank you so much for dropping by and having this chat with me.

对

Yeah.

我也很感谢，詹姆斯。

I appreciate it, James.

谢谢。

Thank you.