rafskov

Congrats you've done a POC and purchased GHAS! Let's do a more detailed onboarding.

If you did not do a POC or just want to check on the basics, take a look at this guide.

Notifications

• Are we sure the right people are getting Dependabot alerts and Secret Scanning?
• Setup discussions with developers and engineers to review GHAS scan results, ideal developer flow, and integrations.
• Are we using Slack Actions?
• JIRA setup right?
• Do we have a plan and policy for ignores?
• Are we using Security Manager Role

rafskov

You may need to deauthorize accounts with SSH access from time to time. If you have the public key of the user (go to Org user's SSO details page or get use the API to get the public key), here's an idea on how to go about auditing ssh keys. You might also be able to use this to monitor for key rotation.

Recall a SSH public key fingerprint can be generated using ssh-keygen -l -f SSH Public Key File.

Then you can do the following to search for a match:

List organization members

For each user from above, run curl -s -k https://github.com/[user_name].keys | ssh-keygen -lf -.

rafskov

Reviewing PRs and compiling lists of PRs during audits can take time. One particular scenario is where an administrator uses their privileges to merge across protected brances without peer approval. How do you find these? While the below approach isn't perfect, it can give you some ideas.

When an administrator uses their privileges to override a branch protection rule and merge a pull request, an entry is written to the audit log with the category set to protected_branch and the action set to policy_override. You can search your audit log entries for these types of events by constructing a search query:

action:protected_branch.policy_override which will show events like this:

[user icon] [username] – protected_branch.policy_override Refs/heads/[branchname] was updated despite unsatisfied required status checks because [username] is an admin on [owner]/[repository]