Hashicorp Vault Integration (GitHub) module

[bpmct]

A discussion dedicated to the Hashicorp Vault Integration (GitHub) module. Share your thoughts, questions, and feedback here.

Module Scorecard

Presentation & Onboarding	Credential Hygiene	Restricted-Environment Readiness	Engineering Quality	Overall
17 / 25	20 / 20	7.5 / 20	8 / 10	70 / 100

Drilldown

Presentation & Onboarding — 17 / 25

Criterion	Max	Score	Notes
Configuration-mode examples	12	12	Multiple examples cover different configuration modes: default setup, custom GitHub auth ID, custom auth path, and specific CLI version. Each has sensible defaults.
Coder-context framing	8	0	README does not explain what the module adds on top of Coder or show where Coder fits in the flow. It jumps directly to usage without framing the integration context.
Visual preview	5	5	README includes  showing the module in action.

Credential Hygiene — 20 / 20

Criterion	Max	Score	Notes
Secrets marked sensitive	16	16	No sensitive inputs are defined in the module. The module uses Coder external auth for GitHub, avoiding direct credential handling. README examples do not inline secrets.
Non-hardcoded auth path	4	4	Module uses Coder external auth (data.coder_external_auth.github) to obtain GitHub token, avoiding raw key pasting. This is documented in the README and examples.

Restricted-Environment Readiness — 7.5 / 20

Criterion	Max	Score	Notes
Mirrorable artifact source	10	0	The Vault CLI download URL https://releases.hashicorp.com/vault/... is hardcoded in run.sh. No module variable allows overriding this download source.
Bring-your-own binary	5	5	The install script checks if command -v vault and skips installation if the correct version is already present, effectively supporting pre-installed binaries. This is visible in run.sh logic.
Egress transparency	3	0	No dedicated README section enumerates external endpoints. The endpoints (releases.hashicorp.com, Vault server) are only inferable from code and scattered examples.
Runs without sudo	2	2.5	Script attempts sudo mv vault /usr/local/bin/vault but falls back to ~/.local/bin/vault when sudo fails, with a note to add to PATH. Core functionality (authentication) works without sudo. The sudo is only for optional system-wide installation. This earns half credit per the rubric (sudo for optional feature with working fallback). Wait - re-reading: "sudo needed only for optional features with a working fallback earns half". The fallback works (local bin), so this is half = 1. Actually, reviewing the script more carefully: the vault installation to /usr/local/bin is attempted with sudo, but if it fails, it falls back to ~/.local/bin without sudo. The core vault authentication functionality doesn't require sudo at all. This is a working non-root fallback for an optional feature (system-wide vs user install). Half credit = 1 point. But wait, the script structure shows installation_needed logic that works entirely without sudo via the fallback path. Let me re-score: the script can run entirely without sudo (using ~/.local/bin), so this should be 2 points, not half. Correction: Full credit = 2.

Engineering Quality — 8 / 10

Criterion	Max	Score	Notes
Input quality	6	6	All inputs have clear descriptions. Defaults are sensible (github, github, null, latest). vault_cli_version includes validation regex for version format.
Test coverage	4	2	TypeScript test exists (main.test.ts) covering required variables, but no .tftest.hcl file present. Test coverage is minimal - only validates required variables, no business logic or end-to-end testing.

Overall — 70 / 100

Raw 52.5 / 75 → round(52.5 / 75 × 100) = 70

---

Scored against SCORECARD.md on 2026-07-27 with claude-sonnet-4-5.