roadmap VS trufflehog

Same message as for PyPI compatible package registry: https://github.com/github/roadmap/issues/94

Yeah I had to look around a bit but yep… https://github.com/github/roadmap/issues/94

It looks like a lot of things have been killed… which with my cynical hat on I think might have something to do with overlapping capabilities with Azure services.

Others have mentioned tmate to SSH into a running GitHub Actions workflow; there is a roadmap issue making that functionality built-in to Actions, planned for 2023/Q4.

Immutable actions are on GitHub's roadmap.

I think not yet, but seems to be in the roadmap

Any ideas how to solve this? Github already released information on a certain feature they will be developing in the future, but do you know any workarounds for now? Do I need to use an external package registry and use registry hosting service that allows me to modify the accessibility permission? Which do exist?

Trufflehog

Frankly, I think it will take years to replace API-keys (if it will ever happen). Developers are much better-off using CLI tools that prevent leaking secrets by blocking commits to git (e.g., https://github.com/Infisical/infisical or https://github.com/trufflesecurity/trufflehog)

Trufflehog also offers pre-commit hooks. You can have it report on PRs too.

Is this not just a another https://github.com/trufflesecurity/trufflehog?

I agree that code scanning is really important, the best way to convince others is to identify high-risk threats in source code and present them to the decision-makers. For example, scanning Secrets is great for showing how repositories can be a massive vulnerability and identifying some low-hanging fruit, especially in the git history. Attackers are really after git repository access for this reason and there are plenty of open-source or free tools that you can use to illustrate the problem. Git-Secrets, Truffle Hog. These aren't great for a long-term commercial solution, something like GitGuardian is a better commercial tool but if the goal is just to illustrate the problem then finding some high-value secrets with free tools is a good way to convince the security personnel to invest in some solutions. Then the door is open to having more conversations as you have already proven the risk.

It’s easy to think that it’s only important to scan for secrets in your public-facing repositories, but this real-world data breach proves that you need to treat all code the same from a security perspective. Malicious hackers can use open-source tools like Gitleaks and TruffleHog to quickly detect secrets in massive amounts of code*, without leaving a trace. As a defender, **it’s extremely important to have secret scans tightly integrated into your SDLC* (software development lifecycle) to reduce the risks of exposing them. GitGuardian offers secret scanning for private repositories in their Free, Business, and Enterprise plans.

There are software like Trufflehog ( https://github.com/trufflesecurity/trufflehog ), that finds secrets. We are using it at organizational level, but there's always some delay from finding something and getting it reported. I've been meaning to add it both to our CI so our team can notice right away, and even to Git push hooks, to catch these cases early.

https://github.com/trufflesecurity/trufflehog And https://github.com/Yelp/detect-secrets

Have you tried trufflehog or gitrob? gitrob trufflehog