BUG: Github UI always has a different commitId - not allowing for False Positive Processes

[ambernormand]

This issue is each commit within the UI has a new commitId attached to it so there is no way for a user to report the false positive and continue on if they are using a frontend workflow.

Steps to reproduce

• User starts by editing a file within Github UI
• User adds a secret (a false positive) within the UI and attempts to commit to master - doing so provided push rejected feedback to the user with a commit Id which is to be reported as a false positive via the commit whitelist file
• User adds the provided commitId from the feedback in the whitelist file
• User again attempts to commit to master within the UI - user will again receive push rejected feedback

The only workaround we could think of was whitelisting the whole repo making it never be scanned until it was removed from that whitelist.

[d3jk]

@ambernormand, unfortunately this is a known limitation, but still needed if a user is trying to pass sensitive data into the repo via the GUI. We are open to new ideas of how to fix or workaround this, but for now we typically tell teams if they got blocked in the GUI and they cannot remove what is being flagged (assuming it is not sensitive data), they will have to push up from terminal or some other way that persists the commit id being generated or do what you are already doing and temporarily repo whitelist.

[sclouts]

@ambernormand We haven't been able to address this particular issue yet, however, we did release a new version of SEDATED® with lots of improvements (see below).

https://github.com/OWASP/SEDATED/releases/tag/v1.2.0