Blessed are the software engineers, for they shall inherit cybersecurity
Looking beyond security engineering and explaining why software engineers also have the potential to shape the future of cybersecurity
One of my core convictions which informs everything I discuss in Venture in Security, is the idea that the future of security is going to be similar to that of engineering. In one of his articles, Rami McCarthy points out that for many organizations, this is not the “future”, but already the present-day reality.
The idea that the future is already here but it is not evenly distributed is not new but it rings especially true in cybersecurity where the gap between the security haves and have-nots continues to widen. In this piece, I am looking beyond security engineering and explaining why software engineers also have the potential to shape the future of cybersecurity.
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
Over 2,565 copies of my best selling book “Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup” have been distributed to the readers so far. This book is unique as it talks about building cybersecurity startups. It is intended for current and aspiring cybersecurity startup founders, security practitioners, marketing and sales teams, product managers, investors, software developers, industry analysts, and others who are building the future of cybersecurity or interested in learning how to do it.
Software engineers are building security, not just creating vulnerabilities
Nearly two years ago, I wrote an article about the role of open source in cybersecurity. While everyone in the industry sees open source as a source of vulnerabilities, most of us forget that open source is also in many cases a solution to security challenges. Moreover, it is precisely the way cybersecurity originated - by having people share knowledge, collaborate, work in public, and build on top of one another’s ideas.
The critical role of open source in maturing cybersecurity is entirely logical, but it is not obvious. The same is true when it comes to the role of software engineers in our industry.
Industry pundits like to talk about the need for software engineers to pay more attention to security. There is a lot of thought leadership surrounding the topic of “making engineers care about security”, getting them to fix security vulnerabilities early in the software development lifecycle (the whole shift left movement), and so on. I do not want to underplay the importance of these topics, but I think it needs to be finally said that software engineers are building security, not just creating vulnerabilities.
Security is an inherent property of any piece of code
Back in 2011, Marc Andreessen of a16z proclaimed that “Software is eating the world”. Fast forward to today, and it is easy to see that he was right. Software underpins the very foundation of the infrastructure we rely on in our daily lives. It powers everything we do, and it is embedded everywhere we look. When security professionals think about this, many start to lament that the world we live in is fundamentally insecure because “engineers don’t care about security”. It is easy to arrive at that conclusion when cybersecurity tooling finds never-ending lists of vulnerabilities. It is logical, yet it is not quite true.
The job of software engineers is to write high-quality code to solve problems and achieve business objectives. This is what companies pay them to do, and this is what they are being measured on. While engineers do not indeed spend much time thinking about security, they take great pride in writing high-quality code. Quality has many aspects which include latency, readability, efficiency, maintainability, consistency, testability, reusability, portability, scalability, modularity, clarity, and finally security among many others.
Indeed, security is just one of many aspects of code quality, and I think it should be treated as such. Security teams frequently feel like their job is to teach everyone how to be secure, so many are spending time and effort trying to convince developers that they need to “care about security”. There are many great materials about building guardrails and paved roads, and people talking about it are better positioned to do it than me.
What I think is worth emphasizing is that security is an inherent property of any piece of code. In other words, even if the software development team doesn’t have any application security tools in their environment and does not employ any security engineers, the code it ships is not going to be fully insecure. Similarly, if there are no people and tools dedicated to quality assurance (QA), it doesn’t mean that every line of code that will make it to production will be buggy.
There is a growing number of engineers with experience building cybersecurity solutions
Another way in which software engineers are shaping the future of cybersecurity is by building security products themselves. Over the past decade, the number of cybersecurity startups exploded, and with that, so did the number of software engineers with experience building cybersecurity solutions.
At first glance, building security products is no different than building any other products - most software engineers should be able to do that. In reality, that is not entirely true. There are several reasons why that is the case:
Security solutions are data-heavy. Most tools are designed to ingest a large volume of log data, and then detect and respond to threats. Having strong software engineers who specialize in data and data engineers can offer startups a big advantage.
Security solutions are integration-heavy. Most tools need to be connected to other products, and almost no product can bring value on its own. Maintaining hundreds of API integrations is a slog. While there are solutions like Leen and Synqly that promise to solve this problem, most companies are still building integrations in-house, or delegating this work to offshore software firms.
Security solutions require experience with low-level programming languages and knowledge of operating systems. From what’s happening on the Linux kernel to how bad actors can be detected by analyzing Windows Event Logs, software engineers building security solutions need to have some interest in very deep areas of software, hardware, and operating systems.
Security solutions require the support of legacy infrastructure. Unlike many other B2B SaaS solutions which can often get away with building new and exciting tech, security startups have little choice but to support legacy tools and infrastructure as they still need to be protected.
Security solutions require highly privileged access to customer environments, and therefore they are subject to high scrutiny from the buyers. This means that software engineers building security products have to get used to operating with security in mind and dealing with the level of oversight rarely seen in most other B2B SaaS companies.
By no means is security a unique field in terms of how software is built. At the same time, there are unique aspects of building security products.
Software engineers with experience building security products are well-positioned to launch cybersecurity startups
I often talk about the rise of security engineering, the need to bring software engineering principles, systems, and processes to cybersecurity, and the fact that security engineers have the potential to build great cybersecurity companies. While I think all these perspectives continue to be true, the fact of the matter is that building internal tools is not the same as launching customer-facing security products. Over the past year, I became convinced that software engineers with experience building security products may be even better equipped to launch cybersecurity startups than security engineers.
Many full-stack, low-level OS, infrastructure, and data engineers have accumulated fantastic experience building products from concept to launch. More importantly, they know just how much the user experience, scalability, and robustness of these solutions matter to customer adoption. The way I think about it - everything can be learned, and people with a strong track record building security solutions in-house can usually figure out how to do it as a standalone company. The key is having experience in software engineering: writing a script can help automate tasks and configure existing applications, but one needs to know how to program to build new applications.
Many security problems are fundamentally engineering and data problems, and there is enough evidence that taking a different approach can lead to unique insight which in turn can become a foundation for a winning company. For example,
Abnormal Security has proven that by applying machine learning to large amounts of email data, it’s possible to build a product that can move the needle for email security. Abnormal was founded by an experienced software engineer and a product/go-to-market leader.
Avalor, founded by experienced entrepreneurs and data-savvy software engineers, showed that vulnerability management is also a data problem and it can be tackled as such.
Plenty of new cybersecurity startups such as Tarsal and Tracecat were also founded by software engineers, and not security practitioners (or even security engineers).
None of these examples illustrate that security knowledge is not important. Instead, they highlight that software engineering experience can be sufficient to get started. In addition, it is worth saying that just knowing some front end is not enough to be a solid cybersecurity startup CTO. Full stack engineers, low-level OS developers, DevOps and site reliability (SRE) engineers, as well as data and infrastructure engineers, on the other hand, are well positioned to succeed.
This brings us to an interesting observation: there is a fairly limited pool of software engineers with experience building cybersecurity products in the US who may be eager to start their own companies. There are several reasons why that is the case:
In recent years, a growing percentage of new cybersecurity startups have been coming out of Israel. While Bessemer doesn’t explicitly call it out, the fact of the matter is that 13 out of 14 cybersecurity companies acquired in the past year for over $100M were from Israel (excluding Tessian which is based in the UK). Israeli cybersecurity startups tend to keep their research & development (R&D) centers in Israel. As a result, their expertise in building security companies multiplies with every exit and every new startup. While the fact that Israel is developing such strong expertise in building security products is rarely getting enough attention, I think it is one of the secret sauces of the Israeli cyber ecosystem. The United States has orders of magnitude more capital than Israel, but not necessarily more software engineers with experience in security ready and willing to take risks and start companies.
A good percentage of US-based cybersecurity companies have their software engineering teams in India and other countries with lower costs of labor. This has recently turned into a trend with companies started in Silicon Valley. From the business standpoint, this makes perfect sense: if a company can assemble a team of 10X engineers abroad for a lower cost than it would pay to hire the same number of average engineers in the US, it’s a no-brainer. And yet, this also means that we aren’t accumulating as much expertise in building cybersecurity startups in the US as we could.
The US continues to be a home for giants such as Microsoft, Google, Splunk, Palo Alto, and Zscaler, but even with them, not everything is that simple. Both Palo Alto and Zscaler have a strong presence in India and Israel. In his interview from 2023, Nikesh Arora, CEO of Palo Alto Networks, explained that “In the last five years, India has been the fastest growing office of Palo Alto”. Google and Microsoft also have R&D centers focused on cybersecurity abroad. While they still hire strong security-focused engineering talent in the US, we have not seen people from these companies have as much impact on the startup landscape as one would have hoped.
So, where will the next generation of unicorn cybersecurity CTOs come from? Among places such as engineering-centric security teams (think of Notion, Figma, Ramp, Brex, and others), I think they will be from:
Fast-growing cybersecurity startups such as Abnormal, Vanta, Drata, and Rubric. These people have experienced growth, seen what success looks like, and know what it takes to get there.
Infrastructure, AI, and data-focused teams of large enterprises and startups. Someone who built SSO or engineered a CI/CD pipeline at, say, Palantir, or someone who architected data pipelines at Elastic, is perfectly positioned to bring innovative ideas much needed in security.
Large cybersecurity companies such as CrowdStrike, Palo Alto, Zscaler, or Okta, especially if they also have a track record working at a startup before or after joining these behemoth enterprises. Good CTOs need to be able to ship fast, cut corners (and know which corners to cut), and this kind of experience can only be accumulated when working at startups.
If history teaches us anything, it is that the new generation of cybersecurity startup founders tends to come from existing (and usually, successful) security companies. I have discussed the role of cybersecurity mafias in my blog before.
Keep in mind that there are no formulas: once in a while, there is an outlier that comes in and reshapes what is known about the way cybersecurity companies are built. It is those outliers that challenge our biases and assumptions, and it’s thanks to the people who challenge the way things are done that we are able to progress exponentially, and not linearly.
On that note, if you are a software engineer building (or thinking of building a cybersecurity solution), please say hi - I’d love to hear about it.
Vogons don't do security :)
Security? In software engineering? That's like expecting a Vogon constructor to appreciate a good Pan Galactic Gargle Blaster! Most engineers are far too busy wrestling with the Babel fish of code to worry about pesky little things like digital bank vaults and firewalls. Though, I did see a DevOps chap the other day trying to use a spork as a security key...
more lines of code more vulnerability & larger the codebase bigger the attack surface.