Buildkite Hooks
You set up buildkite hooks by placing shell scripts into your agent or repo folders. The runner then executes these scripts at specific stages of every build job. Engineering teams use these scripts to load secrets, prepare tools, and clean up disks. Still, problems start when teams grant broad permissions to the runner host itself. Any script in the pipeline can then use those wide host roles without limits. How buildkite hooks run in your pipeline A build job moves through clear stages from
Git Hooks for Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up buildkite hooks by placing shell scripts into your agent or repo folders. The runner then executes these scripts at specific stages of every build job. Engineering teams use these scripts to load secrets, prepare tools, and clean up disks. Still, problems start when teams grant broad permissions to the runner host itself. Any script in the pipeline can then use those wide host roles without limits.
How buildkite hooks run in your pipeline
A build job moves through clear stages from start to finish on a host. At each stage, the runner checks for matching script names in specific locations. First, it looks for global scripts stored on the host machine itself. Next, it checks for local scripts stored inside the source code repo. Plugin scripts also run during these phases if the pipeline includes them.
Early stage scripts set up variables and fetch keys before the code downloads. Checkout scripts handle how the runner pulls code from your version control system. Pre-command scripts run right before your main test or build command starts. Post-command scripts run right after the main command finishes to gather logs or results. Finally, exit scripts run at the very end to wipe temporary files and folders.
The runner merges variables from each script into the active job session. If a script fails with a bad status code, the whole build job stops. This order gives platform teams a clear way to enforce setup rules on hosts.
Managing agent hooks versus repository hooks
Platform teams must decide where each script lives based on trust and risk. Scripts stored on the host machine stay under the control of the platform team. Developers who push code to a branch cannot edit those host files. Because of this, teams put sensitive secret loading logic inside host scripts. Those scripts read keys from a store and export them to the job.
Repo scripts live inside the code project alongside the app source files. Any developer with write rights to a branch can change a repo script. When a pull request triggers a build, the runner executes that modified script. This setup makes repo scripts great for fast test setup by app teams. Still, it also creates a big security risk if the host has wide roles.
Git Hooks for Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native hook controls solve and leave open
The runner gives you settings to block repo scripts on sensitive build hosts. Turning off repo scripts stops untrusted branch code from running during early phases. Host scripts also help teams keep secret fetching logic out of git repos. These native controls decide which script files are allowed to start on a machine.
Still, native controls leave a major gap once the build job is running. Once a script exports a database key or cloud role, any command can use it. The runner does not check individual queries or commands sent over the network. A bad script or flawed test can run destructive commands against live data. Native hook rules only govern script startup, not what queries or commands do in flight.
Teams also struggle to audit which person triggered a specific database query from a job. Shared runner identities make every action look the same in target system logs. Even if masking rewrites matched fields like emails, phone numbers, card numbers, or national IDs, you still need command-level checks.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
In what order do buildkite hooks run during a job?
The runner starts with environment setup, then moves to code checkout, and runs pre-command scripts. After the main build command finishes, it runs post-command scripts and final exit cleanup scripts.
Why should teams block repository hooks on shared agents?
Anyone who can open a pull request can edit scripts inside the code repo. Blocking those scripts on shared hosts stops untrusted code from stealing host keys or secrets.
How do variables pass from a hook to the build step?
Scripts run inside the job context and export variables to the runner environment. The runner captures those exported values and passes them to the main build command.