Our investment in Tromzo Security
If you could characterize modern application security teams in one word, it might be “overwhelmed.” Such teams are responsible for applying a wide array of tools and techniques to detect security flaws and vulnerabilities in applications. Unfortunately, if you talk to security engineers on these teams, there are a few things you will hear again and again — they are drowning in a sea of false positives and noisy results, they are desperately trying to prioritize thousands of vulnerabilities, and they spend a majority of their time manually triaging issues rather than doing strategic security work.
The driving force behind these problems is that the way we build and deploy applications has profoundly changed over the past decade. DevOps as a cultural concept has exploded, centered around the idea that engineering teams should push smaller builds, more often, in a more self-service way. Tooling that assists with this has grown dramatically as everyone chases continuous integration and continuous deployment to ultimately achieve greater velocity in product development. Coupled with this, the adoption of the cloud and cloud-native technology stacks has deeply altered the way that infrastructure is managed. Infrastructure provisioning is much more self-service versus centrally managed; microservices have led to increased heterogeneity in languages and frameworks relative to traditional monolithic architectures; and infrastructure is highly ephemeral, regularly being spun up and spun down, rather than fixed.
A number of tools have recently branded themselves under the “DevSecOps” banner in an effort to address the complexity caused by these changes. Such tools are typically built under the design assumption that the only way to scale application security in the context of DevOps culture and modern system architectures is to integrate application security tooling natively into the CICD pipeline. Inherent in this assumption is the concept that engineering and DevOps teams must become core stakeholders in security. In other words — security needs to “shift left” in the software development lifecycle. Snyk, StackHawk, DeepSource, BridgeCrew, R2C, Fossa, and Accurics are but a few examples of recent startups built around these concepts.
Unfortunately, while these tools are fantastic in many ways, they do not quite solve the problem on their own. This first wave of DevSecOps companies are primarily focused on the detection of issues, but detection alone is insufficient. In fact, many security engineers will tell you that more detection is actually the last thing they need — most companies have a backlog of hundreds to thousands of “detected” vulnerabilities. The bigger issue is — how do you know what to fix?
Application security is characterized by lots of invalid vulnerabilities, irrelevant results, and general noise, primarily because it is actually quite difficult to automate the analysis of security flaws. As a simple example, many security teams get frustrated with the fact that Snyk will send alerts for vulnerable third party libraries in your codebase even if your application never accesses the vulnerable portion of that library.
Because so many results are not actionable, the concept of “DevSecOps” often falls flat — it is untenable for security teams to offload all detected vulnerabilities to engineers because such alerts are not actionable without triage and prioritization. Security teams who try often end up facing the wrath of engineers who receive a list of hundreds to thousands of “critical” vulnerabilities, many of which have likely been in the application for years.
Furthermore, modern environments often lead to an even more foundational question — what scanners and tools should even be running? The increased heterogeneity of languages and frameworks used in most companies, coupled with the dynamic nature of these environments and the self-service deployment of new infrastructure, means that most security teams barely know what scanners to run or which scanners are live in their environment. It doesn’t matter if there are great scanners for a given language, if I have no idea whether my environment includes that language.
These issues leave most companies, even with modern “DevSecOps” tools, in the following situation with respect to application security:
Interestingly, a few large companies with sophisticated security teams have made some inroads on solving these issues, such as Coinbase, DOW Jones, Salesforce, Twitter, and Volterra. The common pattern across these tools is the creation of a central application security orchestration layer which helps automate the triage and prioritization of vulnerabilities.
We were lucky enough to meet Harshil Parikh after he went through this exact same journey as the CISO of Medallia, initially struggling with application security and eventually building out a similar solution of his own. He had partnered Harshit Chitalia, who had seen the same problems from the engineer’s perspective at Juniper Networks. The two of them realized that while these application security problems were fairly universal, few companies had the resources to build the right solution in-house. Furthermore, they realized that there was an immense opportunity to build a dramatically better product in this space that went far beyond what the companies listed above had built. Specifically, by first building a rich asset map of the entire cloud environment — from code, to CICD, to production infrastructure, to organizational structure — you could build much more intelligent application security automations. As a simple example, you may want to ignore vulnerabilities of a certain class which are deployed in a way that makes them inaccessible to outsiders.
The more time we spent with Harshit and Harshil, the more we were convinced that this tool would represent the foundation of any modern application security program. For this reason, we couldn’t be more excited to announce that we are leading the seed round in Tromzo as well as the company’s launch from stealth. Joining us in the round are the Silicon Valley CISO group, the largest angel syndicate of CISOs; Operator Partners, and a wide array of notable security leaders including Adam Shostack, Jack Naglieri, and Zane Lackey.
Harshil and Harshit represent the perfect founding team to start a company like this given not only their direct personal experience building solutions in this space, but also due to having direct empathy for both the engineering persona as well as the security persona, both of whom are critical to scaling security in modern environments. Harshit’s background leading the engineering team at a data infrastructure startup also provides the foundation for Tromzo, which at its core is a data company.
We believe this “data first” approach to application security management is the key missing piece in the modern DevSecOps stack. The only way to have engineers and DevOps be stakeholders in security is to have relevant, actionable, and understandable results that a developer can act on. The hard part isn’t running a scanner on commit or pull request — it is having the appropriate context, governance, and policy layers to properly triage, contextualize, and route vulnerabilities in an automated fashion.
Tromzo is already being used by an array of leading companies such as NextRoll and Acoustic. If you’re overwhelmed with your application security program, we recommend you check them out.
