When we backed Aikido Security in September 2023, the application security market had a paradox at its centre. The tools available for developer security — SAST, DAST, SCA, container scanning, IaC security analysis — had never been more capable or more numerous. The gap was not in coverage; it was in signal quality. A development team running a standard CI/CD security scanning configuration in 2023 might receive hundreds of findings per week across their codebase. Triage fatigue is not just a SOC analyst problem; it is a developer problem. When a developer opens a pull request and sees a security scan result listing seventeen findings, twelve of which are in transitive dependencies they did not choose and cannot practically update without breaking their build, the cognitive response is to either fix the obvious critical items and merge anyway, or to progressively tune the scanner's noise floor to the point where it only fires on the most severe vulnerabilities — at which point it misses the medium-severity findings that, in combination, constitute real attack surface.
Aikido Security's founding insight was that the reachability problem — whether a vulnerability in a dependency is actually reachable through the application's execution paths — was the key to making developer security findings actionable. A vulnerability in a library function that is never called by the application's code is a theoretical risk, not an operational one. The standard SCA approach of flagging all vulnerabilities in all dependencies produces a findings list that includes both genuinely exploitable risks and phantom risks with the same severity classification. If you can determine, through static analysis of the application's call graph, which dependency vulnerabilities are on a reachable code path from an entry point, you can dramatically reduce the findings list to the subset that actually represents exploitable surface. The developer experience improvement this produces is measurable: fewer findings, higher signal-to-noise ratio, faster triage, more consistent remediation behaviour.
The broader philosophy behind Aikido's architecture resonates with something we have been arguing for several years: that application security tooling needs to be designed around developer cognitive models rather than security team audit requirements. A findings report formatted for a quarterly security audit is not useful to a developer making a merge decision in thirty seconds. An inline comment in the pull request interface that says "this call to deserialize() on line 47 is reachable from the /api/upload endpoint and the deserialization library version has a known RCE vulnerability — here is the patched version" is useful. The format, timing, and context of security feedback determines whether it changes behaviour. Tools that produce findings in a format and context that developers cannot immediately act on will not produce security improvements regardless of their technical accuracy.
We want to acknowledge a genuine tension in the developer security market. The shift-left narrative — the idea that finding security issues earlier in the development lifecycle is always better — is broadly correct but obscures a category of security risk that cannot be found at development time: runtime configuration errors, deployment environment misconfigurations, and emergent attack surface from the combination of independently secure components. A codebase that passes all static analysis checks can still deploy into a cloud environment with overpermissive IAM policies, expose an API endpoint without rate limiting, or use default credentials on a backing service. Developer security tooling that addresses the code-level risk without addressing the deployment and runtime risk provides incomplete coverage. The security companies we are most interested in are those that can bridge the code and runtime layers — not just scanning the repository, but understanding how the code behaves when deployed and what attack surface that deployment creates.
Aikido's roadmap through 2024 reflects this direction. The initial SAST/SCA capability — the pull request integration and reachability-filtered findings — was the wedge into developer workflow. The cloud misconfiguration scanning, container and Kubernetes security posture management, and exposure surface analysis that followed are addressing the deployment-time risk category. This is the right architectural direction for a developer security platform: own the developer's security workflow from commit through deployment, with a consistent findings interface that treats both code vulnerabilities and infrastructure misconfigurations as properties of the developer's end-to-end responsibility, not as separate domains owned by separate teams.