Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Making Sense of Application Security

Making Sense of Application Security



Adib Saikali provides a roadmap for application developers and architects to master application security, identifying the security skills needed as an application developer.


Adib Saikali is passionate about technology and entrepreneurship from assembly to JavaScript from pitching venture capitalists to advising senior IT executives at Fortune 500. Adib is currently a Principal Platform Architect at VMware.

About the conference

InfoQ Live is a virtual event designed for you, the modern software practitioner. Take part in facilitated sessions with world-class practitioners. Hear from software leaders at our optional InfoQ Roundtables.


Saikali: Welcome to my talk, making sense of application security. This talk is an application developer's guide to all of the foundational things that you should know about security. The kinds of things that helps you debug tricky exceptions without having to visit lots of blog sites and Stack Overflow and trial and error your way to eliminating an exception, for example.

My name is Adib Saikali. I am a software developer, been a software developer since 1995, and a Code Janitor since 2014. I'm currently a Global Field Principal at VMware Tanzu. That basically means I spend enormous amounts of times doing things with Kubernetes, Cloud Foundry, Spring, and a lot of time in customer code bases, that are multiple millions of lines long with like making them a billion dollars a year, and really advise customers on how to go towards modular monoliths or microservice architectures. I've accumulated a lot of patterns on how to refactor and modernize applications. Security has been a big part of that. One of the things I've observed is that developers struggle with security a lot. Because it's one of those things that one person on the team does, and then everybody else doesn't have to do it. You do it once a year, and so you every time have to remember and re-Google how to do it. I'm also currently working on a book called Securing Cloud Applications for Manning Publications. You can buy it and start reading the chapters as I finish them.

Why We Should Care About Application Security

Why should you care about security? You should care about it because it's a CEO level problem. What I mean by that is, if there's a large enough security incident, either your company is going to go bankrupt and shut down, or potentially more likely, the CEO is going to get fired. A good example of that is the Equifax CEO who did resign after that massive data breach they had in 2017, and so did a bunch of other senior executives. What are CEOs doing about this? CEOs, for the most part, are not developers or technical people. What they're doing is they're actually creating this, they have this role of chief information security officer. This is the individual responsible for the security of the enterprise, and they report directly to the CEO so that they can drive the transformation of the organization's security practices to whatever is needed to make it more secure. Even the U.S. president is getting in on the action. President Biden has issued two executive orders in the past year or so around how to improve security and requirements for secure infrastructure and applications in the U.S. government.

What AppSec Means for App Developers

With this extreme focus from executives on security, what does that mean for you as an application developer? I think it actually means four things. Number one, is you're expected to use all product security features. For example, if a database you're using has an option to allow you to encrypt data at rest, turn that on. If you are making a call from one microservice to another, you can make that call over mutual TLS as opposed to over a plain, regular non-encrypted channel. The other thing that's expected of you is to follow corporate security standards. More organizations have published standards that say, when you do certain things like a service calls another service, or when you go to a database and you want to access it, you have a password for the database, where does that password get stored? How is it managed? Thirdly, there's just general expectation that you're going to be able to design and implement secure applications, which I think is a reasonable assumption in 2022. In order to design and implement secure applications, there's foundational things about security that you need to be familiar with. Lastly, in all of these organizations I talk to, there is a transformation program around doing more DevSecOps. You are the developer in the DevSecOps tool chain or process.

What Senior Business Leaders Want

If we take a step back and say, let's double click on those four things, how do we go about doing those? If you look at it from the point of view of the senior business leaders at the top of the pyramid, they just want a secure application. In order to do a secure application, you as the developer need to do two things. Number one, is you need to write your code using some programming language using the libraries of that language, and that framework. For example, maybe you're a Java developer building Spring Boot applications running on Kubernetes, which is then running on a public cloud. The second part is that you follow the corporate standards for secure software development lifecycle. When you start doing that middle layer, people usually get stuck. They get stuck because there's something about the underlying layer that they don't understand.

For example, let's say you're configuring Spring Security to allow you to log in with your Google account into the application. You have to provide it with this thing called a client ID and a client secret, because it implements something called the OpenID Connect protocol. The documentation for Spring Security is not going to teach you the OpenID Connect protocol, you're expected to show up to the party knowing that protocol. If you want to avoid getting stuck, what you want to focus on as a developer is the bottom layer of the pyramid. If you learn the bottom layer of the pyramid, you can always more easily learn the second layer, the middle layer of the pyramid whenever you need to. That's really what I want to talk to you a little bit about, in particular, that standards, protocols, and patterns that's in the bottom left corner of the pyramid.

