Security suggestion for trusted publishing in GitHub Actions

[HudsonGraeme]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Given the increase in supply chain related security incidents I'd like to flag this potential improvement to trusted publishing for the team's review.

At the moment, there is no hash of GitHub workflow contents provided through trusted publishing to downstream consumers like crates.io, pypi, npm etc. This creates a key gap where an attacker can publish a malicious release if they compromise git credentials of a maintainer and modify the actions workflow to disable safeguards.

This exact situation happened recently which allowed attackers to exfiltrate a significant amount of funds by exploiting workflow mutability in a popular cryptocurrency wallet framework bittensor-wallet.

The proposed solution for this is to have trusted publishing supply an additional metadata field to trusted publishing consumers containing a hash of the workflow body. This would then allow downstream package repositories to pin workflow hashes and reject publishing if the workflow is changed. The attacker would then need to compromise github and the package repository in order to disable the hash check and publish the binary, dramatically increasing the difficulty and likelihood of attack.

I've attached the issue I've opened on PyPI. The maintainer identified that it'd be tough for PyPI to fetch and hash the bodies of the workflows upon ingest and my reason for reaching out is to propose GitHub supplies this field as metadata to lighten the lift on package repositories.

pypi/warehouse#19702

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[armorer-labs]

Trusted publishing is exactly the kind of place where provenance needs to be stronger than simple success/failure of the workflow. At publication time, the important question is not only "did this job run?" but "what chain of review, code provenance, and execution context made this artifact eligible to become authoritative?"\n\nThat is why I like security features here that tie together:\n- what commit or PR lineage produced the artifact\n- what workflow / environment / approval boundary it crossed\n- what secrets or identities were reachable at publish time\n- what immutable evidence remains afterward\n\nIf those signals line up, trusted publishing becomes much easier to reason about during incident response too.