Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

We’re hiring for product and application security roles in our organization. Come join me and our awesome CISO, Susan Chiang, in building a secure mental healthcare system that everyone can access. We are looking for a director of product and a senior application security engineer. Feel free to apply using those links or reach out to me!
Someone recently showed me this cool startup, Pangea, which makes it easy to design products securely by default. A common topic in the security industry is “security by design.” The concept has been around as far as I can remember. However, if you look at the big cybersecurity companies, none of them are related to this concept. In fact, almost all of them are layering security on top, or reacting to security problems through monitoring or response. For example, Palo Alto Networks started as a firewall box that you can plug into your datacenter. Their cloud security products are primarily monitoring tools. Similarly, Crowdstrike has an agent installed on endpoints that monitors and takes action. Even Auth0, which is part of Auth0, isn’t security by design, it’s primarily meant as an integration, i.e. it’s supposed to work with various setups and environments.
This isn’t intended to be a blog about Pangea. It’s intended to discuss the concept of security by design. I’ll talk more about Pangea a bit later, but not to bury the lede, I do think Pangea is an interesting concept. In fact, I believe there should be more products like this. As a disclaimer, I haven’t played around much with Pangea, and I’m thinking of them in comparison to Auth0, with which I have hands-on experience.
Seeing Pangea, I wondered why companies that advocate for security by design aren’t successful. It’s because security by design might seem like a good idea, but it isn’t practical and won’t work for most companies.
Does “security by design” work?
It comes down to tech debt. As security people, we hope that people care about security early on in the development process. Unfortunately, that’s not the reality. Almost every person is more focused on delivering a product quickly, and many times, security slows them down and/or is an afterthought. Of course, this isn’t an excuse for poor security. It’s just that most developers don’t have security at the top of their minds nor do they always know the best security practices. Pangea solves this by allowing developers to have basic security from the start. So, why don’t people do this?
One major problem is that products change, so it’s hard to understand security requirements for an ever-evolving product, especially earlier on. There are fundamentals like storing passwords properly, encrypting sensitive data, etc. Although this is necessary, it’s rarely sufficient. Another fact worth noting is that most of the best practices were developed recently, but some applications were created before this. It’s difficult to rewrite these applications properly.
So, security by design does work with what we currently have, and especially, with tools like Pangea. However, it only solves for the future but not the past. This works if companies start building now with these tools, but it’s difficult to integrate these tools with current applications because they tend to be a bit too black-box. That is, there’s not enough customization to deal with the nuances of the tech debt created in most applications.
As a result, the market for these tools is mostly new companies/startups, and the bet is that they will make it bigger. However, this will lead to a lot of thrash because most startups fail, so it’s likely they will see substantial churn. In addition, they have to find ways to educate startups on this so that it doesn’t slow them down.
They have major market risk — they have to make sure their customer acquisition costs will be lower than the lifetime value of the customer, which could be low and/or have a high standard deviation. This is because they have to find a market segment that will likely grow since they are technically looking at “new” markets. It’s smart that Pangea specifically has focused on the AI application market because it’s a new market that will likely grow (despite some potential turbulence since there are likely more AI applications than the market needs). The question is whether these are new companies or existing companies building AI applications within their stack. The latter is harder to capture. In other words, it’s hard for these types of tools to capture the existing market, which is pretty large.
Finally, another boundary is that having too deep of an API integration with these tools will make them too sticky, i.e. it will make it hard to swap out. This is a problem because these APIs feel like black boxes that are hard to customize, so it’s hard to do security by design if the product is too opaque.
How can these products capture more market share?
There are a few potential changes/ideas to help increase the adoption of security by design products. To start, I believe the market should change to security by integration or security by replacement. Those are probably not the best descriptors and definitely need work! The idea is that these products need to describe ways to solve issues with existing applications.
Specifically for Pangea, they are focused on APIs, but this even feels like too much friction. One way is to integrate into common application frameworks like Flask or ones that AI applications are likely to use. Another way is to create a new framework where they can build the application. This will reduce both development and security usage friction, which is a win both for the developers and security. This will require some developer evangelism, but it could be a good risk since the AI development market seems relatively nascent, especially the ones that are focused on developers integrating AI. Finally, they can create middleware for the framework as seen with frameworks like Django. This suggestion relies on the idea that to increase adoption, security needs to happen behind the scenes.
Another way is to have more customizability with their API, similar to what Auth0 does. This allows them to integrate better with existing applications and open up the existing market. Of course, this makes the deployment process more complicated and longer. It will also require more documentation and having to handle various edge cases that exist with various systems. In other words, it will no longer be straightforward and require the developer to spend more effort and have more expertise. It also complicates the product substantially, which might increase friction with adoption.
This leads to the third suggestion: providing professional services to help with adoption. I know this is always an unpopular option because services don’t have great margins and aren’t attractive for VC investments. However, in this case, applications are so heterogeneous because of tech debt that it’s hard to build security software that works well just out of the box. This also helps companies that don’t have sufficient resources and/or expertise to do this properly, so that’s a barrier to adoption. I believe that professional services are underrated but can be important to adoption as well as generate revenue in the short term (even though it’s low-margin revenue). It also works well even if you’re going with a basic API approach. It complements well if you are creating more customizable APIs that have a high initial cost of setting up. Ideally, the cost of maintenance will be low. That way, either the company can maintain it with its existing resources, or you can offer a recurring services contract similar to software in the past.
Doing security by design is hard because most applications have tech debt that leads to heterogeneity that can’t be solved with simple software products. I believe it’s hard for these companies to exist by just addressing the companies building new applications. They need to find ways to expand their product to improve the security of current applications. Overall, these tools are important because we need to make it easier to integrate security best practices into our applications.