Key Security Skills for Application Developers

If we extract from that bottom left corner, what are the four things that you may want to focus on? It's going to be, number one, secure your communication channels between your application and everywhere else using TLS. Number two is implement single sign-on in your applications, and try to get rid of passwords. You don't want to store them in your app. You don't want your users to have them either. Number three is you want to manage your credentials securely, all those API keys, database passwords, that your application might have. Number four, is when you have a microservice architecture, and you have one service calling another service, calling another service, you need a way to secure that call chain. We'll talk about some of these. Again, my purpose here isn't to solve these problems, but to more guide you as a developer on the things and then the direction that you need to go with.

Typical Legacy Enterprise App

What does securing communication channels mean? Let's take a look at a classic typical legacy enterprise application, the simplest things of all. We have a three-tier application with some JSON HTTP coming in from a mobile app or a web browser, going to a monolithic backend, and going to a SQL database. When you think in terms of security from the enterprise, people will come back and they will say something like, I'm going to put firewalls on here. What does putting firewalls do? It assumes that you have this network zone that usually people call the red zone, where that's exposed to the internet, maybe bad actors could get in. We're going to have a firewall to basically say, the application server will only accept requests from a load balancer, and the database will only accept requests from the application server. This idea of segmenting the network into zones so that you can say the green zone is where I can keep my data, the yellow zone is where I keep my business logic, and the red zone is that edge to the internet that I have.

The key thing here is that this is not enough, because you can have a bad actor internally, you're not the only application on the network. There could be other applications that have security issues, and they break down. There's this move towards doing everything with zero trust. We don't want the application server to trust the network, we want it to assume that its communication from the load balancer has to come in over mutual TLS, so the application server can make sure that the request only came from the load balancer. The load balancer can make sure that it sent the request to the application server. Similarly, the application server wants to know that it connected to the correct database. The database wants to know that the application server is the right application server talking to it. This means as a developer, you're expected to be in more situations where TLS is being used. It used to be that TLS was just something you did at the edge of the network between the internet and your load balancer.

How to Learn Cryptography as a Developer

What do you have to know in order to understand this? There's a lot that you need to know. This mind map here shows you how you need to approach this. There's a lot of stuff on here. It's possible when you go through this to get lost in all of the cryptography rules. If you're looking at this and you're like, I got to learn encryption. There's this thing called authenticated encryption. What does that mean? There's this elliptic curves, and key exchange, and certificates, and perfect forward secrecy, and all the different tradeoffs that cipher suites represent? I'm overwhelmed as a developer, what do I do? My advice to you is to think about cryptography not in terms of the math that it's implemented in, although that's very fascinating, but to think of cryptography as a set of primitives that are like black boxes, tools in your toolbox. You bring out different cryptographic primitives for different purposes. For each cryptographic primitive, it always provides you some security guarantees. For example, AES with authenticated encryption allows you to make sure that data is not only confidential, but you can detect if somebody has modified the encrypted data. You have to know how to configure it correctly. Because, unfortunately, some of these standards have settings on them that are no longer secure, because there were breakthroughs in attacking these algorithms. Or maybe just the computers got faster, and they're no longer considered secure.

These primitives can also be misused, so it's important that you understand the wrong ways of using them so you can avoid using it incorrectly. Lastly, you got to write some code using these primitives. It turns out that some cryptographic libraries out there are hard to use, because they assume that you're an expert, and it's easy to do the wrong thing with them. Then the end result is an insecure application. It's always important to find a high quality implementation of one of those libraries. Finally, you got to learn how these cryptographic primitives come together into a protocol like TLS.

Problem 1: Detect Accidental Data

My most important recommendation to you is to actually wrap your head around these cryptographic primitives by looking at some simple problems that are realistic, things that you may actually encounter in the real world. I've got four problems for you to think about, and try to implement in your favorite programming language. On subsequent slides I also include links to a GitHub Org that has solutions to these in Java and Spring. Number one is, think about it as I want to detect accidental data corruption. In this scenario, you're a shoe retailer who sells shoes online. People return shoes they don't like. They arrive at your warehouse, and the warehouse employees look at the shoes that have been returned, check that they meet the return criteria. Then use the warehouse management application to approve a refund. That's awesome. Then, what happens is that the warehouse management system generates a refunds.json. Think of it as having like an order number, say order number 123, is going to get a $50 refund. Then that is filed. The refunds.json goes on to the Payment Service, where the Payment Service is able to look at the Order ID and the amount to refund, and actually return the money to the credit card of the customer.

