EP 24 — Innovating Application Security with Industry Expert Eric Sheridan

Harshil: Hello everyone. Welcome back to another episode of the Future of Application. Security. Today I have a very very special guest with me, Eric Sheridan. Now, this is a little bit of a different episode. It's not the standard format we use for inviting guests from other companies. Eric actually is our latest team member at Tromzo. He joined us about two weeks ago as our Chief Innovation Officer. Eric, welcome to the show.

Eric: Hey, thanks for having me. Pleasure to be here.

Harshil: Eric, I would love for you to just briefly introduce yourself to the audience. Before joining Tromzo, what did you do, where you came from, how you started your career in the world of security, and give the audience an overview of what you're all about.

Eric: Yeah. So hey, pleasure to meet you all, my name is Eric Sheridan, as you know. It's funny what got me into security. I’ll actually tell you a brief story. So I got into security in my teenage years. Back then everybody got online with a very old dial up modem and you got online through the CD that was sent to you by AOL. It was basically spam. So I was a big AOL user back in like AOL 3.0 days. And so I got on a chat group one day, I was probably mouthing off because I was a teenager, and I had somebody say something to the effect of “Stop or I'm going to kick you out”. And of course, me being me, I was like, “Well I'm not going to stop”. And then a few moments later, my computer completely froze and crashed. I had two thoughts go through my head. The first one was, “Well that's not good, my parents just bought this, how do I fix this?” And the second thing, it was like, “That's really cool, I want to be able to do that”. And so it took many years for me to actually figure out what they were doing, but they were actually using a tool called Punters. At the end of day, it was like a buffer overflow. You saw like a really long message through a chat message. The recipient would get it, they would try to display it and AOL would just completely freeze and crash. And so back then it seemed like if a single process crashed in Windows, all of it was just frozen. So this is a tool that allowed you to basically kick anybody off the internet and crash their computer. So I actually got into security out of a complete power trip as a teenager, but over the years I’ve matured a bit. So I've been working in security and application security and product security for almost 20 years now. I spent the last 13 to 15 specializing in creating technologies designed to perform security testing against software and applications that people write and deploy. And it's been a very interesting experience for me. And as a result, I'm proud to say I helped create numerous products that came to market, including several at White Hat Security, which was then acquired as a part of NTT. This is the NTT heading up all of the innovations within that organization. And yeah, so great experience building a lot of tools, finding a lot of vulnerabilities, producing a lot of data. So good stuff.

Harshil: That's such an amazing story. I remember seeing those things as well back in the day on AOL Messengers, and I believe some of those also used to happen on Yahoo Messenger back in the day. It's phenomenal. So Eric, you got into security and you mentioned you were building some of these technologies at White Hat Security and things like that. Tell me more about that. What was your product? What would the product do?

Eric: Yeah, so actually in 2011, I actually co-founded a company whose mission was set out to do static analysis. And so this is a technology often referred to as static application security testing or SAST, where it would actually consume source code and scan it for patterns indicative of vulnerability. I set out I built this technology within like, I kid you not, like maybe three months, White Hat Security got wind of it and I was a part of an acquisition. So they actually brought the technology in house. And so then I actually had the opportunity to take that technology, turn it into a product that was designed specifically to be consumed by security teams with results immediately disseminated to developers. So one of the big things at the time was how do you scan source code that resides with on prem. Because not everybody was using cloud at the time. So the big advancement, there was a performance benefit on how we built it. But operationally, getting something in a customer's environment that could scan the code and only send out the snippets that were needed to verify the vulnerability was a big thing. From there, the big things throughout the past decade were built like an AppSec platform. So I expanded upon that to build out software composition analysis technologies. You know, things would actually look at third party components that are being used, tell you which licenses they're using, which ones have vulnerabilities. I built out a technology that would automatically generate actions for source code vulnerabilities. So if we found a SQL injection vulnerability in your app, we would then say, “Hey, look, here's a real time generated patch of this file that if you apply it will fix the vulnerability”. So I built several advancements around SAST and then my most recent was around DAST, Dynamic Application Security Testing. So this is a technology that is designed to send attacks at runtime against your app and then based on how it responds and behaves, will indicate whether or not it's in fact vulnerable. And what was interesting about this is I worked at an organization whose bread and butter was really DAST and the question was how do you take that and make that work in today's world, which is DevSec ops, which basically means code is being written fast, it's being deployed fast. So how do you test it fast and how do you make it work within the build pipeline? So I had a chance to do some pretty cool stuff there, and so from my end, it was a really great experience to understand both what are the challenges that development of product teams face when it comes to onboarding security technologies, how you go about disseminating results, and a great opportunity to figure out how are developers viewing security, how they view the results, and how do you make them more efficient in a world where they have significant amount of pressure to push and release fast. So those are the big ones. Along the way there were a few, like IAST and RASP technologies that never made it or got very far past the R&D phase. But at the end of the day, I kind of take a little bit of all the acronyms, if you will.

Harshil: Right, right. So this is amazing because you've spent so much time in all of these different tooling that have become the table stakes for every security team, right? Almost everyone has some SAST, DAST, SEA, things like that. Now that is becoming very very commonplace, which is not the thing ten years ago, but also the world around us, the way software is being built and developed, the technology is being used, the architecture, all of that has also changed over a period of time, right? So thirteen years ago when you started building that static analysis tool, the processes and the systems and the technologies for software development were different than what we have today. Do you have any insights or thoughts about what has changed and how is it affecting our appsc world?

Eric: Yeah, absolutely. So I will admit one of my strengths, which is also one of my greatest weaknesses, is I can work with the blinders on and stay focused on a key problem and that means I can solve the problem but at the same time, sometimes I forget to pick my head up. So I recently picked my head up just a crack trying to get a purview of like what is the world, what are we dealing with today. And it kind of struck me when I said it out loud to myself. All of the different technologies and environments that development teams are using to build and deploy products. You know, things like source code repositories, infrastructure code, you have cloud native environments, hybrid cloud environments, you have a requirement to generate software bill of materials, multiple back end systems databases, various registries both for containers and third party components, issues with what are those sort of things that are resolved, microservices architectures, distributed architectures as opposed to monoliths. It's all these things I've worked on sort of in isolation to help provide security testing in isolation. But when you look at the whole picture, that's a lot to manage. I had a conversation with someone recently and they said “We think we have close to about 3,000 source code repositories that we, the product security team, have to maintain”. And when they actually got in there, did the work, the answer was closer to 5,000. So that's a lot of stuff to maintain. So while these technologies like infrastructure code, microservices and all this stuff have added a lot of benefits, they've also introduced a significant amount of complexity with respect to operationalizing a lot of security capabilities. And unfortunately, what I'm seeing is that security always lags behind engineering in terms of maturity. And honestly, that's kind of just the reality of the situation, and the way it's going to be, right? The software engineering organization is going to drive, security is going to come back because at the end of the day, security needs to help the software engineering be successful. So software engineering is leading, security is catching up and it's been catching up thus far from the perspective of, okay, if they're moving faster, how do we get the results faster? So security tooling and testing has been trying to produce results at a faster rate in various different environments. I'm one of those folks who is focused on that and talking about that and unbeknownst to me, I'm kind of contributing to this problem. There's this big data problem where you have these product security teams having just massive amounts of vulnerability data coming at them at an exponentially greater volume and rate from all these disparate tools. Because let's be honest, there's no one platform that's great at everything. The product security teams are going to pick the best thing for the job. So there's all these different technologies. And so the question is, okay, how do you pull this stuff together? How do you make that available to development teams? How do you track that to completion across this very diverse product stack with development teams that have a high attrition rate and or just rotate across technologies quickly? It was an operational nightmare. I kind of sat back, my jaw dropped. If I had hair, it would have fallen out at the size of the problem that we have here. And as a part of picking my head up, I asked myself, is anybody else seeing this problem? And so I was grateful to come across yourself and what Tromzo is doing, because at the end of the day, I think this big data, massive data problem that product teams are dealing with has to be operationalized better. Otherwise we're going to be pushing software to production at a faster rate with a greater number of vulnerabilities than we ever have before.

Harshil: Yeah, no, that's a fantastic insight and I can correlate that with my personal experience as well, right? In one of my previous jobs, we had a pretty solid AppSec team and we felt very proud of the security and SDLC that we had built in, right? We had a lot of controls and checkpoints and architecture review, threat modeling, all those kinds of things we would do would run a number of tools, but every month or so we would discover new services in production, right? And we would ask that question every time to ourselves. How did that happen? How did this thing miss every single control? We spent two years building our software security program. How do we just completely miss this thing and it's already in production and the customer found it out during one of their pen tests, which is a total failure, right? As a security team, I would want us to find those things out first, manage the risk and effectively bring this under control, right? But every once in a while we would have those issues and that is what triggered the thought process that you know what, it is really hard for us to maintain this visibility and control when you are a central small security team and there's hundreds of thousands of developers just doing their job, which is pushing features every single day, deploying new things every single day. And sort of correlated to that is the adoption of a lot of the third party source code and containers and images coming from different places, which we've focused on these topics as a security industry. In the context of oh, we need to find these problems, right? We need to find more vulnerabilities in these dependencies, we need to find the dependencies that are potentially infected and are not safe to use. The entirety of the conversation has been around finding more problems, but the result of that is because now developers are writing less code and using more of the open source dependencies and libraries, just the volume of code has increased. And then add to that all of the SCA scanning, container scanning systems that all of the security teams have deployed. So effectively you end up finding many problems in this larger volume of code that the developers don't even own, but it gets inherited in some or the other way. The end result that most people are not thinking or talking about is that you get this massive volume of issues but you don't even know if those dependencies are relevant, if that function is being used, if this is intentional, or if it's not intentional, does this even present a risk to your business? So the very early stage of security's response to this shift towards microservices architecture, agile device movement is to find more problems, right? I think we’ve sort of come to a stable, steady state in finding those problems because now everyone knows how to find those problems, but now is the time when people are starting to think about, okay, we found all these problems, what do you do with this now, right? How do you bring this under control? How do you manage it? So, as you said, it has become a massive data problem. And this data does not have any context and it's really hard to make sense of it.

Eric: Yeah, I like how you phrase it. We've gotten really good at finding problems at some point here we need to get really good at finding solutions. And with that myopic focus on generating more vulnerabilities, we forget very basic fundamental operational questions that need to be answered. So if you're sitting with a vulnerability backlog of like 280+ thousand critical vulnerabilities, and you open one up and you look at it and you're on the product security team, your next question is, “Okay, who do I go to about getting this fixed? Who wrote this piece of code? Who deployed this asset? Who wrote and deployed this container?” That's a very simple question that we should be able to answer, but as an industry, and I'm, including myself when I say this, as an industry, have failed. We have failed to be able to support and answer that stuff. So, honestly, I think when it's all said and done, the cold hard truth is that product security teams have been set up for failure and it's not their fault. And at the end of the day, rather than pointing fingers, personally, I'm going to say, “Hey, look, I contributed to the problem because I generated a lot of those results. Now I want to contribute to the solution, which is how do we most efficiently act on and operationalize all this disparate data?”.

Harshil: Yeah. And it became very real. And I'll bring up one of the most well understood recent issues around Log4J. When Log4J hit, everyone knew we had to pass these things, we had to fix it, right? Now I talked to a lot of people who are running initiatives to mitigate this concern. Almost every single security team that I talked to, what they did was they had many many different sources of information. They would have some cloud security solution, CSPM solutions that would say, “Here are all the things that need to be fixed in your cloud environment”. Then you would have a container scanner that would be looking into the registry, flagging all the containers that would need to be patched. And then you would have an SCA tool that's looking at your code repo saying, “Here are all the code repos that need to be patched”. So practically what happened was every single team that I know of, they downloaded all those results or created a Google Sheet or an Excel Sheet with multiple tabs. “Here are all the issues from SEA, here are all the issues from container scans, here are all the issues from our cloud security solution”, and then share it with the rest of the engineering organization or the technology organization and ask people to fill in who owns what. What is important, what is not important, right? So this became a massive project management exercise rather than a pure technical fix, right? So it's a nightmare situation. You have Google Sheets, multiple versions of Google Sheets with many tabs, with hundreds of thousands of line items just to figure out who owns these things and what is the solution that needs to be implemented. So it's a massive nightmare because you don't know who owns it, you don't know what is actually important to your business, what needs to be patched first out of thousands of items. You can't fix everything, yeah? You have to go sequentially, figure out what the crown jewels are and fix those things. So that's how the problem manifests itself.

Eric: And it’s funny you talked about using spreadsheets. So Log4J was, what, like late 2021 into 2022? Even in that day and age, with all this talk about platforms and all these and so forth, that vendors, security testing vendors have talked about where you can use this one place, how operationally we're still exporting all that data into a spreadsheet and normalizing it. And so at some point here, we want to help those teams get out of that Excel hell, if you will, and onto something that's a little more efficient. So I appreciate you sharing that. The Log4J one was interesting because it affected Minecraft. I don't know if you happen to be a Minecraft player, but I've got kids who play Minecraft, so I learned how to do it too, and it was terrible. Not the game, like the vulnerability. So if you logged into a server with a vulnerable client, anybody could just post a message in chat and instantly anybody who had an outdated version of that library, their whole machine was immediately coded and exploited. So it's crazy this sort of stuff comes up and while it's a challenge, this Excel hell that we talked about, it's a great opportunity and a great problem to solve. And that's probably the biggest reason why I decided to join Tromzo. Because the way you're all kind of positioning it, I can now say the way we're positioning it, the way we as a company are positioning it is unique. And for you, having boots on the ground experience with that problem honestly is going to put the whole company in a better position on how to solve it, because you cannot solve problems efficiently that you have not experienced personally. And as a leader of a company knowing you experience it personally makes me feel confident about the direction that we're going.

Harshil: Yeah. So I have my own hypothesis on how to solve the problem but I'd love to hear your thought process of what a good solution looks like in this kind of a scenario.

Eric: Sure. So there's a number of things that I would look for out of a solution. Earlier we talked about applications being deployed that we didn't know about ,or what are the assets that are actually in my organization. So, like, we had a customer that thought that maybe they had 2000 repos when in fact they had closer to four or five. Being able to automatically discover that stuff and communicate that with a single pane of glass is absolutely critical. The next thing I want to look for is like, you have all these disparate tools with the disparate data and the formats all that stuff needs to be normalized. We need something that can pull in all this information from different sources, normalize it into a common model that product security teams can work with, that works best with them. Because it's interesting, you go to any organization and the terminology for severity vulnerabilities can change, right? Sometimes it's “P zero”, sometimes it's “critical", sometimes it's just a number, like a CVSS number. And being able to normalize that and allow the product team to configure it for their needs is absolutely critical. The next thing I'm looking for is actually the ability to automate their mediation workflows. If you're ingesting and providing a single pane of glass to, in some cases literally millions of vulnerabilities, operationally, how do you disseminate that, each of those findings and track them to conclusion? Like, I want a platform that can make that painless and easy. At a click of a button, it's integrated, we can track it, everything synchronized to completion. And a key piece of that is making sure that whatever that technology or platform is, that it works for technologies that product engineering teams are already using today. The last thing I want to do is to have the engineer learn how to use someone else's website to be able to ingest this stuff, right? Because that's a painful process. I experienced that personally in my career, so I'm not having any more of that. Another key thing I'm looking for is like, automated policy enforcement. Once you have all these results come in, you have these connectivity to the various disparate systems to discover assets, then you should be able to enforce some policy right out of the gate within your source code repositories within your CI CD pipelines of registries. At the end of the day, with all of this context about your environment in a single pane of glass, I'm expecting that we'll enable product security teams and AppSec teams to be able to make more efficient decisions about risk, more informed decisions about risk in a way that they've never been able to before. Thus far, they've only gotten like a picture or a single perspective. This is going to be a unified holistic view of what risk they're really dealing with. And I want a platform that can help them slice and dice the data in a way that allows them to generate reports and views that most effectively communicates with their audience. Some days, product security teams are speaking to an engineer who loves to talk about infrastructure as code. And the other day they're talking to an executive at sea level who just wants to know, are we there yet, what's the budget, and these sorts of things. At the end of the day, it's a big ask. With that said, if it were easy, it wouldn't be worth doing. It's our problem, but it's a good problem to solve, right?

Harshil: Yeah. I think you're also in the same direction as how I've been thinking about this problem, which is to effectively solve software security, cloud security, we have to democratize security. It cannot be just the ownership and within the realms of the security team, how do you democratize it if they don't come to security, you take security to them, right? You have the right level of information, actionable insights into the developers, workflows into the systems where leadership teams live or where decision makers make their decisions on. And that makes it easy for them to understand what the risk is, understand how to mitigate that, and take the actions to actually do that. Because let's be honest, at the end of the day, security teams can only identify the risk and potentially highlight it to people who actually need to go and remediate it. Rarely can security people remediate things themselves. So helping the owners of the risk understand why that is important and why they need to take action and what action they need to take, it's incredibly important to actually drive to the end goal, which is remediation of that risk. No longer can we just stop at flagging the risk because nobody else has time to spend hours and hours on learning new security related things. How do we make it easy for them? How do we do a lot of the pre-work in flagging only the things that are actually relevant?

Eric: Yeah, I mean, at the end of the day, if you as an organization are not able to act on the data that you've collected, what is the value of the data in the first place?

Harshil: Right, right. Well, this is great. And also I think there is a lot of momentum behind this democratization of security in a way, because what we can also see is a lot of the non-traditional security tooling platforms, companies, they're also getting into security. I get very excited when dev tools and dev platforms like GitHub, Gitlab, JFrog Datadog, all of those companies start delivering security products because then we know that security will sort of become part and parcel of the broader dev platforms that are used by developers on a day to day basis, which potentially will also shift the nature of what we do as security professionals, right? Like we're not going to be busy clicking buttons and scanning things and generating PDF reports, which is what used to happen ten years ago. So what does the role of a good AppSec engineer look like in the future? I'm curious if you have any thoughts on how the role of the team or an individual within the team has changed from ten years ago to now.

Eric: Yeah, there's a lot of developer oriented products and technology stacks of incorporating security capabilities, which I agree is great because at the end of the day, I think they're going to get effective utilization from their audience. And so to your question, how does that transform security teams? I think it does a couple of key things. The first one is I think it turns product security teams a little bit more, almost like a SOC function, the security operations center where having a holistic view of all of your assets, all of the application across all these disparate technologies and having a system that alerts you when something is out of whack or if there's a set of risks that need to be acted on within a certain period of time. I think we're going to see more of that being accepted. And then the other thing I'm expecting is that product security teams and abstract teams are going to be doing more internal evangelism in marketing. And it's not from a perspective of, “Hey, security is important” because if software engineering products won't cooperate with security and then the engineering team and the product team, they already know it's important, then the question of how do they act on that information as efficiently as possible? I think organizations are going to start looking at product security teams not for visibility, so much visibility into what's wrong, but guidance on how to address it as quickly as possible. So having that holistic view of all your risks and being able to sort it, manage it, slice the data and back it up with operational guidance is going to be key for product security teams to be able to scale as we move forward in this direction.

Harshil: I love the fact that you're pitching Tromzo to our audience indirectly. So tell me about why you actually joined the company.

Eric: I know the joke will always be closing, right? At the end of the day, it is a real problem. So I have two kids that are both below the age of ten and they're growing up in a very technology savvy way and a very technology oriented world. And the amount of diverse software that plays a role in their lives is substantial and is significant. And as I get older and the chip on my shoulder from my teenage years and 20s kind of falls away, the more I realize that I want to leave behind, it's cheesy i know, a world that's better, safer, selfishly, for my kids. And when I look at the world through that lens and look at the work I've done and this field through that lens, the inability for people, boots on the ground, these teams to be able to make use of and drive the resolution of all these software vulnerabilities that are cropping up everywhere, one is not good, but then I don't want my kids to grow up in a world where that's the reality, where there’s just holes and issues everywhere. So I guess more from the heart, I want to do whatever it is I can with the skills that I have to address that problem and will make the world better for my kids when they get older.

Harshil: That's such a beautiful mission and a fantastic way to make career decisions based on a personal mission. I love it. I am very sure that we will continue to build amazing things at Tromzo. We are all aligned towards a common goal, common mission. And I'm incredibly excited to have you on the team, Eric. Thank you so much for joining this podcast and have a fantastic rest of the day.

Eric: Awesome. Thank you.