operational guidance (Socket recommendations after the Ethersphere release-pipeline compromise, Nov 9)
Tip: make your publish workflow prove the released commit came from a protected branch; provenance and notarization will sign whatever CI builds
Inside the publishing workflow, check that the tagged commit is on the protected release branch or came from a merged release pull request, and fail otherwise.
Put the publish environment behind required reviewers and restrict which tags can deploy to it; use rulesets to limit who can create tags and releases.
Don't skip tests on the release path, and keep code-signing and notarization secrets away from manually dispatched workflows that accept a free-form branch input.
Treat a release-bot token as a publishing credential: scope it narrowly, rotate it, and alert on releases that bypass the normal release flow.