The relationship between code quality and security is not analogous — it is constitutive. The security properties of a piece of software are a subset of its quality properties. A function with a buffer overflow vulnerability is not high-quality code with a security defect; it is code that fails to correctly handle the bounds of its input domain, which is a quality failure. SQL injection vulnerabilities arise from code that conflates data and control flow — a structural quality problem. Insecure deserialization patterns exist in codebases where type safety and input validation discipline have been allowed to erode. When we backed Sonar in 2021, the investment thesis started from this observation: the companies building code quality analysis infrastructure at the level of structural code properties — not just CVE matching in dependencies — were building security infrastructure whether they framed it that way or not.
SonarSource's static analysis approach operates on the principle that code quality rules and security rules are not separate categories to be analysed by separate tools. A rule that flags complex, deeply nested conditional logic is a maintainability rule that also reduces the probability of logic errors that could be exploited. A rule that enforces consistent error handling patterns prevents the kind of partial failure states that can create security-relevant inconsistencies in application state. The taint analysis capabilities in SonarQube — tracking the flow of untrusted data through an application to identify points where it is used in security-sensitive operations without appropriate sanitisation — are an extension of the same static analysis foundation used for quality rules, not a separate security scanning engine bolted on. This architectural integration is significant: it means that the security findings are produced by the same analysis pass that produces quality findings, in the same IDE and CI/CD integration, with consistent severity framing.
The developer adoption evidence for this integrated approach is meaningful. SonarQube's prevalence in development pipelines across European enterprises — particularly in the financial services and telecommunications sectors that have large internal development teams — reflects a buyer dynamic that is different from standalone security scanning tools. Quality tooling is adopted because development teams want it; security tooling is adopted because security teams require it. When quality and security analysis are integrated in a single platform, the adoption driver is the quality use case, and the security coverage comes along. This creates a different product motion than security-first tools that need to overcome developer resistance — the developer is already in the tool, already acting on findings, and the security findings surface naturally in the same workflow.
We should acknowledge the boundaries of what static analysis can and cannot detect. SonarQube and similar static analysis platforms excel at finding code-level vulnerabilities that manifest in structural patterns: injection vulnerabilities, path traversal, insecure cryptographic implementations, hardcoded credentials, known-dangerous API usage patterns. They are structurally unable to find vulnerabilities that emerge from runtime behaviour, configuration, or the interaction between independently secure components. A correctly implemented authentication function that is called by the wrong code path at runtime — accessible through an unintended execution path — will not appear as a static analysis finding because the code itself is correct. Runtime application self-protection (RASP) and runtime security monitoring address this complementary category, and the most effective application security programmes use both.
From a portfolio construction perspective, our investment in Sonar reflects a conviction that code quality analysis has a durable business model that security-first application scanning tools sometimes lack. The procurement motion for code quality tooling goes through the engineering organisation, not the security organisation. Engineering leaders understand the maintenance cost reduction, onboarding efficiency, and technical debt management value of continuous quality analysis — these are arguments that appear directly in engineering budget conversations. The security value is a secondary benefit that strengthens the business case without being the primary justification. This dual-value structure, where the security benefit is real and meaningful but the engineering productivity benefit is sufficient on its own, creates a more resilient go-to-market than products that must justify their entire cost on security outcomes alone.