Clarify meaning of "standardized tooling"

From @JustinCappos in Slack:

I was curious about the meaning of "standardized tooling" here: https://baseline.openssf.org/versions/2025-02-25.html#osps-br-0501 Would this prevent an organization from using more secure tooling which isn't as widely deployed? I assume you instead want to argue that tooling should be at least as secure as the standardized tooling.
FTP /HTTP were the standard for software downloads ~20 years ago (even for package managers), with the MD5 sum listed on a website in many cases. This moved to using HTTPS, which thankfully has been largely subsumed by better systems (Sigstore, TUF, etc.). We wouldn't have wanted people to get stuck at any of these intermediate points because they read the guidance and feel like they aren't permitted to do better

Eddie says:

I think the intent was simply to say that the tooling shouldn't be entirely custom. Even if an approach isn't widely adopted, but it follows some public spec or standard, that would still fall into the letter of the law as the requirement is currently written. I think the recommendation is what seems to restrict it to commonly adopted tools.

Evan suggests:

Recommendation: Use existing dependency tooling for your ecosystem, such as package managers or dependency management tools to ingest dependencies at build time. This tooling MUST be at least as secure as the default choice for that ecosystem. This may include ...

But asks:

What do other people think on "ingest dependencies at build time" vs some other wording that would allow for ingesting and validating dependencies at commit time rather than at build time?

Start with the linked OSPS-BR-0501 section in the 2025-02-25 baseline and review the surrounding recommendation. Resolve whether “standardized tooling” permits more secure alternatives and whether dependency validation may occur at commit time as well as build time. Done means the guidance clearly expresses the agreed scope without discouraging stronger approaches.