Strengthening Software Engineering Goals: The Call for Workflow Hashing in GitHub Actions Trusted Publishing

Enhancing Software Supply Chain Security with Workflow Hashing

Achieving robust software engineering goals increasingly demands a proactive approach to security, especially within the intricate web of modern software supply chains. A recent discussion on GitHub Community highlights a critical vulnerability in GitHub Actions' trusted publishing mechanism and proposes an elegant solution that could significantly bolster security for countless open-source projects and enterprises.

The Vulnerability: Workflow Mutability and Supply Chain Risk

The core issue, raised by HudsonGraeme in discussion #191125, revolves around the lack of workflow content hashing in GitHub Actions' trusted publishing. Currently, when a release is published via trusted publishing to downstream consumers like PyPI, npm, or crates.io, there's no cryptographic hash of the GitHub workflow itself included as metadata. This creates a significant security gap:

• Compromised Credentials: If an attacker gains access to a maintainer's Git credentials, they can modify the GitHub Actions workflow.
• Bypassing Safeguards: These modifications can disable security checks or inject malicious code into the build and release process.
• Malicious Releases: The attacker can then publish a compromised release, which downstream package repositories would accept as legitimate because the publishing mechanism itself is 'trusted'.

This isn't a theoretical threat. HudsonGraeme points to a recent incident involving the popular cryptocurrency wallet framework, bittensor-wallet, where attackers exploited workflow mutability to exfiltrate substantial funds. This incident underscores a critical gap in current security practices and highlights how easily a lapse can impact software project metrics related to reliability and user trust.

The Proposed Solution: GitHub-Provided Workflow Hashes

The proposed solution is straightforward yet powerful: GitHub should supply an additional metadata field to trusted publishing consumers containing a hash of the workflow body. Here's how this would work:

• Pinning Workflow Hashes: Downstream package repositories could then 'pin' the expected workflow hash for a project.
• Rejection of Altered Workflows: If an attacker modifies the workflow, the hash would change, and the package repository would automatically reject the publishing attempt.
• Increased Difficulty: An attacker would then need to compromise not only GitHub but also the package repository to disable the hash check and publish a malicious binary, dramatically increasing the difficulty and likelihood of detection.

HudsonGraeme's discussion with PyPI maintainers revealed that it would be challenging for PyPI to fetch and hash workflow bodies upon ingest. This reinforces the argument that GitHub, as the source of the workflow, is best positioned to provide this crucial metadata, lightening the lift on package repositories and ensuring broader adoption of this security measure. By integrating this feature, GitHub would empower developers to meet higher software engineering goals for security and integrity across the software supply chain.

Community Engagement and the Path Forward

The GitHub Actions team acknowledged the feedback, noting its value in shaping future product improvements. While there's no immediate commitment, the discussion highlights a vital area for improvement in developer tooling and supply chain security. As developers, contributing to such discussions is key to driving the evolution of platforms like GitHub, ensuring they continue to support robust software engineering goals and practices.