gh-action-pypi-publish VS trufflehog

> Recently I've seen someone on Reddit trying to automate the creation of PyPI projects through GitHub Actions. The person was complaining that the first deployment couldn't use an API key for that project since it didn't exist. So I'm not surprised some people are trying to do the same for malicious purposes.

Sorry for the tangent, but: you can do this now! If you use trusted publishing, you can register a "pending publisher" for a project that doesn't exist yet. When the trusted publisher (like GitHub Actions) is used, it'll create the project[1].

All of this is supported transparently by the official publishing action for GitHub Actions[2].

[1]: https://docs.pypi.org/trusted-publishers/creating-a-project-...

[2]: https://github.com/pypa/gh-action-pypi-publish

In the documentation example, I see that the action yaml file contains the line uses: pypa/gh-action-pypi-publish@release/v1. I have never done this before and almost went with that, but I am not sure why the example shows v1 hardcoded, so I don't think I actually want this to happen. It doesn't seem to be well explained though, and the pypi-publish action repo was also quiet on this. Is this saying that it will create a release branch in my repo and call the release v1? Or how will this appear after I've done it? Will I have to manually change this v1 to v0.1.1 in the actions file AND the pyproject.toml?

Yeah, you're uploading to PyPi in your pipeline, great. The custom github action still uses twine because the stdlib falls short on BASIC security. https://github.com/pypa/gh-action-pypi-publish/blob/unstable/v1/twine-upload.sh

I never bothered with pypi myself but I hope the nudge into github actions helps you. I've found the following promising github action: https://github.com/pypa/gh-action-pypi-publish

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