The problem we're solving here is not even a security problem. We just want to basically say, how does the Payment Service make sure that the refunds.json is actually correct? It wasn't accidentally data corrupted because there was a disk error, for example, or a network transfer error? The answer to that is you could use something called the Secure Hash Function to do that, and calculate a signature. That's a problem for you to go to figure out how to solve on your own.

Problem 2: Detect Tampering and Validate Identity of File Creator

Number two is, now you're like exactly the same scenario but this time the Payment Service wants to know that the warehouse management service was the one that generated the refunds.json file, and it wasn't some rogue employee or hacker. Now what we say is that, the warehouse management application is going to sign the refunds.json file with a secret key that it knows. The Payment Service is going to read that refunds.json, and use that secret key to not only detect corruption of the data but also check that the only way this refunds.json could have been created was by somebody who possessed that secret key. That takes you to what's called the Hash Message Authentication Code that was on my mind map earlier. Really simple to implement in something like Java, and incredibly useful as a foundational concept to wrap your head around.

Problem 3: Detect Corruption, Tampering, and Privacy of File Contents

The next requirement is, ok, I've got this refunds.json file, but it's in plaintext. What I'd like to do is to encrypt it, so if somebody intercepts it, they cannot see what's in the refunds.json. That's where this idea of the Advanced Encryption Standard will come in, and you can do this with the Advanced Encryption Standard.

Problem 4: Solve Problem 1, 2, 3 without Using a Shared Secret

The next complication of the problem is, I have this shared secret, the warehouse management needs to know the password that was used to encrypt the refunds.json file, and the Payment Service needs the password in order to decrypt that. Sharing keys between things is a really hard problem. This is where public key cryptography comes in, and you can learn by solving this with a sample I've linked from a GitHub repo. You can learn how to actually do this using what's called a Diffie-Hellman key exchange with the JOSE suite of libraries. I built it in such a way that it's simple for a developer to follow along, again, with the goal of just understanding the concept, not really actually doing it like the way I would solve it here, because you just use TLS for that.

Standards to Learn

This is a list of all the things that you might want to know as a developer. For Java libraries, if you're looking for stuff, I recommend the Google Tink library. It's a developer friendly API for doing cryptography in general in Java and other languages, which is used by Google in production. It's designed to allow you to not accidentally do the wrong thing.

Logging in Human Users

The next problem we run into is, we have all these users, we need to log them in. How do we do them, and we really don't like passwords anymore. The answer to that is when we look at what do people want to do? How do they want to log in again? Think of the shoe retailer, ACME's web shopping application. You might have a user who wants to log in with their thumbprint from their MacBook, another one wants to log in with the face ID on their iPhone. Somebody else wants to log in with their Facebook account, and somebody else wants to just use a plain old username and password. Those are all ways that you have to log in. Do you have to actually support all these ways to log in inside your app? The answer is no. What you should be doing is you should be delegating all of that into some single sign-on service. You can get these single sign-on services from the cloud, like a SaaS offering, things like Auth0 and Okta. Or you can write your own single sign-on service, maybe on top of something like Spring authorization server, or you could use a prepackaged authorization server that's built into a platform that you're using that comes with a larger platform maybe based on Kubernetes. The key thing here is that you as a developer only learn one protocol, which is the OpenID Connect protocol. That allows you to interact with all single sign-on servers, regardless of who wrote them, if that single sign-on server supports the OpenID Connect protocol.

Use a Phishing Resistant Hardware Key

However, even with all of these, when you do have that single sign-on server, you probably want to configure it to be phishing resistant. Hackers are getting very sophisticated, and they'll create a fake website that looks just like your bank's website. They'll send you a text message, and this and that, to try to trick you into going to this fake website and actually entering your real username and password, and potentially your real one-time password, and get it. One of the ways to get around that is you can use something like this guy here. It's a hardware security key. Let me just demonstrate how that works. I'm going to plug it into my MacBook. I'm going to switch over here to my GitHub. When I try to sign in, it's going to say, your password was correct but I need you to use security keys. I'm going to say, yes, use a security key. Now it pops up and says, which security key do you want to use? I want to use the USB that I just plugged in. It's flashing, but when I press it, I'm in. What that security key is doing is it's checking that I'm actually talking to GitHub, so I don't accidentally say yes to a website that is a phishing site.

Web Authentication Protocol

