Secret scanning's delegated bypass controls for push protection (public beta) - feedback

[courtneycl]

GitHub Advanced Security customers using secret scanning can now specify which teams or roles have the ability to bypass push protection. This is intended to help reduce bypass rates within organizations that see high levels of live secrets being bypassed and committed into repositories.

This is managed through a new bypass list, where organizations can select which teams or roles are authorized to bypass push protection and act as reviewers for bypass requests. If an individual not included in this list needs to push a commit that is initially blocked, they must submit a bypass request. This request is then reviewed by an authorized individual who can either approve or deny it, determining whether the commit can proceed into the repository.

🗣️ We're looking for your feedback as we're in beta, both from the reviewer side and from the requestor side.

Things like:

• what kind of information about the secret would help the reviewer make a decision on the request?
• what are the challenges reviewers are encountering when tracking requests?
• what questions or uncertainties are developers left with during and after submitting a request?

Thank you very much -- we appreciate you ❤️

---

Learn more about secret scanning | Learn more about push protection

[ebickle]

We've deployed this internally and it's working great.

I have a couple requests though!

• We want to centrally approve push protection bypasses, but right now the bypass requests can only be viewed at the repository level. Could an organizational dashboard/page be created to show all requests for an entire organization?

• I see a secret_scanning_push_protection_request.request action in out log streaming, but no webhook equivalent. We need a webhook for push protection requests - we'd like process the webhooks in our GitHub App and then create items in our team's intake board. Right now we have no way to do that - without the dashboard and webhooks, the requests all just go nowhere unless someone knows who to reach out to.

Thanks!

[courtneycl]

Hi @ebickle! Thanks for trying this out, and for your feedback here.

Both the org-level view for requests and webhooks are coming. They are both part of our requirements for GA, but webhooks will land before the org-level view does.

For

the requests all just go nowhere unless someone knows who to reach out to.

are the reviewers on the bypass list getting emails with the requests?

[ebickle]

Thanks for the info @courtneycl!

I checked into the email alerts and I don't believe that's working at the moment. I had someone try to create an artificial bypass request - I can see the request on the repository's security tab and the associated audit log, but no email yet. We have a team set up rather than individual approvers - maybe that's why?

[ebickle]

I partially take that back. I did receive an email, but it went to the personal (primary) email address on my account rather than the corporate email I had configured specifically for the organization. My suspicion is the bypass request emails aren't honoring the custom routing rules on defined on the https://github.com/settings/notifications/custom_routing page.

[courtneycl]

@ebickle aah that's helpful! Okay! We'll look into that and fix it. Thank you.

Another thing we're doing is showing the list of reviewers on the bypass request itself, so developers will be aware of who the request goes to in case they need to contact them out of band.

[courtneycl]

@ebickle this should be fixed now -- thank you for the report and for your patience.

[harringj]

Hi, @courtneycl! The delegated bypass feature is one we're planning to rely on as a key control to keep provider secrets out of our GitHub environment, so we're very excited about it. That said, our testing has uncovered some problems.

Using the CLI, I was able to use a non-privileged account (i.e. a non-org-owner, non-security-managers account) to bypass push protection and commit a GitHub PAT to a repo in one of our orgs that has the delegated bypass turned on.

Then, two of my colleagues were able to use the web UI to push an azure ad application key (push protection itself didn't even work on this one) and a hashi key (where delegated bypass didn't work).

Have others reported similar concerns? Happy to get on a call with your team sometime to demo what we're seeing. Thank you!

[harringj]

@courtneycl bump, please 🙂

[courtneycl]

Sorry @harringj! Not working from the CLI certainly is curious 🤔 I'll send you an email to set up a time to dig through it.

We don't support delegated bypass from the web UI yet, but regular push protection should indeed be working there for supported tokens.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[wilmoore]

Hello @courtneycl,

I don't know if it was this specific release item, or one of the others listed in the changelog for July 8th, but, I suspect based on the timing, that one of the items for July 8th caused a regression for the Gist QuickSearch Input field.

I've documented what I know about this here:
https://github.com/orgs/community/discussions/131464

For a little more context:

1. Sometime in the AM, possibly 11am/noon (roughly), the Gist QuickSearch was functioning the same way it has always functioned for years.
2. I went out for a few hours, and came back around 5pm, so sometime after 5PM (MST) I noticed the QuickSearch not only looked different (i.e. CSS), it also doesn't focus after pressing "/", and, typing characters known to result in search results, does nothing.

I know releases can be a bit chaotic, but, I suspect that those that rely "Heavily" on Gist search functionality (i.e. Gists are my personal Notion), might be in a bit of disarray at the moment due to this regression. If it's a feature (I can't see how it would be), it certainly wasn't listed in the changelog.

I should also note that, it seems that when logged out, the QuickSearch functions as it always has. When logged in, this is where the potential regression can be noticed. Also, attempts to log out from the Gist screen, seem to do nothing, while, logging out from main github.com, does do what it is expected to do.

I'll also take this opportunity to ask, is gist.github.com being deprecated or, it is just a lack of resources with eyes on that sub-domain ATM?

[courtneycl]

Hi @wilmoore! That change isn't related to this release. I moved your other post into the Repositories category; they're the team that owns gists and can speak more to it.

[Chocrates]

Did this release have any undocumented changes to branch protection defaults?
We have a use case where we sync a repo from a source repo in an org to a destination repo in another org. the destination has branch protections and we have added the user doing the sync in the bypass list on the branch protection.

This broke "all of a sudden" Between Friday and Yesterday. Looks like it is because Do not allow bypassing the above settings is now enabled by default and allow force pushes is now needed to allow automation to sync repositories.

[garpur]

When you need a exception because of test-code etc it needs to be handled promptly -- preferably within 15 minutes.
Having to wait for more than an hour is unacceptable.

[courtneycl]

Hi @garpur, this is good feedback to send to the team that is triaging your requests.

[samigt]

As an security admin approver, I need a glimpse of the detected secret (in the dev request) to be able to make a judgment if it is a false positive or not.

[courtneycl]

@samigt what kind of glimpse would be helpful? Is seeing some of the characters sufficient, or do you need the full string?

[samigt]

We have to make sure it is balanced and controlled, I prefer to see all of it (as a security manager not just as a bypass approver) to see where I should tweak the custom signature.

However, we have a big list of bypass approvers each responsible for their own department, I would not want them seeing secrets from other departments ideally.

[ilakhtenkov]

Hi @courtneycl. We found feature very useful, but I was not able to find if there is a REST API, with which I could set up different bypass approvers across hundreds of repositories in my organisation?

[courtneycl]

Hi @ilakhtenkov -- glad it's useful!

The "Update a security configuration" API should help. The secret_scanning_delegated_bypass_options body parameter lets you set who the reviewers should be for that configuration. Then you can apply the configuration to repositories using the "Attach a configuration" API.

[ebickle]

I'm working on implementing the bypass_request_secret_scanning webhook and noticed that the completed action type doesn't fire when a response is submitted, only the response_submitted event.

I suspect the documentation is wrong and there are fewer action types (sub-event types) than described in the documentation. Or, alternately there's a bug and the completed event is supposed to exist but isn't being sent. Is anyone able to confirm?

[courtneycl]

The wording is admittedly confusing -- completed is fired when the developer pushes the secret after their request has been approved, essentially, completing the entire flow for that secret.

Requests that are denied will never get "completed".