TeamCity Security Review
TeamCity’s Pull Requests feature can be set to build everybody’s pull request, letting arbitrary code run on your build agents. We test agent authorisation, roles, secure parameters and deployment credentials. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
A TeamCity build agent’s state comes from three independent status pairs, connected, authorised and enabled, and it only runs builds when all three are set at once.
A TeamCity instance is only as locked down as the roles, agent authorisation and pull request settings your team configured
TeamCity’s own documentation on roles and permissions confirms that roles are assigned per project, so the same user can hold System Administrator rights in one project and no role at all in another, with a role also grantable to a whole user group at once. System Administrator carries every permission a Project Administrator has plus server-wide rights: creating and managing user accounts, authorising build agents, changing HTTPS settings and editing server-wide settings. We test which role each user and group actually holds in every project, not just in the ones the business remembers to check.
A build agent’s state is described by three independent status pairs, connected or disconnected, authorised or unauthorised, and enabled or disabled, and TeamCity documents that a brand-new agent stays unauthorised until a system administrator explicitly authorises it on the Agents page, even one installed on the same machine as the TeamCity server itself. An agent runs builds only when all three statuses line up at once, and one left disconnected for 14 days reverts to unauthorised and has to be trusted again before it can pick up work. We test which agents are actually authorised, whether any agent was authorised without review, and what an authorised agent can reach.
We review the roles, agent authorisation, secure parameters, pull request build settings and deployment credentials configured on your own TeamCity instance, the same way we review pipeline configuration on Jenkins rather than Jenkins itself. We never test TeamCity’s own codebase or attempt to find vulnerabilities in the underlying product.
SCOPE
What we review on a single TeamCity instance
Roles and Per-Project Permissions
TeamCity assigns roles to users on a per-project basis, so the same person can hold different roles, or no role at all, in different projects, and a role can also be granted to a whole user group so every member inherits it directly or through nested groups. System Administrator carries every permission a Project Administrator has, plus the ability to create and manage user accounts, authorise build agents, change HTTPS settings, edit server-wide settings and manage licences, while Project Administrator is limited to a project’s own settings and build configurations. We test which role every user and group actually holds in every project, and whether anyone holds System Administrator rights beyond the small group who genuinely need them.
Agent Authorisation and Trust
A build agent’s state combines three independent status pairs, connected, authorised and enabled, and TeamCity is explicit that a brand-new agent stays unauthorised until a system administrator authorises it on the Agents page, even one installed on the same machine as the TeamCity server; an agent disconnected for 14 days reverts to unauthorised and must be trusted again before it can accept work. An agent runs builds only when all three statuses are set together, so an unauthorised or disabled agent connected to the server cannot execute anything until someone deliberately changes that. We test which agents hold authorisation, whether that authorisation was ever reviewed, and what an authorised agent can reach on the network it runs on.
Agent Pools and Isolation
Agents can be organised into agent pools and assigned to specific projects, and TeamCity’s REST API and CLI expose the same connected, authorised and enabled statuses so a fleet can be audited for agents still waiting on authorisation after a mass deployment. An agent shared across multiple projects, or one left in the default pool available to every project, can run a build from a project it was never intended to serve. We test how agent pools are actually assigned, and whether a shared agent can be reached by a project it should be isolated from.
Secure and Password Parameters
TeamCity lets a parameter be created with the password type, both in the UI and via the REST API using a property with type rawValue=”password”, which masks the value in the build log and configuration UI rather than storing it in plain text alongside ordinary parameters. A secret stored as an ordinary text parameter instead of a password-type one is written to the build log and configuration exports in the clear the first time it is used. We test which parameters actually hold secrets, whether they are typed as password parameters, and whether a plain-text parameter has ever leaked a credential into a build log.
Builds from Pull and Merge Requests
The Pull Requests build feature integrates TeamCity with pull or merge requests on GitHub, Bitbucket, GitLab and Azure DevOps, and TeamCity’s own documentation warns that setting it to detect pull requests from Everybody, rather than only organisation members or members plus external collaborators, may allow arbitrary users to execute malicious code on your build agents; by default the feature also loads and builds draft pull requests unless that is explicitly disabled. Authenticating the feature with existing VCS root credentials or an OAuth connection’s access token means that same credential is exposed to whatever the pull request build actually runs. We test which trigger scope is configured for pull request builds, whether draft pull requests are excluded, and what a build triggered by an external pull request can actually reach.
Deployment Credentials and Connections
TeamCity connections store the credentials needed to reach external services such as cloud providers and VCS hosts, and for AWS specifically TeamCity documents that the Default Provider Chain credential type is disabled by default because, on a server hosted on an AWS instance with its own IAM role, enabling it would let any project administrator who configures that connection access every AWS resource the server’s role permits. A connection created once and reused across many build configurations extends that same blast radius to every pipeline that references it. We test which connections are configured, whether the AWS default credential chain has been deliberately enabled, and which projects and build configurations can actually use each connection.
Guest and Anonymous Access
Logging in as a guest user is disabled by default in TeamCity, and enabling it is a deliberate step on the Administration | Authentication page that also lets an administrator configure which roles and groups the guest account itself holds. A guest account left enabled with roles broader than a genuinely anonymous visitor needs exposes whatever those roles can reach to anyone who finds the login page. We test whether guest login is enabled, and what a guest session can actually see and do if it is.
Server Version and Update State
TeamCity’s own security notes recommend updating the server regularly to the latest released version, and document that TeamCity automatically downloads critical security updates in the background, though a system administrator still has to approve the installation before it takes effect, so a downloaded patch sitting unapproved provides no protection at all. Bugfix releases within the same major and minor version are documented as backwards compatible with straightforward rollback, which removes much of the reason to delay approving them. We check the installed server and agent versions against JetBrains’ own published update and security notes, and whether a downloaded security patch is still waiting for approval.
Server and API Exposure
The TeamCity REST API exposes the same agent, project and role data as the web UI, including endpoints that filter agents by their connected, authorised and enabled status, and TeamCity can open a debug terminal directly onto an agent’s machine from the UI, a feature it restricts to agents that are already authorised. How the server and its API are exposed, whether behind your own network controls or reachable directly from the internet, determines who can reach that authentication boundary and its authorised agents at all. We test how the server and REST API are actually exposed, and what an authenticated low-privilege session can reach through either.
TeamCity Cloud vs On-Premises
TeamCity Cloud is JetBrains’ own hosted offering, documented separately from the on-premises product, and moves responsibility for server infrastructure, availability and platform-level updates to JetBrains, while agent authorisation, roles, pull request trigger scope, secure parameters and connections remain configuration your own team sets regardless of which version you run. An on-premises instance carries full responsibility for its own server exposure, patching cadence and agent fleet, while a Cloud organisation still configures and is responsible for everything this page tests. We confirm which model your instance runs on before scoping the engagement.
OUR PROCESS
TeamCity Security Review: From Scope to Attestation
Scope and Access
We agree which TeamCity server, projects and build agents are in scope, plus at least one login for each role tier and a sample of any secure parameters in use.
Role and Agent Mapping
We map every project role, agent authorisation, pull request trigger setting and connection against the access it actually grants.
Manual Testing
A CREST-certified tester manually tests role boundaries, agent authorisation, secure parameter handling, pull request build exposure and deployment credentials, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST TeamCity pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent TeamCity Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test TeamCity For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From TeamCity Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our TeamCity instance?
We need at least one login for each distinct role in use, ideally a Project Viewer or Developer account rather than System Administrator, plus visibility of your build agent pools and any secure parameters in scope. Read access to your current roles and agent authorisation state speeds up scoping but isn’t needed to start.
Will testing touch our live data?
Testing focuses on roles, agent authorisation, secure parameters, pull request build settings and deployment credentials rather than the source code or artifacts your builds produce. Where proving a finding needs a test build configuration or a temporary agent, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this hosted on our infrastructure or JetBrains’?
TeamCity can run on-premises on your own servers and agents, or as TeamCity Cloud, JetBrains’ own hosted offering, and we confirm which model applies to your instance during scoping. Either way, the roles, agent authorisation, pull request settings and connections your team configured are what we test.
How long does a TeamCity security review take?
A single instance with a typical set of projects, agent pools and connections sits in our 2-day single-instance scope, with a report landing around 5 working days after kickoff. An instance running a large agent fleet, many pull request-triggered projects, or extensive cloud connections extends that scope.
What is out of scope for a single-instance review?
Testing TeamCity’s own source code or JetBrains’ hosting infrastructure behind TeamCity Cloud is not included, and we do not run denial-of-service testing against the server or its agents. A connected VCS or CI platform’s own security review, such as GitHub Actions or Jenkins, is scoped and quoted separately.
Do you need our source code or admin access?
No. We test with the role accounts and access you provide, and we do not need standing System Administrator access beyond what is needed to verify a specific finding during the engagement.
Does JetBrains have a policy on customer penetration testing?
On-premises TeamCity is software you run yourself, so there is no vendor notification process to follow before testing your own server, and a genuine vulnerability in TeamCity’s own code is reported through JetBrains’ published security channels instead. TeamCity Cloud is JetBrains’ own hosted platform, so we confirm JetBrains’ current customer security-testing terms for it during scoping.
Are your testers CREST certified?
Yes. Every TeamCity engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your TeamCity instance
TeamCity’s Pull Requests feature can be set to build everybody’s pull request, letting arbitrary code run on your build agents. We test agent authorisation, roles, secure parameters and deployment credentials. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
