Add secret scanning and push protection to SCM-BestPractices recommendations

[david-a-wheeler]

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: https://github.com/ossf/tac/issues/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.

[balteravishay]

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]

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]

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?