Scorecards False Positives for Token Permissions & Pinned Dependencies in Repos Using Shared GitHub Actions

[Ndacyayisenga-droid]

Hi everyone,

I'm reaching out regarding an issue we encountered while running OpenSSF Scorecards on the Apache Maven repositories.
We've noticed that the token permissions and pinned dependencies checks are flagging findings for every repo. However, our workflows rely heavily on shared GitHub Actions, such as apache/maven-gh-actions-shared. These shared actions do pin dependencies and restrict token permissions properly, for example, see maven-verify.yml#L197.
An example repository using these shared actions is: https://github.com/apache/maven-dependency-plugin/tree/master/.github/workflows
It seems that the current Scorecards checks don't take shared actions into account when evaluating individual repositories.

1. We’d appreciate your input on the following:
2. Is there a plan to support or account for shared GitHub Actions in Scorecards evaluations?

If not, would you recommend a workaround or alternative approach?
Thanks for all the work on Scorecards, it's been very helpful! Looking forward to your thoughts.
Best regards,
Noah

[Fix3dP0int]

It seems that scorecard only ignores the local(internal) workflows by considering the below code:

		if job.WorkflowCall != nil && job.WorkflowCall.Uses != nil {
			//nolint:lll
			// Check whether this is an action defined in the same repo,
			// https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#referencing-an-action-in-the-same-repository-where-a-workflow-file-uses-the-action.
			if !strings.HasPrefix(job.WorkflowCall.Uses.Value, "./") {
				dep := newGHActionDependency(job.WorkflowCall.Uses.Value, pathfn, job.WorkflowCall.Uses.Pos.Line)
				pdata.Dependencies = append(pdata.Dependencies, dep)
			}
		}

The most accurate way might be to check the direct dependencies of each workflow and observe whether these dependent workflows are secure. But I think this would become very complex and would consume a large amount of tokens. Perhaps we could consider exempting dependencies under the same owner/organization. We should check whether the dependencies workflow secure (like #4716 said).

[Ndacyayisenga-droid]

It seems that scorecard only ignores the local(internal) workflows by considering the below code:

		if job.WorkflowCall != nil && job.WorkflowCall.Uses != nil {
			//nolint:lll
			// Check whether this is an action defined in the same repo,
			// https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#referencing-an-action-in-the-same-repository-where-a-workflow-file-uses-the-action.
			if !strings.HasPrefix(job.WorkflowCall.Uses.Value, "./") {
				dep := newGHActionDependency(job.WorkflowCall.Uses.Value, pathfn, job.WorkflowCall.Uses.Pos.Line)
				pdata.Dependencies = append(pdata.Dependencies, dep)
			}
		}

The most accurate way might be to check the direct dependencies of each workflow and observe whether these dependent workflows are secure. But I think this would become very complex and would consume a large amount of tokens. Perhaps we could consider exempting dependencies under the same owner/organization. We should check whether the dependencies workflow secure (like #4716 said).

Thanks for the thoughtful response, @Fix3dP0int, that makes sense, and I see how deeply analyzing external shared actions could get costly and complex.

To clarify, our main concern is that these shared workflows (like apache/maven-gh-actions-shared) are being flagged despite adhering to best practices (pinned dependencies, token restrictions, etc.). We're not expecting Scorecards to fully trace and validate every external workflow recursively, rather, it would be helpful if Scorecards could optionally recognize and trust shared workflows from the same GitHub organization (e.g., apache/*), perhaps behind a flag or heuristic.

Would a feature like “trusted org-level actions” be feasible or in line with the Scorecards philosophy?

Happy to help experiment or contribute ideas if that helps move the conversation forward!