Secure your CircleCI surface
Context secrets available to jobs that should not see them, and orbs pulling unreviewed code into builds. We don’t connect to CircleCI 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 CircleCI goes wrong
CircleCI goes wrong through unrestricted contexts: secrets in an unrestricted context are available to every project in the organisation.
- Contexts without restriction, making their secrets available to every project in the organisation
- Orbs referenced at floating versions, changing build behaviour without review
- Project API tokens with scope beyond what the pipeline needs
- SSH access to build containers enabled for debugging and left on
- Forked pull request builds granted access to secrets
[02] What We Secure
What we watch, catch and fix on CircleCI
On CircleCI we review context restriction per context, since that is the main lateral path between projects here.
- Context restriction reviewed per context, since unrestricted contexts are the main lateral path here
- Orb version pinning tracked as supply chain control
- Token inventory with scope and rotation
- Debug SSH access monitored, because an open debug session is an open shell in your build environment
- Fork build secret exposure checked explicitly
[03] Where It Lands
Where CircleCI 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 CircleCI specifically
On CircleCI, we restrict contexts, pin orbs, and rotate over-scoped tokens. Reworking secret distribution across pipelines we plan with your engineers.
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] CircleCI FAQs
What CircleCI access does Konfirmity need?
Konfirmity needs a personal or project API token with read access to projects, contexts, pipelines and environment variable names. We read which contexts exist and how they are restricted, never the secret values themselves.
Do you check for debug SSH sessions left enabled?
Yes. Rerunning a job with SSH is a normal debugging step, but an open session is an interactive shell inside your build environment with access to whatever that job can reach. We surface sessions that have been left available.
GitHub
GitLab
Bitbucket
Jenkins
Snyk