Does OpenSSF need classification criteria？

[SamYuan1990]

I hope OpenSSF can provide a classification criteria, with reasons below:

• Tag is not reliable
  Is well known that latest tag is not reliable, but does it reliable for specific tag or specific hash?
  Hence if we tag as 3.0 as an example, the 3.0 can refresh to 3.1 in some case as retagging.
  either for commit, can be refreshed by squash.

• Considering with devops/pipeline as code there need some trade off due to implementation.
  Can't use 'tar -xzf' extract archive file actions/checkout#1448 taking this case as an example, for example, the issue is happened when pipeline code points to 3.0 hence if some one points to latest/main then free from the issue.
  Which means, if just look at this case, as the checkout code feature is just for checking out the code... hence there is no difference for user to use latest/main tag.

• Does OpenSSF or minimal permission policy works for all devops?
  Take github action as an example, if we want to reuse pipeline. For an example

pr.yml // for pull_request pipeline, just a trigger for unittest, and lint
unit.yml // for unit test pipeline
lint.yml // for lint

hence the pr.yml may need token more than read permission, which seems against minimal permission policy, and reported by scorcecard action?

• Does the build difference between different devops instance?
  If I am correct, ideally, the build from same package on different instance will have the same result. IMO, that's why container works among different instance, as in the open container spec, there is diff hash between each layer, and if don't rebuild the layer, the diff hash keep the same, and able to run on different instance.
  Hence when open source pipeline running among a pool of instance, should we care about the instance is located at US or EU?

• Take CVSS table as an example, classification criteria works
  Hence IMO, personally, a classification criteria can help, as we can decouple pipeline code and business code from repo. They can use different security model. As there seems no need to upgrade checkout action within 24 hours, as the checkout action almost running in a pool of instance on cloud for public repo codes. But for log4j issue, we need fix it asap. Which means a classification criteria can better adopted with ... thousands of opensource code repos.