More like last year they laid off a whole bunch of people. We've been waiting for several open tickets on GitHub to be picked up, some were but seem to be abandoned and others just ignored.

Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. However, it wouldn't be unusual for the full error to be wrapped or swallowed by some lazy error handling. Its a bit of a PITA but well worth it to translate to a safe and informative user facing error.

as a nit; RBAC is applied to an object based permissions system rather than being one. Simply, RBAC is a simplification of permission management in any underlying auth system.

Azure’s RBAC system usually tells you this, at least when accessing the Azure management APIs. (Other APIs using RBAC, like the Azure Storage or Key Vailt ones, usually aren’t so accommodating. At least by their nature there’s usually only a handful of possible permissions to choose from.)

Not usually, that's considered an potential attack vector I believe. You're looking to minimize information leakage.

AWS has a neat feature to analyze cloudtrail logs to determine needed permissions.

there are ways to isolate code from CI from CD, it's just not as easy as setting up the classic repo. One can use multiple repos for example, or run CI and CD with different products.

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

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

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

Nobody is immune against mistakes, but a certain class of mistakes¹ should never ever happen to anyone who should know better. And that in my book is anybody who has their code used by more people than themselves. I am not saying devs aren't allowed to make stupid mistakes, but if we let civil engineers have their bridges collapse with an "shit happens" -attitude trust in civil engineering would be questionable at best. So yeah shit happens to us devs, but we should be shamed if it was preventable by simply knowing the basics.

So my opinion is anybody who writes code that is used by others should feel a certain danger-tingle whenever a secret or real user data is put literally anywhere.

To all beginners that just means that when handling secrets, instead of pressing on, you should pause and make an exhaustive list of who would have read/write access to the secret under which conditions and whether that is intended. And with things that are world-readable like a public repo, this is especially crucial.

Another one may or may not be your shells history, the context of your environment variables, whatever you copy-paste into the browser-searchbar/application/LLM/chat/comment section of your choice etc.

If you absolutely have to store secrets/private user data in files within a repo it is a good idea to add the following to your .gitignore:

  *.private
  *.private.*
 

And then every such file has to have ".private." within the filename (e.g. credentials.private.json), this not only marks it to yourself, it also prevents you to mix up critical with mundane configuration.

But better is to spend a day to think about where secrets/user data really should be stored and how to manage them properly.

¹: a non-exhaustive list of other such mistakes: mistaking XOR for encryption, storing passwords in plaintext, using hardcoded credentials, relying on obscurity for security, sending data unencrypted over HTTP, not hashing passwords, using weak hash functions like MD5 or SHA-1, no input validation to stiff thst goes into your database, trusting user input blindly, buffer overflows due to unchecked input, lack of access control, no user authentication, using default admin credentials, running all code as administrator/root without dropping priviledges, relying on client-side validation for security, using self-rolled cryptographic algorithms, mixing authentication and authorization logic, no session expiration or timeout, predictable session IDs, no patch management or updates, wide-open network shares, exposing internal services to the internet, trusting data from cookies or query strings without verification, etc

[flagged]