[toomuchtodo]

Perfect security does not exist. Their security system (people, tech) operated as expected with an impressive response time. Room for improvement, certainly, but there always is.

Edit: Success is not the absence of vulnerability, but introduction, detection, and response trends.

(Github enterprise comes out of my budget and I am responsible for appsec training and code IR, thoughts and opinions always my own)

[timewizard]

> Perfect security does not exist.

Having your CI/CD pipeline and your git repository service be so tightly bound creates security implications that do not need to exist.

Further half the point of physical security is tamper evidence. Something entirely lost here.

[Aeolun]

I find that this is always easy to say from the perspective of the security team. Sure, it would be more secure to develop like that, but also tons more painful for both dev and user.

[timewizard]

I don't code anymore. I like making devs suffer. And this is all good for the user. ;)

[belter]

> Their security system (people, tech) operated as expected

You mean not finding the vulnerability in the first place?

This would allow:

- Compromise intellectual property by exfiltrating the source code of all private repositories using CodeQL.

- Steal credentials within GitHub Actions secrets of any workflow job using CodeQL, and leverage those secrets to execute further supply chain attacks.

- Execute code on internal infrastructure running CodeQL workflows.

- Compromise GitHub Actions secrets of any workflow using the GitHub Actions Cache within a repo that uses CodeQL.

>> Success is not the absence of vulnerability, but introduction, detection, and response trends.

This isn’t a philosophy, it’s PR spin to reframe failure as progress...

[toomuchtodo]

This is not great based on the potential exposure, but also not the end of the world. You’re free to your opinion of course wrt severity and impact, but folks aren’t going to leave GitHub over this in any material fashion imho. They had a failure, they will recover from it and move on. It’s certainly not PR from me, I don’t work for nor have any financial interest in GH or MS. I am a security person though, these are my opinions based on doing this for ~10 years (I am consistently exposed to security gore in my work), and we likely have an expectations disconnect.

As a customer, I’m not going to lose sleep over it. I’m going to document for any audits or other governance processes and carry on. I operate within "commercially reasonable" context for this work. Security is just very hard in a Sisyphus sort of way. We cannot not do it, but we also cannot be perfect, so there is always going to be vigorous debate over what enough is.

[koolba]

> Success is not the absence of vulnerability, but introduction, detection, and response trends.

Don’t forget limitation of blast radius.

When shit hits the proverbial fan, it’s helpful to limit the size of the room.

[toomuchtodo]

Yeah, I agree compartmentalization, least privilege, and sound architecture decisions are a component of reducing the pain when you get popped. It’s never if, just when.