Another really exciting technology that you want to know about as a developer is something called web authentication. This is a protocol that allows you to really register users without ever asking them for a password. For example, I have my YubiKey plugged into my laptop right now. If I go here, and I say Adib Saikali, and I click on Register. It's going to say, ok, how are you going to authenticate yourself? I'm going to use my hardware key. That's going on. I'm going to press the button again, success. Let me log in now. When I log in, how would you like to log in? I'd like to use my hardware security key, please. I'm in. You can see here it actually knows who I am. It's given me a user ID and it's given me a public key. This Web Authentication Protocol actually works with all web browsers. This works on your iPhone, Android, Mac, Windows. It's pretty prevalent these days. As you can see, this is wonderful for user experience, because how do you even have to sit there and come up with a password? What are the password rules for? How many characters and special characters and capital letters? You take that frustration out of the process. Bottom line is, as a developer, go ahead, learn OpenID Connect and learn web authentication.

Managing Credentials Securely

The next thing we want to talk about is credentials. How do you store them? You've got your monolithic app, and you've got a database password and an API key for the credit card processing API. Where do you store those keys? You should most definitely not store them in a text file on a server, because that's easy for somebody to steal. You should put them in what's called a credential service. The credential services are available from the cloud providers like Google KMS, or Azure Key Vault, or you can install your own vaults like HashiCorp Vault. That is very much a learn-the-credential vault that you have access to in your organization first. Once you learn how to use one of those vaults, it's easy to learn other vaults later on. Bottom line, two things you should know about as a developer, know about OpenID Connect, know about web authentication, and learn how to use your credential service, that's part of your organization.

Securing the Service-to-Service Call Chain

The last problem we want to talk about is the service-to-service call chain. Let's actually break it down with a concrete example. Let's say I have a webpage that looks like this, a product catalog. I've highlighted in the squares where some of the microservices might exist on the page. For example, you might have a price discount calculation service that factors in what marketing promotions are going on right now to assemble the page. If we take a step back, we'll say, we've got a product service page. It calls a book detail service to get the details of the book. Calls the pricing service, which in turn calls the buying habits service, to find out what you're buying habits are. Factor that into how much discount you're getting, and whatever current marketing promotions are happening. This example can be generalized into this thing over here, whereby you have some external clients, requests enter at the edge microservice layer, and the microservice at the edge call other microservices down the chain. As you can see here with the service J in the bottom right corner, service J might want to know, who is the actual human at the other side of this application? Is it Adib or not? Whereas microservice H there in the middle, it basically says I don't care who Adib is, who the user is, but I do need to know who called me? Was it microservice B, or was it microservice E? This is the idea of service identity versus user identity. It's important to actually know both at all times.

This gets a little bit more complicated, because the lines on the diagram earlier were not really one protocol. I could have a situation where from the user to my edge microservice, it's over HTTP, and that's written, that's a Java service, which uses OpenID Connect and web authentication to log the user in. You can then have that edge microservice in Java making an HTTP REST call to an internal microservice written in C#, which uses gRPC to call an internal service written in Go, which posts the message on a RabittMQ broker using the AMQP protocol, which is then picked up by a JavaScript Node.js service that is using AMQP. Looking at propagating user identity down the call chain, or service identity, you run into, how do I do that, or the variety of protocols that exist?

I have some bad news for you. There is no industry standard way of doing this, no app. There are patterns that can be used to solve this problem. The most important of those patterns is that you should use mutual TLS everywhere. Every service-to-service call should be over mutual TLS. Even if it's going over messaging, you need to do it twice, on both ends. That's why you need to be really good at TLS as a developer. Then, for the user identity, you've seen lots of ways to do it. People typically will say, I'm going to take a JWT token that describes the user, and signed by the login server, and I will just pass that down the chain and maybe bind it to a request with another signature or something like that. Lots of patterns that you can learn. However, if you know TLS, if you learn TLS, you will have the cryptography background to more easily understand this type of thing. Practically, there's lots of infrastructure pieces that can help you with it. For example, if you might have a service mesh available in your Kubernetes cluster, that could be very helpful for implementing this or an API gateway.


I want to take a step back and say, as a developer looking to upskill yourself in security, here's what I would do if I were you. I would start on this pyramid in the bottom left corner and focus on learning the standards and protocols. Set the goal for yourself to get really good at TLS, because that will force you to learn a lot of basic cryptography. Then, after you've figured that out, actually get good with a particular framework or language. For example, maybe you learn Spring Authorization Server, or Spring Security, Spring Cloud Gateway, and you learn how to put something together in Java, if you're a Java dev. Then you also got to focus on learning some industry best practices, maybe like, how do I containerize my workload security?

