When it comes to creating, releasing, and maintaining software, startups are usually well-oiled machines. But this is not the case when it comes to securing software. Startups need to move fast but many developers still perceive security as a hindrance and a tax on progress, despite the meaningful increase in cyber risk that is created by neglecting to build secure software. Cool new features are useless if they are vulnerable to malicious exploits.
← All talks 
Build Turing Fest 2022
Building Security Into The Beginning Of The Development Cycle
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Good afternoon, everybody. It's great to see that Edinburgh has the same cultural quirks as my native Dublin does when it comes to beer in the afternoon. It seems the place clears out very quickly once there's free beer on offer. Yeah, if anybody needs help down the stairs or something halfway through, just let me know.
There's three tracks here today, build, grow, and lead. For myself, it's definitely falling more into the camp of building. The reason I'm here is I'm the founder of a company called Evervolt. We build effortless encryption infrastructure for developers that makes it really easy for them to collect sensitive data from their users and not worry about the data itself going missing.
As you can see, build is very much in the title of this talk. Although it sounds pretty anodyne, I don't think most people will argue that security is important and that building security in should be something that developers are considering. The harsh truth is that they don't.
One of the great advantages that I have in talking about security generally is that explaining the size of the problem and why it's important is pretty easy. All I have to do is just point to major media outlets and newspapers and so on, and everybody understands the scale of the problem.
People care about it. People say they do things about it and try to make everything a little bit better when it comes to the security itself. Generally, there's a lot of shortcomings that people fall into when they're building. But you ask any typical startup founder or engineer, they'll always say that security's a priority.
You can ask, do you care about security? And it's one of those leading questions where nobody's ever gonna say no. But the way that they say no is by making it priority two or three. Priority one is basically the only thing that ever gets done in a startup.
Priority two or three maybe gets half completed in six months' time or a year's time. But priority one is what matters, and it's very rarely security, unless you're actually a security company like us. This is a line that I hear all the time from startup founders.
It happens all the time. It's generally meant innocently, and it's just interesting that every founder comes to the same conclusion when it comes to creating their answer to this question of, do you care about security, or are you implementing anything to do with it?
They always just wanna build new features. As I said, priority one is start up building their product and getting into the hands of more customers. And security always feels like it's kinda secondary when it comes to that. But this mindset is kind of broken and faulty, because other features always end up appearing.
Developers are working on more and more things in the product itself. Customers are giving them feedback. They get a new idea for a new product that they should be building, or they think they should be building. That always takes priority, founders, especially early stage founders, really like shiny things.
Everybody talks about focus. If you read Zero to One by Peter Thiel, it's just focus on one thing relentlessly and ruthlessly. But you're fighting an uphill battle against human psychology there. Most people tend to lose that fight when it happens. Everybody knows that startups are great at this, though.
The one advantage of building features being priority number one for these startups is that they end up, generally speaking, shipping pretty good products and shipping features really quickly that their customers care about. They start getting really good reviews on Twitter, and customers give them a good feedback when it comes to, say, Net Promoter Score surveys or something, if any of you are founders that do them.
We personally don't, but that's a whole other topic of discussion. Generally, the people working on features within these startups, they're working in an environment like this. This may or may not be a real startup, but it's definitely reflective of when people sitting in a living room in Palo Alto or London or Edinburgh or Dublin or whatever, they got their laptops open, they got code editors open, they're just cranking out features to beat the band and just get their product together quickly.
Although it might be easy to think that this is sort of an overdramatized reflection of it, of what building a company looks like, it's really not. I've got a couple of other examples here. I don't know if anybody can guess what company this is, but if anybody can't guess, I'll tell you it is Airbnb in the early days.
Again, I think this is somewhere in the Mission in San Francisco. They all sort of just rented an office, which was actually a living room in a house. That fireplace you see behind them was actually used pretty actively during winter as well, which I think an office manager in Airbnb today would definitely have some concerns with, which seems pretty reasonable to me at least.
But here they're thinking about, how can we improve the booking experience? Or how can we make it easier for people to find, I guess at this point, a couch to surf on when they're in San Francisco or New York? They're not thinking about security.
There's another great company, Stripe. You see Patrick and John, the founders there. They're an interesting company because they have all these challenges with partnering with banks and making sure that they're sort of giving the impression that they're bigger than they are and that they really care about these things.
But again, you even see a code editor open in front of one of their engineers there. Again, they're shipping features, but they're thinking about things like PCI DSS compliance, because they're dealing with credit cards all the time. The only reason that Stripe were thinking about this, and again, don't wanna speak for them, but it's because they had to.
The banks were like, show me your paperwork, and we'll give you a license to use our merchant banking services. And they just did it as a result. So it ended up being priority one, because security was a feature for them. The general challenge though for companies that aren't Stripe or that aren't Evervolt is that companies this early on are just focused on surviving.
All that matters is, can you get from the stage that you're at now to having 10x more customers in a year or whatever, just looking arbitrary numbers out of nowhere, and making sure you don't run out of cash so you don't have to have a difficult conversation with your entire team, and yeah, tell them some bad news.
But this is a pretty pessimistic outlook on building a company, because if everything goes really well, your survival mechanisms suddenly have to change to growth mechanisms. You've kinda gotten out of infancy, you've learned how to walk, you've learned how to sell to customers.
There's a lot of parallels there. And it's about how quickly can you grow. To grow, you generally have to sell to customers that will pay you a lot of money so you can invest in making your product better. Overnight developers and startups that are building products, they basically go from building a product that they are selling to customers that aren't really paying them, or might be paying them a few bucks, but the only reason they really care about the product is because they got a free hoodie at a conference like this,
or they got stickers, one of their friends said it was pretty cool, they got free AWS credits or something. Those startups that are making decisions like that generally look like this. But then they have to start selling to customers that ask them about security questionnaires and basically what their security posture looks like, what their security team looks like, before they'll even talk to them or look at a demo.
The people in these companies look, again, a little bit less like this, and a little bit more like this. Brooks Brothers suits, they have worked at a law firm for a few years. They might call themselves CISOs or security architects or something like that.
But basically these people walk into a room or jump in on an email thread with what you thought was gonna be an engineering conversation, and then they start asking you about your certifications. You don't really know what certifications are. This is what goes on in the founder's head at this point in time.
It's like, oh, this conversation I had with Shane at EverVault or whatever other security company, maybe they were right. Maybe we should have thought about it a little bit earlier on. They kinda just go through this existential crisis. They start thinking about how can we get compliant with SOC two or ISO or PCI, and this maybe nonexistent compliance framework that looks kinda like keyboard gobbledygook, but they have to become compliant really, really quickly, and they have no idea how to do it.
So they open up their web browser, they start figuring out how they can actually become compliant, asking the questions that all of us ask in our head. But now that Google is a representation of what's actually happening inside our head, this may be real, maybe not real screen recording of an actual founder going through the process, asking all these questions, getting stressed out, and trying to figure this out.
Interestingly, you'll see that there's a bunch of Google Ads that have been purchased by companies that are aware that this is the thought process that companies go to when they're trying to make these decisions. It's working really well for them. But this is what they do.
In the meantime, those six figure deals or seven figure deals, the deals that are gonna let you double your engineering team or triple your marketing team or whatever, they're hanging in the balance, because time kills all deals. When you're going through this exchange back and forth, security team goes on holidays, compliance lawyer has a kid or whatever, has to take two weeks off, the deal can potentially blow up because you don't have this stuff ready to go.
But then they buy compliance automation software, Vanta, Secure Frame, Drata, any of these products that kind of help them through the process of becoming compliant. They find an auditor that's introduced to them by this company, and they get compliant really quickly. All should be good, or at least that's what they think in their head.
And again, this is sort of an apocryphal quote from many, many founders that, at least I've heard directly, I'm sure a bunch of other founders have too. They think they're secure, because a SOC two auditor said they're secure. The SOC two auditor has this framework of controls and requirements for what good security looks like.
All that matters is you can provide evidence to basically confirm that exact control. So it could be anything from, do you have multi factor authentication on your email, to do you have board minutes from your last board meeting? Because apparently that makes your software more secure.
But this is what they're thinking about. All this is to say that compliance isn't security. Founders generally have the best intentions when they're going out of their way, spending frankly big money on compliance software and auditors and so on to go through this process so they can sell to the bigger customers.
But when that's done, you think you're secure, and then the cycle just starts again. Founders now answer the question of, do you think about security? Instead of saying, we care about security versus priority two or three, they now say, we are secure. We've completed our SOC two certification or ISO certification.
Again, just not true. That's all fine. You start selling more and more to customers that care about this stuff. You sell to IBM or the US government or something like this, and everything's going great. Your revenue starts ticking up. Then after a while, you end up meeting with a customer who has a real head of security.
And the head of security looks a little bit less like our friends in the Brooks Brothers suits, and they look a little bit more like this guy. This guy, you know, has a like, an Ubuntu laptop, goes to DEF CON every year, grew up cracking WiFi passwords, hasn't paid for software in twenty years, just uses Still in twenty twenty two, downloads all his music on BitTorrent.
He's one of those people. He knows what security is, and he knows what secure software looks like. He's spending all of his time trying to break into companies, looking at the source code, looking at the APIs that you expose. He goes into your website, scrolls into the footer, sees like a SOC two logo.
He doesn't even know what SOC two is. He spends all his time in security, but that means nothing to him. So generally, HackerMan doesn't care about your standard operating controls, your compliance frameworks. They're just transparent things that don't matter to him at all.
Because the more time he spends thinking about compliance frameworks, the less time he has to actually try and attack you. After a while, HackerMan gets into your database. This is a true story. It happens all the time. HackerMan could even work for your company currently.
You could log into your servers, change your source code. There could be some dependency injection, a myriad of things that could possibly go wrong with software that people don't really think about securing. He gets your database. That's a problem. Because A, you might know about it, and B, it's just really, really bad, because you've got really sensitive information in there.
It could be social security numbers, credit card numbers, email addresses, whatever. Stuff that you just don't want on the front page of the New York Times. Not that they would publish that, but you know what I mean. HackerMan sees no compliance frameworks. He sees right through them. He's got laser eyes.
All he sees is an open port, badly implemented authentication, developer docs that are a little bit too informative. He steals an employee's laptop in a Starbucks. Really basic stuff like this that compliance frameworks don't cover. They're not thinking about, do you carry around a nine millimeter pistol in your pocket in case somebody tries to steal your laptop?
That is security, but it doesn't fit neatly into those frameworks, and a SOC two auditor definitely isn't gonna ask you about that. Now, if you're lucky, HackerMan is gonna be working for one of your customers, or potential customers. Is gonna be friendly. He is not gonna wanna actually screw you over all.
Worse he is gonna do is make the deal fall through, which is pretty bad when you are a startup. But in the scheme of things, nobody is dying. Nobody is losing all their sensitive data, so it wouldn't be too bad. But what if it's not?
What if he is some guy on the internet, doesn't have a real name, has the same personality characteristics as the guy that goes to DEF CON every year, but he lives in Belarus and is employed by some nation state to get into your infrastructure, take the information out, post it on the web, request a ransom, then use that to fund buying arms for some militia in some country that I won't name.
Now HackerMan is not just unhappy with your product. Obviously it is a really bad deal, or a really bad scenario that he is. But compliance teams and lawyers are now, too. They are gonna start asking you questions about, like, oh, you said you were secure.
You showed us your SOC two certificate. You showed us your ISO compliance certificate, and you have a good auditor and stuff. Like, what went wrong? Then obviously that is the lens that they are looking at it through. But it's a complete mess. If it's really bad and all your data gets properly published on the internet, you could be being sued by a regulator, or it could be a class action lawsuit if you're in the United States or something like this. Costs real money.
We've seen it happen in the past with things like Equifax. They had to go to a full Senate hearing. I don't think anybody Well, I mean, would be pretty cool to go to a Senate hearing, but ideally just for non bad reasons, personally speaking.
Complete mess. Distilling all this down, what's happening is that startups are designing security for compliance teams and fake security so they can get deals over the line. But they're not building their products securely for what really matters in protecting against, which is hackers.
People like HackerMan, a six year old kid who's just figured out installed Kali Linux and got all these tools themselves. There's a lot of people in the world that don't necessarily want to do right by your company. All that being said, some of you here might be thinking now, oh, maybe we should think about security.
How do we go about that? This is a question that a lot of people ask all the time, particularly in growth stage companies where they've sold to a few customers, they've got a decent bit of revenue, they look into grow reasonably quickly, increase their average deal size.
They wanna hire a security team to do security. But anybody that has ever worked at a company that is sort of scaling from two people to ten people to twenty people and beyond, you realize that once you add people in a company whose sole responsibility is one particular thing, everybody else in the company stops caring about it.
You hire a recruitment team, no one else wants to recruit. You hire a sales team, sales is someone else's job. With sales and recruiting, it is kind of fine, because if you do not hit your recruiting target or your sales target this year, maybe it is kind of bad, but your customers are not losing out necessarily, unless you have got serious infrastructural issues or reliability issues.
Once they have the security team in place, if they do hire one, they're just gonna distract from what really matters in building your product. My answer to this question is just not yet. You probably shouldn't. If it's something that's on your mind, there's a better way of doing it.
Your product team is, in and of itself, your security team. Much like how you have to get engineers in your engineering team to recruit other engineers, or salespeople to recruit other good salespeople that they know are good, your product engineers should just be factoring security into the product itself.
You're just creating this false dichotomy between building new features and building new features securely. They're not two different things. A good product has a really great user experience, is really nice, does the job really well, is cheap, reasonably priced, but it's also secure.
Security isn't like a feature in a product, it's just a basic expectation. It's just that the laws of statistics dictate that because security breaches don't happen to every company, it's kind of fine. But it's just table stakes at this stage, and more and more companies are becoming aware of this in twenty twenty two.
Giving you an overview of what security in twenty twenty two actually looks like, security is just this sort of walled garden approach where, again, they hire a security team or a CISO. They buy all these tools, these are actually the good tools. There's a bunch of other tools out there that aren't good.
They use encryption at rest, which is actually, I think, a scam, but I won't cover in this talk. Compliance certifications, Cloudflare, Splunk Tenable. You're just patching in reactively all of the things that you think you need to protect inside your infrastructure. It's really confusing, because you have to go through the procurement processes for all these pieces of software.
You have to manage them, you have to scale them, you have to talk to an account exec every six months when your renewal is coming up and they ask you for twice the price you paid the year before. There is just a lot going on.
It doesn't even do the job particularly well. Basically, keeping on top of security all day is potentially a full time job. I understand why people want to hire security teams, but again, don't in the short term. The biggest challenge is that modern security does not focus on the root problem itself.
We shouldn't be building walls around applications. We should be focusing on kind of the crown jewels that really matter to protect. Like, sure, there's some other security related issues outside of data when it comes to availability. Like, somebody could make you go down if you went down, your customers went down.
That would be pretty bad. But what really matters is the data that you're collecting from your customers, particularly if it's super sensitive, like credit card numbers or social security numbers or something, you wanna keep that safe. If that's the only thing your security team does, that'd be a pretty good outcome.
Sure, other people might not be happy with reliability and availability, but you can fix that, and that is sort of like a quarter long project that you just sort of improve in your infrastructure if you are an early stage company. I know in bigger companies it is a lot more involved.
This is how most of us are storing data now. Just a normal database, this structure looks pretty familiar to most of us. Here we have got names, credit card numbers, social security numbers. It is all just there in plain text. It is fine.
You create your database, you put it inside a virtual private cloud, you have a username and password on it, you think everything's good. It mostly is, lot of the time. The challenge is, once somebody gets into your infrastructure, this architecture just doesn't really make sense anymore.
The topic in general of what we're trying to solve for here is securing data itself. Data itself should be the new endpoint in security, but it's not. People treat endpoints as the main endpoints in security. Yeah, it matters if your API has an endpoint that you can just pull all the data out without authorization.
But you probably have logs. They're not gonna get your entire database. Again, it'd be really bad, but it's not as bad as an entire SQL database going missing. And the solution for all of this and treating data itself as the endpoint in security is encryption.
Encryption is very topical at the moment for many economic reasons and also for just people thinking more and more about privacy and privacy regulation and so on. Many of you probably use things like Signal. WhatsApp itself is end to end encrypted, so happens all around us.
Every time you see the green padlock on the top left of your web browser, which is rare to not see these days, encryption's happening under the hood. Encryption is just maths. But because it's just maths, there's a certain cohort of society that has a very, very strong opinion about it.
This is the first proper meme I'm gonna use in this talk. But the Jedi bell curve meme, I think, a great way of representing this. The easy thing to say would be that, Oh yeah, obviously we should just encrypt everything. But the vast majority of people who've looked at encryption or thought about encryption before just think it'll slow them down.
It'll stop them from building these new features until you're sort of an expert in encryption, of which there are very, very few. Then you're the Jedi over on the right. Again, you think you should encrypt everything. Encryption itself is a lot more simple than this meme might make it out to be, or what other people on places like Stack Overflow might make it out to be.
Encryption just lets you take a piece of data and lock it with a secret key that you then keep in a safe place. And as long as that key is kept safe, the data is kept safe. But still have to store this in your database.
And that's a fine sort of architectural design consideration and so on. But if you get access to the encrypted data, you might feel like you've sort of hit the gold mine and got access to a company's entire insensitive data set. But if they don't have the key, they can't decrypt the data, so all's good.
But what happens if somebody steals the key and they get access to the encrypted data? This is a huge deal, it actually happens all the time. People think that, oh, just by keeping the key in an environment variable somewhere in their source code, keeping their database encrypted as normal, it's way better than it was historically.
But if you get access to the application, you have the key, and then you have the encrypted data. It's pretty bad. The key is just as sensitive as the data itself, but nobody really thinks about protecting them. There's some tools out there that try to do it, but not very well.
The biggest challenge is that implementing encryption properly is just really, really hard. You have to do all these four things. You have to pick what library you're gonna use. You have to store the keys. You have to still actually touch the data itself before you encrypt it.
That's a major design consideration that people have to factor in. Then every time you wanna use it, you have to decrypt it again. And there's no point in storing data if you're not using it. This generally happens quite a lot. And as a result, encryption's almost always implemented wrong.
Even if you look at crypto companies or people building your crypto wallets, aside from some of the big players, a lot of the startups that get started in this space really don't understand how encryption works under the hood. That's a scary thing, because encryption used to just be making sure that your credit card payment on Amazon would go through.
In nineteen ninety six, when the spec for SSL got developed, this is what it was designed for. And now everything goes over the internet. If you're using cryptocurrency, that is effectively real money. You can convert that to dollars or some so called fiat currency and use it in a shop.
But data should always be encrypted. But it should be encrypted properly. Meaning, if you had a billboard in Times Square, and obviously this is a very grungy representation of Times Square, we couldn't afford the billboard, you should be able to post your entire database on a billboard, as long as it's encrypted.
If the keys are kept safe, there should be no worry about the data going missing. Going back to our architecture diagram earlier on, if this is what your database looks like now, this is what it should look like if you use encryption properly.
Hacker man gets into your database, malicious employees just really annoyed at the speed of progress, or how hard they're working or something, they wanna ruin your company, which does happen. They go into the database, all they get is this, and they don't have the keys.
Why are the keys so important? Keys are basically the architectural reason that encryption was implemented the way it is. Encryption is basically taking some way of deciphering data, or modifying data itself, and just breaking it into two parts of the risk, two equally risky components.
You've got the encrypted data, but you're just shifting the risk of that data going missing over to another piece of data. But keys are everywhere. They're generated randomly, generally. If you're using TLS in the web browser, it's just ephemeral data that gets generated by the mouse movements in your computer.
But they're all over the place, and there's almost as many keys in the world as there are pieces of encrypted data. But the tooling for managing keys really, really sucks. And this is one of the things that we were considering when we were starting EverVault is encryption is fine, but you should just use off the shelf standards there and not really innovate too much.
But managing the keys is a really, really hard problem. In Edinburgh, obviously, there's a pretty big financial industry that are pretty good at keeping money safe. But why aren't people doing the same for keys? You keep your money at the bank, not under your mattress.
You should keep your keys safe in some equivalent of a bank, not in an environment variable or a text file or an Amazon s three bucket, like many of you in the room have probably done in the past. That's where what WeBuilt comes in.
As I said, EverVault is effortless encryption infrastructure for developers that makes it really easy for them to collect sensitive data from their clients, with the data encrypted at all times, process that data using code that they write themselves, again, with the data encrypted at all times, and sharing that data with third parties.
You guessed it, again, encrypted at all times. The overall architectural difference between EverVault's design and encryption, we hope that more people implement this bank approach when it comes to encryption schemes, because we just need more people thinking about it, is that the company themselves never touches sensitive data in plain text.
It's always encrypted before it even hits their infrastructure. Happens either in the web browser or at the edge. They don't have to worry about the standards. They don't have to worry about the keys. It's just always encrypted. And our customers customers of this hypothetical crypto key bank, they never store keys, but they always store encrypted data.
Things like data residency and data locality that are very topical at the moment in the data privacy and privacy regulation space gets solved really cleanly, almost by accident by this architecture. But I'm gonna say that when we were designing it, it was pretty intentional until big customers started asking it, asking about it.
Yeah, all should be good. But people, again, think that encryption is a tax. The reality is encryption could be used for a bunch of things that people haven't really thought about. Most of us have probably thought about this basic flow where you're collecting an email address from a customer, you're storing it, you wanna use it at some point later on.
This is what it looks like with kind of the Evervolt esque architecture. But there's other things as well that people haven't thought about. Going back to the Stripe example, when they were building their software, they had to become PCI DSS compliant, which is basically an oligopolistic anti competitive compliance framework invented by Visa, MasterCard, Amex, JCB, and a few others.
That basically requires that you have a pretty robust security architecture before you can handle sensitive data. But encryption solves for a lot of this, as long as your keys are kept safe, again, at the crypto bank. And then crypto, for crypto. We have the saying that crypto means cryptography, but we're really fighting a losing battle here, so we've started to just lean into it and accept that when people talk about crypto, they're not talking about encryption.
They're talking about a quick book on Revolut trading apps or something like that. But you can keep sensitive wallet keys safe at all times and still kind of do these economic transactions without the risk of losing the keys. Because in crypto, losing the keys is as bad as losing the money.
And that's something that we're very aware of, and crypto companies are generally very aware of as well. But through no fault of their own, basically because of how universities teach encryption or don't. People just don't think about this stuff. When you're going to university and you're studying computer science, you learn how to build really performance software and really scalable software and reliable and so on, and memory efficient, when that really mattered back in the 80s and 90s.
It still does, but it matters less and less now. But nobody's really talking about security in university. We think this is probably the only reason why people aren't implementing it as widely today. It's just sort of a societal problem, when I say just, but they should be easily fixable by small curriculum changes.
But that will render crypto companies a lot more robust, I think it's something that we all need to be very aware of as we're moving to a world where crypto is dominating a lot of our economic structures. All that's to say, encryption's a super tool, and more and more people should be using it.
It's way cooler than standard CI pipelines that just make it easier to deploy your code a little bit quicker and without downtime. It actually enables new things for businesses. And this is sort of like a message that we're trying to preach. It's something that I've been talking about for ages, but it's really something that we all have to consider when we're writing code for a side project, or a new startup that we're building, or this new project at a huge company that we work at.
And developers should be empowered to use encryption all the time. And all the software that they build, going back to the point about product engineers versus security teams, they're the one thing. Developers should be empowered to build software securely, because it's just a basic expectation of what they're building.
They have the tools now, just. There's some good open source libraries. There's products like EverVault. You've got great guides online to learn about encryption, and more and more people are talking about it. So the tailwinds are just starting to turn, and it feels like twenty twenty two and beyond is just a really great time to be thinking about this more and more.
It's starting to get mature enough where you're not gonna get stuck with a product or a tool that just wasn't a good investment. It's the right time. Now we just need to wield them and use them every day, which is easier said than done.
But it's sort of an ask that I have for all of you, is to just factor this into every sort of architecture meeting you're doing every week at your company, or every day when you're writing a line of code, just think about, how could this be exploited?
Or how can I serve my customers better by making this offer more secure? We can go from a world where data breaches happen all the time to this idea of, what is a data breach? I'm glad the Keynote automation worked, because I spent a while trying to get it working in the end.
So encrypt everything and build safe software. Thank you, everybody.