Feature: Check custom CII Best Practices URL

[jmgate]

Is your feature request related to a problem? Please describe.
I work in an environment where the majority of the software project cannot be open source due to a variety of security and need-to-know requirements. However, we'd like to take advantage of some of the great tools made available by the OpenSSF, so we're looking at standing up internal instances of the Best Practices Badge App and securityscorecards.dev. Once we have the internal Badge App stood up, it would be great if we could just point scorecard to it in some way.

Describe the solution you'd like
I'm flexible on implementation details, and trust whatever you think is best. Some potential solutions that come to mind:

1. Environment variable: E.g., CII_BEST_PRACTICES_URL=https://bestpractices.company.com scorecard --repo internal-gitlab.company.com/{owner}/{repo}.
2. Command line option: E.g., scorecard --repo internal-gitlab.company.com/{owner}/{repo} --cii-best-practices-url https://bestpractices.company.com.

Describe alternatives you've considered
If this enhancement is undesirable, we can always fork this project internally and replace all instances of https://www.bestpractices.dev with our internal Badge App URL. Looks like that would only need to happen in

• clients/cii_http_client.go
• cron/internal/cii/main.go

plus updating some links in a few Markdown and YAML files if we want to be consistent across the board.

Additional context
N/A

[spencerschrock]

Just to clarify:
Your internal environment has access to the public internet, but you can't register your project with https://www.bestpractices.dev because the projects are not open source?

I ask because there are other checks with clients that attempt to reach out to third party services. Part of Fuzzing checks for OSS-Fuzz integration data, and the Vulnerabilities references osv.dev.

[spencerschrock]

If you're only hosting an internal instance to satisfy the CII-Best-Practices score, you could also consider not running that check and then it won't affect your score.

If you already planned on hosting an internal instance of the best practices app and just want Scorecard to connect to it, either of your suggestions are feasible. We have gone with option 1 in the past for GHES support for example.

[jmgate]

Thanks for the quick response, @spencerschrock. Hopefully this can clarify things:

Your internal environment has access to the public internet, but you can't register your project with https://www.bestpractices.dev/ because the projects are not open source?

That's correct.

If you already planned on hosting an internal instance of the best practices app and just want Scorecard to connect to it…

Yes, this is what we'd like to do.

you could also consider not running that check…

Understood. There are some checks we intend to disable internally (anything GitHub-specific, as we use self-managed GitLab inside), but this is a case where we'd like the check to be there, but to look to an internal URL.

there are other checks with clients that attempt to reach out to third party services…

I'll have to look closer at all the checks to which ones we might want to disable or modify. I'm still just in the project proposal stage and trying to get a better idea of the scope for any changes we'd want/need to make to stand these tools up internally.

[spencerschrock]

Sounds good. If this moves out of proposal stage, feel free to pursue the env var approach.
We could probably read the env var in DefaultCIIBestPracticesClient, and set some state for the httpClientCIIBestPractices struct.

scorecard/clients/cii_client.go

Lines 65 to 68 in 367426e

	// DefaultCIIBestPracticesClient returns http-based implementation of the interface.
	func DefaultCIIBestPracticesClient() CIIBestPracticesClient {
	return &httpClientCIIBestPractices{}
	}