feat: add control OSPS-BR-07 for secrets management

[trumant]

This change adds a new control to the Build & Release control family that focuses on secure handling and storage of project secrets.

This change closes #352

[eddie-knight]

Also, we have an outstanding action item to go back through all of the BPB identifiers to make them match the origin ID instead of the custom format

[funnelfiasco]

Thinking about this a little more, I don't think "Quality" is the right section. That's described as:

Quality focuses on the processes and practices used to ensure the quality and reliability of the project's source code and software assets. These controls help ensure that the project's source code is well maintained, secure, and reliable, reducing the risk of defects or vulnerabilities in the software.

I can see an argument for that, but I don't think it's the most apt. There's no perfect fit for this one, but I'd say "Access Control" is probably the closest?

Access Control focuses on the mechanisms and policies that control access to the project's version control system and CI/CD pipelines. These controls help ensure that only authorized users can access sensitive data, modify repository settings, or execute build and release processes.

[trumant]

Thinking about this a little more, I don't think "Quality" is the right section. That's described as:

Quality focuses on the processes and practices used to ensure the quality and reliability of the project's source code and software assets. These controls help ensure that the project's source code is well maintained, secure, and reliable, reducing the risk of defects or vulnerabilities in the software.

I can see an argument for that, but I don't think it's the most apt. There's no perfect fit for this one, but I'd say "Access Control" is probably the closest?

Access Control focuses on the mechanisms and policies that control access to the project's version control system and CI/CD pipelines. These controls help ensure that only authorized users can access sensitive data, modify repository settings, or execute build and release processes.

I waivered between those two as well. Thinking of projects implementing gitleaks style pre-commit and the like feels like a process quality issue, whereas deciding whether to manage secrets and credentials and if so, where, how, etc feels like a mix of AC and QA categories.

[evankanderson]

Should this be in Build & Release, since that is where most of the secrets are used?

[evankanderson]

The recommendation of manual audits for secrets in commit history seems a bit strong for level 1, but I'm reading it as a best practice rather than a requirement.

[trumant]

The recommendation of manual audits for secrets in commit history seems a bit strong for level 1, but I'm reading it as a best practice rather than a requirement.

My intention there was to point out that pre-commit checks are helpful but insufficient and that adding scheduled, automated checks via GHA and likely using the same tool used in pre-commit (gitleaks or similar)

If you read "manual" as implied we should probably copy edit a bit more.

[evankanderson]

The recommendation of manual audits for secrets in commit history seems a bit strong for level 1, but I'm reading it as a best practice rather than a requirement.

My intention there was to point out that pre-commit checks are helpful but insufficient and that adding scheduled, automated checks via GHA and likely using the same tool used in pre-commit (gitleaks or similar)

If you read "manual" as implied we should probably copy edit a bit more.

"Periodically audit" suggested a process which was at least partially manual. (Also, what happens if the audit flags a credential? There isn't explicit guidance here, and I can imagine folks trying to expunge content from history, which would be... not great.)

I guess my main concern was requiring an audit process and answering the "leaked credentials" question seem like a higher bar than the rest of the level 1 criteria (and harder to measure).

[evankanderson]

I'm happy with this as-is, just adding thoughts to see what others are thinking.

[evankanderson]

Thinking about the removal of audit guidance from BR-07.01 (which I agree with), I wonder whether we should say something here about "credentials where are suspected to have been compromised or leaked should be rotated promptly".

That may be too much detail, but I'm playing back the previous conversations, and I'm wondering if I lost some good in an attempt to broaden accessibility.