CI deployments, volunteers, and security

[rossabaker]

We have 90 people with write access to at least one repository in the org. This is great!

Any of them could conceivably exfiltrate a deployment secret, or publish an artifact outside the projects to which they've been added. This is not great!

I have no reason to suspect malfeasance, but how do we prevent a disgruntled volunteer from publishing Cats 2.9.1 and getting it into everyone's Scala Steward before anyone notices?

• Is there a way we could monitor for dubious artifacts on Maven Central?
• Should we consider (ugh) per project GPG keys to improve traceability? That's still projects, not people.
• ... but nobody validates GPG keys anyway, so that's not even preventative.

I'm proud of how we bring along new maintainers and wish to extend the tradition. I just wonder if we've fallen behind on any practices that could make it safer.

[softinio]

This is a valid concern, but hard to solve. I wonder if there are any security scanning tools that can be added to the CI run that have an OSS friendly pricing model that can be leveraged.

Not something I have looked at in detail, but wonder if this is something like codeql can be used help to some degree with this.

Also, wonder if anyone has written a tool to analyze GitHub audit log, if not this would be a fun side project to do for the purpose of helping with the concerns highlighted here.