Feature Request: Adopt Immutable Releases for Improved Supply Chain Security

Open
#239 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
github, github-actions, shell

Research direction

No files, tests, or entry points are named. Start by reading GitHub's immutable releases guidance and reviewing the repository's current release and distribution configuration. Done means defining and adopting an agreed immutable or append-only release process, with any selected signing, checksum, provenance, or SBOM requirements documented.

Written by the indexing model from the issue text.

Description

Hi Databricks Setup CLI maintainers 👋

I’d like to request that this repository consider adopting immutable releases as part of its release and distribution strategy, in line with GitHub’s supply chain security best practices.

GitHub documents immutable releases here:
👉 https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases

Why this matters
At the moment, releases (or release assets) can technically be modified or replaced after publication. While this may be convenient operationally, it introduces avoidable supply chain risk, especially for a security‑sensitive tool like setup-cli that is commonly used in automation, CI/CD pipelines, and privileged environments.
Immutable releases provide the following security and operational benefits:

  • Protection against release tampering
    Ensures binaries and artifacts cannot be altered post‑release, intentionally or accidentally.

  • Stronger auditability and provenance
    Consumers can trust that a given version tag always maps to the same bits.

  • Improved defense against supply‑chain attacks
    Aligns with modern best practices for secure software distribution.

  • Safer CI/CD consumption
    Downstream pipelines relying on release versions gain stronger guarantees.

Suggested approach
Some possible ways to implement this (one or more):

  • Publish releases as immutable GitHub releases, avoiding asset replacement or retagging
  • Treat releases as append‑only (new version instead of modifying an existing one)
  • Optionally combine with:
    • Signed release artifacts
    • Checksums (SHA256/SHA512)
    • Provenance metadata or SBOMs

Context
GitHub explicitly recommends immutable releases as a baseline supply chain security control, particularly for CLI tools and automation dependencies:
https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases
Adopting this would further strengthen the security posture of databricks/setup-cli and increase confidence for enterprise users.
Happy to help discuss or validate an approach if this is something the team is open to exploring. Thanks for considering!

Dominant language
Shell
Stars
29
Forks
19
Avg merge
3m
Merged PRs (30d)
6

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/setup-cli

All issues in databricks/setup-cli

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.