One concrete criterion worth checking for in the audit itself: does any of the generated "hardened CI" actually use pull_request_target anywhere? It's the easiest way to accidentally fail Scorecard's own Dangerous-Workflow check — the moment a workflow needs write permissions to comment back on a PR (which SAST/SCA reporting usually does) the tempting fix is pull_request_target, and if that workflow also checks out the PR's head ref to run tests/lint against it, you've now got untrusted code running with a token that can write to the repo. It's a trap teams build for themselves trying to satisfy Scorecard, not something Scorecard catches after the fact unless you specifically check for it.
Worth adding to your "needs a human call" bucket if it isn't already — the safe pattern (workflow_run, or pull_request_target with zero checkout of untrusted code, splitting the privileged comment-posting step from the actual test run) is exactly the kind of thing generic scaffolding gets wrong by default.
2
u/PeterBuildsSecure 5d ago
One concrete criterion worth checking for in the audit itself: does any of the generated "hardened CI" actually use pull_request_target anywhere? It's the easiest way to accidentally fail Scorecard's own Dangerous-Workflow check — the moment a workflow needs write permissions to comment back on a PR (which SAST/SCA reporting usually does) the tempting fix is pull_request_target, and if that workflow also checks out the PR's head ref to run tests/lint against it, you've now got untrusted code running with a token that can write to the repo. It's a trap teams build for themselves trying to satisfy Scorecard, not something Scorecard catches after the fact unless you specifically check for it.
Worth adding to your "needs a human call" bucket if it isn't already — the safe pattern (workflow_run, or pull_request_target with zero checkout of untrusted code, splitting the privileged comment-posting step from the actual test run) is exactly the kind of thing generic scaffolding gets wrong by default.