Git hook

A local script that Git runs automatically when a repository event occurs, such as commit, checkout, or merge. Hooks are legitimate automation features, but they become risky when attacker-controlled repository structures can cause them to run unexpectedly on a developer machine.

Expanded Definition

A Git hook is a local automation mechanism that Git triggers on repository events such as commit, merge, rebase, or checkout. In NHI and developer-security contexts, hooks matter because they can execute code on the workstation without a separate approval step, which makes them a powerful control surface for both productivity and abuse. Git hook behavior is documented in the Git hooks documentation, but operational practice varies widely across teams.

Definitions vary across vendors and platforms when hooks are bundled with developer tooling, IDE integrations, or repository templates, so the important distinction is not the file name alone but whether the hook can execute with the user’s trust and privileges. A safe hook policy treats repository content as untrusted until verified, especially where cloned code, submodules, or automation scripts can influence local execution. NHI teams should also consider how hook-driven workflows intersect with secret exposure, because developers often run hooks in environments that already contain tokens, certificates, or cached credentials. The most common misapplication is assuming hooks are harmless because they are “local,” which occurs when attacker-controlled repository content is allowed to supply executable hook logic.

Examples and Use Cases

Implementing Git hooks rigorously often introduces developer-friction and compatibility constraints, requiring organisations to weigh local automation speed against the risk of unreviewed code execution.

• Pre-commit hooks block commits that contain obvious secrets or policy violations, but only if the hook source itself is trusted and consistently distributed.
• Post-merge hooks can refresh generated files or run tests after branch changes, which helps workflow automation while expanding the attack surface on the developer machine.
• Repository templates that seed hook files can standardise quality checks, yet they also create a path for malicious defaults if template provenance is not controlled.
• In the CI/CD pipeline exploitation case study, attacker influence over automation demonstrates how trusted build logic can become a delivery mechanism for code execution.
• Git’s own guidance in the Git hooks documentation shows that hooks are expected extension points, which is exactly why governance must distinguish sanctioned automation from unexpected execution.

When linked with repository hygiene, hooks can support early detection of bad commits, credential leakage, and unsafe merge content. They are most useful when teams can prove the hook origin, review changes to hook logic, and prevent hooks from being silently introduced through cloned repositories or workspace setup scripts.

Why It Matters in NHI Security

Git hooks matter because they sit at the boundary between source control and local execution, where secrets, service account tokens, and developer privileges often coexist. If a hook can run unexpectedly, it can read environment variables, access cached credentials, exfiltrate API keys, or alter code before it reaches review. That turns a convenience feature into a non-human identity risk, because the hook may interact with the same secrets and automation paths that protect CI/CD and deployment workflows.

This is especially important given NHIMG research showing that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. The same conditions that create secret sprawl also make hook abuse more damaging, because the local workstation often becomes a bridge to more privileged systems. The Millions of Misconfigured Git Servers Leaking Secrets research underscores how repository misconfiguration can expose sensitive material at scale, while the Emerald Whale breach illustrates the broader consequences of automation abuse and exposed credentials. Organisations typically encounter the impact only after a workstation compromise, leaked secret, or unexpected repository behavior, at which point Git hook governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do secrets in Git history create long-term risk?
• What breaks when a secret is deleted from Git but not rotated?
• Why do Git-based secrets create lasting NHI risk?
• How should organisations respond when a secret appears in Git history?