Standards to Learn

Next, I just have some technologies and suggestions for things you may want to learn. Here's my list of standards to learn to wrap your head around cryptography. Number one is what Secure Hash Function is, SHA-2 and SHA-3. Then learn about the Advanced Encryption Standard, in particular, the mode called authenticated encryption with associated data. What does that do? Then learn a bit about the JSON Object Signing and Encryption, because that's used in the OpenID Connect protocol, so it helps you learn that later. Plus, it gives you some cool practical technologies you can use. You can't escape knowing X.509 digital certificates, they're part of TLS. You got to obviously learn TLS. You can learn the OpenID Connect protocol for the purpose of logging users in. The Web Authentication Protocol, so you can do these passwordless logins. Then finally, the Secure Production Framework for Everyone, or SPIFFE is an emerging standard for how to bootstrap trust. That really helps with solving some of the difficult problems in the service-to-service call chain scenario.

Frameworks for Java Developers

For Java frameworks, I recommend Google Tink, Nimbus for JOSE. Spring Security is just a general java security framework. The Spring Authorization Server is a brand new project from the Spring team, which gives you all the infrastructure you need to build your own custom SSL server. This can be handy when you're trying to integrate with legacy environments where you have a non-standard internal service. There's also Spring Cloud Gateway, which is wonderful for implementing a lot of patterns around the service-to-service call chain.

Cloud Infra

Finally, for cloud infrastructure, I'm assuming you're doing stuff on Kubernetes because that's emerged as the industry standard these days for cloud native. How do you containerize securely? Highly suggest you learn about something Called Cloud Native Buildpacks, for building a process to keep your containers patched all the time. Obviously, you got to learn how to run applications on Kubernetes in secure ways. There's concepts on service mesh, like Istio. SPIRE is the runtime environment for SPIFFE, so that's useful to know. Of course, whatever key vault you happen to have available in your environment.

Questions and Answers

Losio: The first question was really about TLS. That was, what if I run two different services inside the same container, or same cluster, or whatever, what's really the benefit to do encryption using TLS or any kind of encryption? Here we are always assuming that we keep running for life inside the same cluster. Any thought or any feedback?

Saikali: In my line of business, I spend most of my time with customers, and there's this kind of always the magical tool that's going to mean you need to know less as a developer. I have yet to meet this tool. It doesn't matter what it is. I remember back in the day when Hibernate came out, it was like, you don't need to know SQL. Of course, you needed to know SQL sometimes better because, yes, I don't have to spend all my time writing SQL statements but I need to know what my tools are using. I have maybe not a different perspective. The perspective I run into is a whole lot of people basically say your infrastructure is going to take care of things for you, and you don't have to know anything as a developer. You don't have to know anything about TLS. You don't have to know anything about mutual TLS. A lot of security people have really given up on developers learning security. I'm the opposite of that. I actually have a very strong belief in the potential of developers to increase their security skills and what that means for the industry.

From my point of view, you don't have to be an expert in TLS to learn the basics of TLS, and then you can configure your service mesh better, if you have a service mesh. You can participate more meaningfully in interactions with customers. I've seen insane stuff happen, where people basically thought that certain things gave them security when they didn't. There were certain things that really did give them security and they thought they didn't secure things. I think it's a worthy goal for developers to learn TLS to a level that a developer needs to understand TLS, not to the level where you're implementing the protocol. Just like you drive your car, you learn the rules of the road. It's the same thing, why not learn TLS?

Losio: Actually, you raised another very good point, something that I was thinking when you started your presentation, talking about cloud services and things that are very available to use. I was thinking, even sometimes the cloud provider make things even too easy that if with a click of a button with just a true, false in an API call, I can encrypt data. Think about Amazon S3, I can encrypt data. When I store my data, I can say, encrypt by default with the default key, whatever. The problem is, on one side, if it's easy enough that you should really do it, why not? On the other side, it's easy enough that you might not even know what you're doing, and assume that it's much more than what that service is doing. You think, my data is secure just because I enable that. I think it is back to your problem of saying that, yes, you need to know, more or less, not just what the service provider, what test tool is there, but what it's supposed to do.

