They weren’t kidding on the response time. Very impressive from GitHub.
replies(1):
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)
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.
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...
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.