Product Security Has a Massive Data Problem

Originally posted on Medium: https://medium.com/@eric_sheridan/product-security-has-a-massive-data-problem-6c838c95d2c5 

Application, Product, and Cloud Security teams have a data problem that almost nobody is talking about. With the widespread adoption of cloud and cloud-native architectures, there has been a catastrophic increase in the speed at which software and infrastructure is deployed. Development teams have significant autonomy in choosing their tech stacks, increasing the fragmentation and technology sprawl. Think about all of the software assets these folks bear responsibility of when it comes to security:

• Source code repositories
• Programming languages and corresponding frameworks
• Build infrastructures and corresponding CI/CD pipelines
• 3rd party components and corresponding registries
• Container registries and orchestration platforms (often Kubernetes based)
• Infrastructure as Code (IaC)
• Cloud providers and corresponding services
• Backend-services such as databases
• Software Bill of Materials (SBOM)
• …and more.

That’s a ton of moving parts! The first challenge Application, Product, and Cloud Security leaders are facing is the discovery and enumeration of assets within their organization. In my experience, the amount of assets we think we have is far less than reality. Recently, I spoke with a Product Security leader at an industry leading CRM organization. Their teams were operating under the impression that the company had close to 3k source code repositories only to come to the stark realization they had nearly 5k – that’s almost 2,000 unknown repositories! That’s a lot of “stuff” to discover and help manage, right? Well, here comes the punch line – go and implement the strategic rollout of:

• Security testing technologies and services across all of these assets
• Triage and disseminate the results
• Fix the vulnerabilities,
• and do it quickly so you don’t get popped

Let me tell you…this, my friends, is an operational nightmare. Each assessment can bring with it tens, hundreds, or even thousands of vulnerabilities, meaning that Application and Product Security teams are left with hundreds of thousands, if not millions, of vulnerabilities to process. In fact, I recently spoke with a Product Security leader who shared with me that they had almost 2.5 million open vulnerabilities in their queue, of which more than 200k were deemed to have a “critical” severity – you know, the “drop everything that you’re doing and fix this now” severity. Let’s just assume for the sake of the article that these are all true positives for a moment, which is a massive can of worms in of itself. What vulnerabilities do you start with? Is this “critical” vulnerability more important than that “critical” vulnerability? Is the application or infrastructure associated with this “critical” vulnerability actually important to the business? And, assuming you make an educated guess as to the answers of these questions, how the heck do you disseminate the results and manage the workflows of each vulnerability to remediation? At the end of the day, if we’re not able to effectively act on the data we collect, then what was the value of collecting the data in the first place?

Product Security Teams Have Been Set Up for Failure

This is what I mean when I say Application, Product, and Cloud Security teams have a massive data problem. Attempting to tackle this and operationalize a solution inevitably leads to “Excel Hell” with people having to make instinctual, gut-based, and often reactionary decisions about risk. This situation cannot get better until we consciously choose the proverbial “red pill” that is radical acceptance; the awareness and realization of a truth that completely destroys the underlying foundation of a belief system. The cold hard truth here is that Application, Product, and Cloud Security teams have been set up for failure, and it’s not their fault. The reason we don’t hear about this is because the people facing this problem on a daily basis are too busy fighting the good fight!

Product Security Calls for Radical Change

With radical acceptance, and strong enough will, comes radical change. This is the sort of radical change Application, Product, and Cloud Security leaders are looking for from the industry, and we have a responsibility to deliver:

• Automate Asset Discovery: Tell me what assets I have, where they are, and how they’re all related. Provide me context – eg. is this repository even used anymore or is it business critical?
• Provide a Single Pane of Glass: Aggregate all of my security findings from my various tools and services into one location. I will always choose the best tool for the job – and they are not necessarily all from the same vendor.
• Normalized Vulnerability Model: Take all these security findings and normalize them into a standardized model that works for me with the context about my business. Just because you believe it’s “critical” does not necessarily mean we believe it’s a “critical”.
• Automate Remediation Workflows: Findings deemed actionable should be automatically disseminated for resolution within systems used by those fixing the issue. Don’t make me train another co-worker on how to use your website – please use theirs.
• Security Policy Enforcement: Allow me to express and enforce my business specific security policies within key points throughout the software development lifecycle. I’d like to try and prevent these vulnerabilities from getting introduced in the first place.
• Advanced Reporting with Context: Allow me to query, slice, dice, and report on the data in various ways so I can best communicate with my audience. Attempting to re-use the same report for my executives that I use for my engineers just does not work.

Accelerate Risk Remediation from Code to Cloud

Application, Product, and Cloud Security teams are in need of help identifying assets, assessing risk, measuring improvement, and articulating ROI in a way that scales with today’s cloud-native applications and infrastructure. It is with this realization that I picked my head up looking for like-minded individuals and discovered Tromzo, an organization uniquely positioned to solve this massive data problem from code to cloud with its Product Security Operating Platform. This is the only company in this industry with founders that personally experienced the massive data problem first hand, both at the CISO and Product Engineering levels. The combined experience of Security and Engineering is absolutely critical to succeeding here, and I’m certainly not the first one to have noticed this about Tromzo. Turns out 25+ other industry leading CISOs saw the same, and decided to back the company and its mission. It is for this reason that I have decided to support the mission and join the company as its Chief Innovation Officer. We are a team of folks that have collectively decided to roll up our sleeves and get to work helping all those great people living in Excel Hell struggling to streamline their operations. In fact, I feel I have a personal responsibility to do so. I’ve spent the last 13+ years of my career leading the development of automated security testing technologies specifically designed for DevSecOps – i.e., we found vulnerabilities fast. So in a sense, I helped create the problem, and now I need to help solve it. Scalability and operational efficiency are the keys to solving this, and Tromzo is best suited to make that happen. To the Application, Product, and Cloud Security teams out there…we hear you, and we’ve got your back.