Saikali: I 100% agree. It's really because what I find in all of the different customer engagements I've been on for the last seven years, there's always a point in the process where you get to go talk to InfoSec. They want to know how this application is secure. At that point is where you run into the issues of, can you speak the InfoSec's language or is this all a black box? If they see that you are more knowledgeable about security, you can have a more fruitful conversation, and you can more easily get your application approved to go to production. If you don't, then you're going to struggle just getting through that internal review process and it may cause project delays. I've seen both of those situations pan out. For me, as a developer, I look at technologies from, what should I focus my energy on? What should I learn?

I use this model from Scott Ambler, where he talks about if you learn a paradigm, that knowledge is good for 25 years, if you learn a particular platform or technology, it's only good for 10 years. For example, if you learned Kubernetes in 2015, you could charge whatever hourly rate you want, but you can bet that in three years, everybody that wants to know Kubernetes, knows Kubernetes, or needs to know Kubernetes knows Kubernetes. Over time, a lot of these technologies, they lose their value of the knowledge, but some of the things at the core of security, they're never going to lose their value. If you learn what a cryptographic hash function is, and how AES works, these things are going to be around for a very long time, or TLS. The details will change. There'll be a new version of the protocol. There'll be a new version of the algorithm, but that's timeless knowledge, in my opinion, for a developer far more useful than learning how to use a service mesh right now. If you have 10 hours to learn something and your choice is learn TLS or learn service mesh, go learn TLS. You're going to use that TLS knowledge for the rest of your career. Service mesh, who knows how long that'll be useful for?

Losio: Actually, there was something you mentioned in the beginning that I found quite interesting, was when you said basic application security is a CEO level problem, because the CEO can define that as well, how management is concerned about safety. I was thinking basically of two different scenarios. One is, I'm a software developer in a large corporation. In reality, I might be worried about the reputation of my company, but not too much about the CEO. I think like, it's his problem, it's there. If he gets fired. That's not the reason why I'm implementing security. That's the first problem. On a more realistic level, I was thinking more in the startup scenario, where I'm not saying that people don't care about security, but it's usually not high on the agenda because even the concept of risk is on a different level. If you tell a CEO of a startup that is trying to survive, make it through in very short time, if you say there's a risk that your application gets hacked, and you're going to lose everything. He is probably going to tell you, there's a very high risk that I'm going to lose everything anyway. How do you get that mindset more so in the startup world, in a new company, when the pressure is just to get fast, get big, and whatever?

Saikali: Let's break down those two scenarios. Let's say you're the enterprise developer working in a Mega Corp with 5000 other developers, and you're like, CEO, who cares? The CEO is going to go buy a private island, I don't care if they get fired. They have lots of money to play. That's actually true, so I don't care as a developer about the fate of the CEO. What I do care about is the quality of the tools that I'm using. What I see in a lot of these Mega Corps is really archaic processes, where it's like, you would like to use something that makes your life better as a developer, but you're not allowed to, or why aren't you allowed to, because information security needs to approve it. Why doesn't information security approve it? Because they're scared to approve anything that isn't already approved? Because that senior vice president who runs the security team doesn't want to get fired. It has an impact on you. My call to action is, there's like a cultural change that we need to go through as an industry around security. That's what we have to do.

I'll give you a really interesting story. On Sunday, I hosted a Matrix Resurrections watching party, and invited a bunch of family and friends, including my electrician who did the Reno in my house, because he helped me set up the TV. When he showed up, he's like, my Google account got hacked, and all these people started buying laptops with my credit card and all the stuff that was saved. The mistake he did was he signed in on some unknown computer with his Google ID, with his personal ID, and the hack started. He was showing me off his Google key that he bought, the hardware key, the equivalent of the YubiKey. I was having to explain to him like, yes, never ever log in. These things have real world consequences. You should care about this as a developer. Just change your attitude around security. That's number one.

In the startup world, startups are starting to get more complicated. The cost of launching a startup in 2022 is significantly higher than it was in 1995, or even 2000, or 2012. I look at it from the point of view, how many hours do I need to invest to learn the security stuff as a developer? How much more valuable I am. Security isn't hard to do if you know how to do it. It's difficult to do when you don't know how to do it. The other side about not knowing the security stuff as a developer in a startup is like, how much time are you going to waste on Stack Overflow, "I got a TLS handshake error when I called this thing or that thing." You waste more time because you didn't take the time to learn it. This is why I'm putting this book together. I am not "a security professional." I am basically saying, I want to explain the basics of security to software developers in a way that makes sense to security developers, so security developers can have a seat at the table with the wider InfoSec community and enable that higher, more meaningful communication. Where the InfoSec people don't just literally say developers can't be trusted, because they don't know anything about security.


See more presentations with transcripts


Recorded at:

Jul 01, 2022