Scan for leaked credentials in PRs and code diff using TruffleHog OSS 🐷

[JamieSlome]

Although GitHub's native secret detection is in place, there are various ways secrets can end up in files and commits. Plus, an extra layer of protection never hurts! 👍

To ensure the capture of leaked credentials, an assessment should occur at the pull request level, with PRs blocked if TruffleHog returns any results. Moreover, pull requests should only be mergeable if TruffleHog returns empty.

Tasks

Beta Give feedback

1. On all pull requests, run secret detection against the source branch
2. Use TruffleHog OSS
3. Enable TruffleHog OSS as a required status check for PR merge
4. On a code push via Git Proxy, run secret detection against generated diff

[JamieSlome]

@abinash2512 - want to take this one on?

[JamieSlome]

@abinash2512 - I've updated the scope of this ticket to include:

1. Running TruffleHog as a pull request check on our GitHub repository, via GitHub Actions
2. Assess code pushed through Git Proxy for secrets using TruffleHog as a new push processor

[JamieSlome]

@maoo - after our community discussion today, we recognised that TruffleHog uses the AGPL-3.0 license. Do you think this would be a problem running it as a status check when pull requests are opened?

@coopernetes mentioned that running it as an embeddable plugin or assessment layer in Git Proxy itself may be problematic but wanted to see what you think about running it as a GitHub Action?

[maoo]

@maoo - after our community discussion today, we recognised that TruffleHog uses the AGPL-3.0 license. Do you think this would be a problem running it as a status check when pull requests are opened?

Yes, I believe so; there are actually 2 things that concern me:

• The "GPL" part of it, which would force all our derived code (eg, a GitProxy plugin that uses TruffleHog) to be released as GPL; assuming we would build the code based on the 2.x architecture, we could host the plugin as a separate FINOS project, and release it as GPL, though I'm not sure if you would be able to run it on your end
• The "A" part, which could affect the license of GitProxy

I can seek legal advice, though it could take some time.

@coopernetes mentioned that running it as an embeddable plugin or assessment layer in Git Proxy itself may be problematic but wanted to see what you think about running it as a GitHub Action?

I think that leaked credentials is a crucial use case for GitProxy, and we should provide it as a plugin that adheres to the GitProxy 2.x architecture.

I also think that we should consider evaluating TruffleHog alternatives; from a quick seach I found https://github.com/GitGuardian , but I'm sure there are way more.