TiDB Completes Independent Security Assessment by NCC Group

Key Takeaways

• NCC Group’s 45-day white-box assessment found zero critical, high, or medium severity issues across 20 repositories.
• All eight findings were rated Low, spanning default configuration hardening and dependency hygiene.
• TiDB integrated gosec into CI, updated dependencies, and NCC Group verified that mTLS and authentication controls work when configured.
• TiDB is working toward secure-by-default configurations for self-managed deployments.
• NCC Group’s initial assessment ran from June 2025 through September 2025
• NCC Group performed a retest in April 2026

When enterprises evaluate a distributed SQL database for production workloads, security isn’t a checkbox. It’s a prerequisite. Teams running financial transactions, customer data, and AI agent infrastructure need to know that the database they depend on holds up under independent scrutiny, not just internal testing.

That’s why TiDB engaged NCC Group, a global cybersecurity consultancy, to conduct a white-box security assessment of TiDB. The engagement covered source code review and dynamic testing across the full TiDB stack: TiDB, TiKV, TiFlash, PD, and supporting components. The result: Zero critical, high, or medium severity findings across 45 days of expert review.

This blog covers what was tested, what was found, what we fixed, and what we’re doing next.

What NCC Group Tested

NCC Group’s assessment ran from June 2025 through September 2025 against TiDB 8.5.2. TiDB provided full source code access, making this a white-box engagement rather than a black-box penetration test. One consultant worked across 45 person-days of effort, covering two testing methodologies:

• Source code review used static analysis tools followed by targeted manual review of security-critical areas across all major repositories, including TiDB, TiKV, TiFlash, PD, TiDB Dashboard, TiDB Operator, TiFlow, and supporting tooling.
• Dynamic testing evaluated the security posture of a live, multi-node TiDB deployment in a dedicated test environment.

The scope covered 20 repositories, the full distributed architecture, and the operational surface area that a real deployment exposes.

What the Assessment Found

Eight findings, all rated Low severity. The findings fell into two areas: Default configuration hardening and code-level hygiene.

The majority of findings related to TiDB’s default security posture for self-managed deployments. Out of the box, inter-component communication does not enforce TLS, and status, administrative, and diagnostic endpoints (including pprof and configuration APIs) do not require authentication. TiDB supports mutual TLS (mTLS) and caller-identity verification for all of these surfaces.

For production deployments, TiDB recommends enabling TLS for inter-component traffic and configuring mutual TLS with caller-identity verification, which requires these endpoints to present a trusted client certificate before granting access. Configuration guidance is documented in Enable TLS Between Components, specifically the “Verify component caller’s identity” section.

NCC Group’s retest confirmed that with these settings in place, the affected endpoints negotiate TLS 1.3 and reject unauthenticated clients.

The remaining findings were code-level: Two flagged known vulnerabilities in pinned Rust and Go dependencies where manual review confirmed no direct exploitation paths in the current codebase, and two identified gaps in static analysis tooling in the CI pipeline.

What TiDB Fixed

Following the initial assessment, NCC Group performed a retest in April 2026 against TiDB 8.5.6. The results:

• Fixed: Gosec linter integration. TiDB integrated the gosec linter directly into the TiDB CI pipeline. We resolved the unaddressed warnings NCC Group flagged in the initial assessment. The system now checks new code changes automatically. This was the clearest action item from the assessment, and we’ve done it.
• Partially fixed: Go dependency updates. TiDB updated pinned dependencies across the primary component repositories (ng-monitoring, tidb-dashboard, tidb-tools, tiflow, pd). Some instances remain in peripheral tooling, and remediation is ongoing.
• Verified: Security controls for production deployments. NCC Group retested TiDB’s security controls (mTLS enforcement, authenticated endpoints, TLS 1.3 negotiation) on a properly configured deployment and confirmed they work correctly. Because these controls are available, documented, and verified effective, NCC Group marked the default-configuration findings as Risk Accepted. This is a standard outcome for infrastructure software where deployment security is a shared responsibility between the vendor and the operator.

For TiDB Cloud customers, TiDB’s infrastructure team manages these configuration controls, so the default-configuration findings do not apply to managed deployments.

Why TiDB Invested in This Assessment

Most database vendors don’t publish independent security assessments. Internal security teams test their own code, fix what they find, and the outside world sees a changelog entry. That approach has limits: Internal teams know where they built the guardrails, and they unconsciously test around them.

TiDB commissioned this assessment because TiDB is the operational database for companies running financial services workloads, real-time AI agent infrastructure, and customer-facing applications where a security gap isn’t theoretical. Customers like Bolt, Manus, and Pinterest run TiDB in environments where independent validation matters more than marketing claims.

What Happens Next

The assessment produced two strategic recommendations that TiDB is acting on beyond the specific fixes already completed:

Secure defaults. NCC Group recommended that TiDB consider requiring users to opt into insecure configurations, rather than defaulting to them. TiDB is evaluating changes to the default TLS and authentication configuration for self-managed deployments to reduce the security surface area of out-of-the-box installations. TiDB will share specifics as that work matures.

Continuous dependency monitoring. With gosec now in CI, TiDB is extending the same discipline to govulncheck for Go dependencies and cargo-audit for Rust dependencies. The goal is automated, continuous tracking of known vulnerabilities so they surface in pull requests, not quarterly audits.

If your team is evaluating TiDB for a security-sensitive workload, check out the full NCC Group report to find out how TiDB meets your security requirements.