Secure your Buildkite surface
Self-hosted agents with production access, and pipeline permissions wider than the teams using them. We don’t connect to Buildkite to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Buildkite goes wrong
Buildkite goes wrong at the agent: agents are yours to run, and they usually hold broader cloud credentials than any single pipeline needs.
- Agents running with cloud credentials broader than any single pipeline requires
- Agent queues shared between trusted and untrusted pipelines
- Pipeline edit permissions granted organisation-wide
- Secrets exposed to builds triggered from forks
- Agents running on long-lived hosts accumulating state between builds
[02] What We Secure
What we watch, catch and fix on Buildkite
On Buildkite we review agent credential scope per queue, since the agent is where the real access lives in this model.
- Agent credential scope reviewed per queue, since the agent is where real access lives in this model
- Queue separation audited as a trust boundary
- Pipeline permissions reconciled against team ownership
- Fork build behaviour checked for secret exposure
- Agent host ephemerality assessed, because persistent agents leak state between builds
[03] Where It Lands
Where Buildkite lands in your registers
Repositories and pipelines become asset register entries with their own criticality, because a build system that can deploy to production is a production system. Access reviews cover repository and pipeline permissions alongside your other entitlements, and the risk register carries supply chain exposure — the dependencies you pull, the actions you run, and who can push without review.
[04] How We Engage
On Buildkite specifically
On Buildkite, we separate queues, tighten agent credentials, and correct pipeline permissions. Migrating to ephemeral agents we plan and drive with your platform team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Buildkite FAQs
What Buildkite access does Konfirmity need?
Konfirmity needs an API access token with read scopes for organisations, pipelines, agents and builds. Because agents run in your infrastructure, we also assess their host configuration and IAM role as part of the same review.
Why do you care about agent queue separation?
Because queues are a trust boundary. If a queue serving untrusted or fork pipelines shares agents with one that can deploy to production, a low-trust build gains access to high-trust credentials. Separating queues contains that.
GitHub
GitLab
Bitbucket
Jenkins
CircleCI