Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add secret scanning and push protection to SCM-BestPractices recommendations #488

Open
david-a-wheeler opened this issue May 14, 2024 · 3 comments

Comments

@david-a-wheeler
Copy link
Contributor

It's sadly easy to accidentally insert secrets into a repository (here's an example).

We should modify the SCM Best Practices to say that any SCM should (where practical) enable scanning for secrets in a repo (including in proposed merge requests / pull requests), and then warn/prevent them (unless specially approved). E.g., in GitHub, secret scanning and push protection should be enabled. Linux Foundation projects can use LFX to use another secret scanning tool.

Related: ossf/tac#215

When implementing this, Set both as defaults for new projects, and add scanning to existing projects. Once the scanning for existing projects looks okay, add push protection.

david-a-wheeler added a commit that referenced this issue May 14, 2024
@balteravishay
Copy link

This is a great feedback, however it does venture a bit into the "tooling" side that sits on top of SCM, rather then actually being the SCM responsibility, wouldn't you agree?
We can say that for many of the tools that are offered by the platforms, where the code is that focus of the tool, rather than the code management tool itself such as dependency/vulnerability management capabilities

@Danajoyluck
Copy link

Added this to the security baseline. will need TAC vote on the enablement. Will raise a TAC issue and link this to the TAC issue and the baseline

@david-a-wheeler
Copy link
Contributor Author

This is a great feedback, however it does venture a bit into the "tooling" side that sits on top of SCM, rather then actually being the SCM responsibility, wouldn't you agree?

It's a little more complicated than that, as is also discussed in #489.

For GitHub, at least, this is an SCM configuration setting, not a separate CI/CD tool. I could agree that it might be better placed in a "CI/CD tool guide" - except we don't have one. Maybe we should make one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants