Interview with Innovation Sandbox 2nd place winner, Pangea. Pangea CEO Oliver Friedrichs, a former Founder of orchestration phenom Phantom, discusses the state of AppSec and what is wrong with the shift-left movement.
Pangea discusses how shifting-left-of-left can bypass both arguments between SecDevOps and app developers, and false positives in code analysis. Paul forgets he’s met Oliver before and then wonders how many security products could be eliminated if developers wrote secure code on the first place.
Finally Oliver lays out how Pangea’s Security Platform as a Service (SPaaS) hands developers authentication, security logging, export restrictions, personally identifiable information (PII), IOC scans, and more.
Find Pangea on the web at Pangea.cloud, on Twitter @pangeacyber, or LinkedIn.
Founder and CEO Oliver Friedrichs can be found on Linkedin.com/in/oliverfriedrichs.
Paul Shomo can be found at LinkedIn.com/in/paulshomo. Send Paul Shomo feedback on Twitter @ShomoBits.
Follow us on Apple, Spotify, Google, YouTube, or your favorite podcast app. Give us a review and I'll give my early adopters a shout-out on the show.
Interview with Innovation Sandbox 2nd place winner, Pangea. Pangea CEO Oliver Friedrichs, a former Founder of orchestration phenom Phantom, discusses the state of AppSec and what is wrong with the shift-left movement.
Pangea discusses how shifting-left-of-left can bypass both arguments between SecDevOps and app developers, and false positives in code analysis. Paul forgets he’s met Oliver before and then wonders how many security products could be eliminated if developers wrote secure code on the first place.
Finally Oliver lays out how Pangea’s Security Platform as a Service (SPaaS) hands developers authentication, security logging, export restrictions, personally identifiable information (PII), IOC scans, and more.
Find Pangea on the web at Pangea.cloud, on Twitter @pangeacyber, or LinkedIn.
Founder and CEO Oliver Friedrichs can be found on Linkedin.com/in/oliverfriedrichs.
Paul Shomo can be found at LinkedIn.com/in/paulshomo. Send Paul Shomo feedback on Twitter @ShomoBits.
Follow us on Apple, Spotify, Google, YouTube, or your favorite podcast app. Give us a review and I'll give my early adopters a shout-out on the show.
The very difficult question. Why can't anyone get developers to fix their code? Are you the person with the answer to that question? We think so. You know, the developers really the majority of which are not security experts, right? We're expecting 29 million software developers by 2024 and how many of those do you think know how to write security code? Probably very, very few. And this problem will only get worse, right? Beyond the developer account, we're expecting a million software companies by 2027, which means almost every company in the world is now writing code if you want to be relevant and build for the future. So the reality is that there is a need for someone to come along and embed security functions into cloud applications out of the gates, and that just doesn't exist today. The genealogy of cybersecurity is a new kind of podcast. Here we'll interview notable entrepreneurs, startup advising cisos, venture capitalists, and more. Our topic, the problems of cybersecurity, new attack surfaces, and innovation across the startup world. Welcome. I'm your cybersecurity analyst, Paul shomo. Yeah, my name is Oliver Friedrich. I'm founder and CEO at pangaea. And hey, congratulations on making innovation sandbox. It's a huge accomplishment. The finalist list in years past have all had lots of investments thrown at them and IPOs. So it's really, you're in the winner's circle just by making the top ten. Yeah, thanks very much. Yeah, definitely appreciate the recognition and excited to participate. So we're looking forward to the actual competition on April 24th. So speaking of competition, one of the things that's interesting about it is a lot of the application security technologies that have came through in the past were they were more like analyzing developer code or testing just built applications to tell them what to fix. But you're kind of a different company than I really seen come through this competition before. And that you're really kind of helping them build secure applications in the first place. I want to dive into your company in detail, but because you're different, I'm really curious to go through the problem application security with you because I suspect you might have a different perspective than what we have. What would you say the state of application security is right now? Well, I think if you look at the current software development life cycle, right? It's a lot of you know, it starts with the build process where developers are building the application, and they may source their security features from open-source or a fragment that set up commercial vendors that are all using different pricing models. And in some cases, they may build it themselves, right? When they're looking at security functions, and they're typically not getting them from a reliable trustworthy framework. And so what happens next is that you have an entire industry that's been formed around static source code analysis, support dynamic analysis, or a third party library and a dependency scanning to make sure that the code that they built is actually secure and doesn't contain vulnerabilities. And most of the you know, when you hear about the shift left movement, right, that's where the emphasis has been is like, let's try to get left of boom, which is the actual compromise by making sure the application is secure. But it's not going as far left as you can, right? Like if you actually had secure code from the beginning, then, you know, you wouldn't have the need for all of these, you know, source code analysis tools and companies and industry. But that's how we're doing it today, right? It's not the most efficient model. Agreed, agreed. Are there any high profile breaches or vulnerabilities that you've noticed that really kind of stand out in your mind as illustrating what's been wrong with these traditional approaches? Yeah, it's a good question. I think if you look at a lot of applications, I mean, that are using the cloud and they're using S three, for example, as an object store, some of the most obvious ones are the ones that are storing data in S three and the S three permissions aren't set up correctly or IAM isn't configured correctly, to be able to restrict access to those to those objects. And that's an example where developers have configured S three as a place to store files, but they haven't necessarily implemented the actual protective measures, whether it's encryption or role based access control or fine grained access control on those objects correctly, which exposes a big issue, right? Developers have had to write all the code to write files to S three to control access to those files, but it's exposed a pretty big significant pretty big security security hole as a result. That's interesting you bring that up because there has been, of course, entire product categories like the security posture management products that they're selling there because they know the configurations are set up incorrectly. And let's just go through. We have the secret once on the secret knowledge. But they have the knowledge of all the different parts of the cloud assets and your applications. Let us fix the controls for you, but you're saying you can help developers set them up correctly in the first place. Yeah, I think if you imagine you as a developer, you could have an API that was just secure out of the box. And you didn't have to worry about configuring all of these complex like authorization levels. Wouldn't that be great? And so that's one of the areas that we see an opportunity to improve. Are you an SDK that's built into applications, or are you more like a set of micro services that the developers call into to implement security? What do you look like? Yeah, we're a cloud delivered set of APIs. So just like stripe is something that you would connect to to embed payments, Twilio for communications. We're delivering core security features as an API for developers to plug in. So it's typically a few lines of code. We have SDKs for Java, JavaScript, python, go C sharp, and other languages coming. And so if you want to embed pangaea, let's say you want to use our file scan service, you're dealing with user file uploads. You want a scanner to scan those files for malicious code, it's just two lines of code deployed that in one to include us one to do the scan itself, makes it super easy to get what are very complex security features, right? Where else would you get that? You could go and plug virus total into your production product, but that's not practical, right? They're not built to be plugged into a high velocity, high volume, highly trafficked cloud product. They're more of a research analyst tool, right? So that's the type of services that we're building and delivering is core essential services that developers can embed easily out of the box. So could you give us maybe go over some of the security features that you help them build out of the box? Yeah, like the ones that are essential when you think about delivering a new cloud product, there's a set of essential services that you need regardless of what you're building, whether it's a B2B product or a B2C product, you need authentication, right? The login box to get into your application. You need authorization, which is the ability to implement role based access control within your product, whether you're an administrator, manager, a regular user, what are your permissions and what access do you have to different functions? In the product, you may need fine grained access control on objects as part of that authorization layer. You know, Google and coin something called Zanzibar, which is their graph based access control model that you might see in Google Drive, for example, when you share a file, but that isn't something that's available to app developers, right? So we're delivering that to application developers so that they can embed that out of the box very easily. You need a secret manager. So our vault service has a secret and cryptographic key store to be able to manage secrets within your application used for database access, API access, other token access, every app needs a secure audit log to log essential important security events like login, logout events, password change events, let's say your financial org. You want to wire transfers or other transactions to make sure that's stored securely in a tamper proof way that's cryptographically verifiable. Our secure object store will build a layer on top of common file stores like S three to allow out of the box secure storage of objects with a few lines of code with a Google Drive like experience to be able to drag and drop files to manage sharing of those files directly embedded in your application. And that's not something that's really available today. Anywhere. Our file scan service will scan user generated content for malicious files. And then we have a variety of partnerships that we've established as well. So we partnered with CrowdStrike for their intelligence database to be able to identify indicators of compromise. So typically, you'd have to go to CrowdStrike to license their dataset, which is a really expensive proposition. In our case, you can come and pay as you go. It's so penny per API call to access world class threat data. From CrowdStrike, reversing labs, domain tools, digital elements, spy cloud, and a handful of others. So we're really becoming the central place for developers that need any security function to embed those into their application with a very simple pricing model just like AWS and other providers, which is pay as you go, and a common procurement process, single login, very easy to get a single auth token for all of these services so that it's one single source for some pretty important security features. That makes sense. It's interesting as you go through these you know. We already mentioned the posture management products were to lock down wide open configurations and you're mentioning other things like redaction so that there's a whole category of security products to mask data sense of data. And so it's interesting to think about that there are entire categories of security products that you layer on top of bad application security, where you're just going right to the source and saying, hey, why don't you just develop secure apps in the first place? That's a great way to put it. We're in some respects taking the entire world of security and turning it into a simple set of APIs for developers, right? So they're not going to go buy these large Enterprise Products that have typically been used to solve the problem after the fact, and so it's yeah, it's a great observation. That's why we see ourselves shifting left of left. We're trying to solve the core problem with some of the same approaches, but embedded in your app instead of with an enterprise product coming down later to try to fix it. Shift left of left, I like that. It sounds like you're fixing the developers by giving them a solution that matches up with their kind of framework of their goals they're trying to get to and to match up with what their bosses want, what their companies want, and that's interesting. Yeah, exactly. And it's you know developers don't always want to learn security and they're focused on other problems, through either a data scientist or machine learning experts or good at what they're at the app that they're building, and so it's boring for them you know. Sometimes to engage in this and trying to figure this out. And it solves an important problem. And for the executive to see, so for example, it gives them a lot of confidence, lets them sleep at night because they're getting a trustworthy framework of unlocked services that they know are built by veterans in the industry, and are delivered securely, and they don't have to worry where their developers are getting this code from. And you know whether it's open-source or from some other vendor model, I talked to a large enterprise this morning, and they have three big cloud products that they host across AWS and GCP, some of them through acquisition, they have no idea what their developers are using for important core functions like secrets management or other approaches. And so consolidating that is a lot of it's not only cost savings, which obviously the CFO and the CIO worry about, but it's also enabling a reduced attack surface. So the attack surface is reduced. And it's a reliable set of those trustworthy services like. You mentioned IOC scans and file analysis for malware and threats. Do you end up being part of the deployed architecture like some kind of API gateway or is it still just kind of a calling over to a microservice? What does that look like? Yeah, we host our services on a global network that we've deployed across AWS and GCP. Worldwide in multiple regions, countries and availability zones. So if you're running a let's say a cloud app on AWS, U.S. west one, which is a common region on AWS, we're running there as well. So your code would call RAPI directly. And ideally, it's one hop away because we're running in the exact same region and AZ as the customer's application. But we do host our own API endpoints. So you're hitting our APIs. For some services, we have what's called a sidecar, which can run on premise. So for a high volume activities like, let's say high volume redaction where we're looking at a lot of datasets and during high frequency API calls, redacting PII, personally identifiable information. You may be, for example, running a site that has user generated content and you want to make sure that there's no PII being posted, whether it's credit card numbers you know, people believe it or not, post things that they shouldn't because they think they're trying to get support or they're talking to someone who's helping them. And so that's an example where we have customers that are using our on premise sidecar to be able to filter that PII from those high frequency user generated content posts. Sounds like a very helpful thing to hopefully deploy, secure applications in the first place. But I'm curious, with the rise of DevOps and sect DevOps, it's a little confusing to us sometimes there's a big new attack surface. What are your customers look like? And what are they typically developing? Could you help us kind of understand big picture of what we're securing here? Yeah, most, if not all, are cloud applications that may be pure SaaS based cloud applications. It could be mobile as they're hitting APIs as well and using API endpoints, but predominantly cloud applications. So most of our customers are either already in the cloud or they're in the process of migrating on premise applications to the cloud. In which case, we're a great entry point because they need to add security. They don't necessarily have it yet, especially in the cloud version of their applications. So that provides a great opportunity. Others are extending their apps to add security features like. Again, if you have user generated content and you want to scan that content, if you have a customer success platform, our customer service platform and you want to scan service tickets and user input for malware or even a malicious domain names through our partner domain tools and user generated content or IP addresses through our partner CrowdStrike to see if those IPs are malicious. So there's really a variety of use cases. You want to tell us a little bit about your origin story like where the idea came from, who you worked with and collaborated with in terms of venture capital community, ciso, CTOs, what did that look like? Yeah, I know a lot of this came from our last experience actually. We had a company called phantom where we really are credited for creating the source base security orchestration automation and response. And in that company, we actually integrated with over 300 different APIs to automate cybersecurity operations, right, and to read events from Sims react to the automatically create playbooks. So we did a lot of integration into APIs across the entire security world. And it kind of started showing up as a next step, like imagine if we could now deliver all of those APIs as a single vendor out of the box for developers, like less for the stock, but more for the development teams like. That's something that, first of all, hasn't been done, it's a huge need, and it's been proven in other categories like, again, stripe with payments, Twilio with communications, and AWS with compute. Shoot, like this has to exist. And so we started talking to our CSO contacts. Universally, we received a positive response that if we had this when we were building our application, like we would have used it. Right. And more mature companies have something in a lot of cases, so we're looking more for expansion and new use cases. And then the investors you know, one of the first people that we spoke with was barmak at ballistic ventures. He got it within a minute. And he's like, we got to go do this. And it was such an obvious problem. He had previously been part of a company called fortify that was bought by HP, creating some of the early static source code analysis, technologies. And so understood it out of the box. And then other investors came on board Jay Lee from sin ventures really, really got it. We then worked with Kareem at Google ventures who came on board really seeing the opportunity even with what Google is doing in the security space. There's a lot that they're not going to touch that developers need as well. And then John Sato at decibel and then okta ventures came in as well because for okta and off zero, this is a natural next step. If you're building a new cloud app, you may go to a zero for authentication, but then you need everything else that pangea has embedded in your app to get to market. It's funny. I go through so many folks at this time of year. I knew you looked and sounded familiar. We did an integration with N case way back in the day and I talked to you actually, I think I wrote up the first roundup of soar in 2017, which would have been right when he went to the version three O and I called out the top three even back then phantom swim lane and de misto, which you all proved me right. So I think we've actually met before. This is funny. That's a while ago, yeah. But yeah, it was great to talk with you then. And it's come a long way. Very interesting that I don't know if the shift left of left is going to be a phrase, but I liked it giving the developers something that enables them instead of telling them what's wrong with what they did is a very interesting approach. I can see why even though this isn't, it doesn't look like the traditional application security tool that we had seen come through this competition. I can see why it's here and I can imagine there's going to be people in that space that want to do what you're doing. Yeah, it really is about time to market and getting your product to market faster and saving costs along the way with a predictable pricing model that's more of like an AWS pay as you go model. It's also about having a trustworthy framework of reliable services that you know out of the box are going to plug in with a few lines of code and get you the security features that you need with a really, really light lift. And so that you can focus on the core IP that you want to develop in your company versus trying to be a security expert. I'd say that similar to like an AWS, we're not really limited by company size. We have everything from startups that are three people building a brand new product to the largest financial organizations in the world that are looking at using some of our services simply because they may not put us in their critical path today, but they have many thousands of cloud applications in some cases that they're migrating to or on premise applications rather that they're migrating to the cloud where they need to embed security easily. Well, it sounds like your price model lets them scale from small to big. I don't want to speak for some of your older competitors or the prior generation. I think some of them could be quite expensive for small outfits with three developers. Yeah, in fact, it's infeasible, right? Or even inaccessible for those companies to ever get to some of these tools and features and the threat Intel side, for example, right? You just never go procure that, but this makes it accessible. And we also have a great program for startups. We're willing to work with you and give you some really great credit on the platform to get up and running so that you're not burning your investors dollars on day one just to get to production. So yeah, just talk to us and we'll work it out. And then for bigger users you know, eventually that outgrow the pay as you go model will also arrive at an enterprise license agreement where it's a predictable consumption model and a reduced price with a discount given a commitment as well. So similar to what AWS would do, right? If you become a big enough AWS customer you're eventually going to go and pay more of an annual license agreement versus the credit card based approach that you're doing today. Are you essentially one of the first in this category? Is that your differentiator or do you have another differentiator? What does that look like? Yeah, I think it's a few things. One is we are the first. We're calling it security platform as a service as a result you know, similar to other verticals where you have this approach. Some of the technologies clearly exist, right? In their own isolated worlds, whether it's open-source or different vendors doing one of these things, but it's the first place to consolidate. I'd say you know what we like to say is we're really consolidating the entire world of security into a simple set of APIs for developers. Most of these products are more for enterprise users, they're for end users, they're for the security teams, to your point earlier after the fact versus embeddable for developers upfront out of the box, and that's the big difference. Also, the pricing model is different you know. As we mentioned, write the pay as you go model, makes it attainable for many of these early stage companies and for anyone to really try it, very, very easily. So the delivery bulk model technically is new and the pricing model is new. And they go to market model as new as a result as well. So definitely some differences, even though some of these things have existed for a while. Very cool. So if people want to reach you on the web or reach your company, how do they get to you? We're at pangea dot cloud, PANGEA. Dot cloud and yeah, you're welcome to sign in and try it out. It's free to get started. And are you on Twitter or folks on LinkedIn? They might want to look up. Yeah, pangea, cyber on LinkedIn, and our Twitter is also pan GSI.