如何为Bitbucket/Git仓库配置特定文件访问权限以保护SDK代码安全

Great question—this is a common pain point for distributed teams managing sensitive SDK code, so let’s break down what’s possible and the best workarounds.

First, the Core Limitation: Git & Bitbucket Don’t Support Native Per-File Permissions #

Git itself is designed to manage entire repositories as a single unit—there’s no built-in way to restrict access to individual files at the Git level. This translates directly to Bitbucket (both Cloud and Server/Data Center):

• Bitbucket’s permission model works at the project, repository, or branch level, not for specific files.
• Even if you tweak settings, any user with read access to a repository can clone the entire repo and see all files.

Workarounds to Protect Your SDK’s Sensitive Code & Prevent Tampering #

Since direct per-file access isn’t an option, here are practical solutions tailored to your use case:

1. Split Your Repository into Private Submodules #

The cleanest approach is to separate sensitive files into a dedicated private repository, then link it to your main SDK repo using Git submodules.

• Grant access to the sensitive submodule only to your core team members, while giving the rest of your team access to the main SDK repo.
• To set this up:

  # Add the sensitive repo as a submodule in your main SDK repo
  git submodule add <private-sensitive-repo-url> ./path/to/sensitive-files
  

• Pros: Full permission separation, easy to manage access via Bitbucket’s repository-level settings.
• Cons: Requires some setup to ensure team members understand how submodules work.

2. Encrypt Sensitive Files with git-crypt #

If splitting repos isn’t feasible, encrypt your sensitive files directly in the repository so only authorized users can view or modify them.

• Use git-crypt, a tool that transparently encrypts files in your Git repo. Unauthorized users will only see encrypted blobs.
• Basic setup steps:
  1. Initialize git-crypt in your repo: git-crypt init
  2. Add a .gitattributes file to mark which files to encrypt:

     sensitive-file.js filter=git-crypt diff=git-crypt
     ./sensitive-dir/** filter=git-crypt diff=git-crypt
     

  3. Share the encryption key with authorized users (via a secure channel like Bitbucket’s secure file storage or a password manager).
• Pros: Keeps your repo structure intact, prevents unauthorized viewing/modification of sensitive content.
• Cons: Requires all authorized users to set up git-crypt locally.

3. Use Branch Permissions + Pre-Receive Hooks to Prevent Tampering #

To stop unauthorized changes to sensitive files (even if users can see them), combine Bitbucket’s branch protections with custom pre-receive hooks:

• Enable branch protection rules (e.g., require pull request reviews, block direct pushes to main branches) in Bitbucket.
• Create a pre-receive hook that checks if a push modifies sensitive files, and rejects the push unless the user is in an authorized group.
• Note: This works best for Bitbucket Server/Data Center (where you can host custom hooks); Bitbucket Cloud has limited hook support, but you can use Bitbucket Pipelines to enforce similar checks.

4. Distribute SDK Builds Instead of Raw Code #

If your team doesn’t need direct access to the source code (only the compiled SDK), skip repo access entirely:

• Use Bitbucket Pipelines to build your SDK automatically on every commit.
• Upload the compiled artifacts to a private storage location (like Bitbucket’s built-in artifact storage) and grant access only to authorized users.
• Pros: No need to manage repo permissions for non-core team members, full control over who gets the final SDK.
• Cons: Not ideal if your team needs to modify the SDK source code.

Bonus: Prevent Tampering Across the Board #

To add an extra layer of security against unauthorized changes:

• Enable GPG signature verification in Bitbucket to ensure all commits come from trusted users.
• Use Bitbucket’s audit logs to track who accessed or modified the repo.

内容的提问来源于stack exchange，提问作者Shadab K