 So a while ago I was at a speaker workshop and they told me what you should never do on stage is Add disclaimers to your talk or say that you're not an expert because then no one's going to believe you I'm going to do both today. I'm going to start with a disclaimer and then I'm going to Tell you that I'm not an expert. So I hope you'll still believe me in the end So first a disclaimer if you've ever been to one of my talks Most of them have been highly technical and what that means for me is that I try to stick as close as I can To the facts or to something that some people believe in called an objective truth Well, not today today. I'm also going to give you my opinion And this means that you may disagree with me that you have a different perspective that you have different ideas about security and the role of a developer in security and that's fine Please come see me after my talk and we can have a lovely conversation and maybe I can learn something from you so Today I am going to give you my opinion the second thing is I Am not a security expert So this may surprise you I'm going to talk about security, but I am a software developer So this is not only a guide for developers. It's also a guide by a developer. I am a developer That is very interested in security. I love to advocate security. I love to champion security. I love to raise Security awareness but everything that I'm going to say today is from the perspective of a developer So I am not an expert. So you don't have to believe a word that I'm going to tell you today Well, let's start with the talk itself so today the most important question that I would like to answer and it is really a very simple question is Just why are developers so important for security? That this may seem like an obvious question developers write a lot of the code that's being used So if developers write insecure code, then probably the security is going to be bad But if you ask security experts who look at this question from a different perspective They typically argue that developers are not so Important for security. They don't say that developers shouldn't be important for security But they say that developers currently are not as important for security as they should be in fact Some go even further. I was reading an article a while ago and it had this very interesting quote You know how it goes Mentioned security to your typical developer and you're likely to be met with an eye roll at best or puzzlement at worst Generally, the whole security thing is seen as someone else's problem This is quite a quote to have in your article and I didn't cherry-pick it either. This is Below a header that basically says the same and this security expert goes on for two more paragraphs Basically making this same point over and over again and this isn't an isolated article either I typically I watch a lot of security conferences and especially in like the Panel sessions there are typically security experts who make similar statements that developers They don't really seem to care about security. Well If I look at myself as a developer, I do care about security. So what is going on here? So I think we have to ask herself a different question Why do developers behave as if they don't care about security? I think this is a really important question to ask ourselves and for me When I take a step back and look at my work and look at what I'm being paid to do I think we can find a reason there because I as a developer I am paid to deliver value some kind of business value to deliver Features to deliver a new release. So my entire environment is Basically telling me we should release soon. We need these features. We need to have this competitive advantage You need to deliver this business value now over the past 20 years or so if uncle Bob is to be believed Developers have actually changed their behavior. They they are now most of them are now writing automated unit tests or an automated Testing suite they care about maintainability They use good design patterns and they will even argue for that with a product owner with a product manager With the people telling them to deliver soon or if you want to rephrase it They use their technical or their professional responsibility to argue for the quality of the features they deliver But this is difficult. So why don't developers do the same? For security, I think to understand that we have to take a trip to a different industry And it's the safety industry the industrial safety industry and there they have a very neat term and it's called safety culture and what this means is that well Everyone knows that safety is important because otherwise things blow up But knowing that a safety is important isn't enough and you shouldn't do safety just to meet the regulations to be compliant What you should do is you should make sure that everyone Believes that safety is important that everyone acts like safety is important and that everyone prioritizes safety This is what a good set having a good safety culture means in an in a company And for companies, this is really important because if you screw this up Something bad might happen like your company blowing up This was a big industrial accident in the Netherlands 10 years ago. This company no longer exists So they had a bad safety culture. That's what all the reports say they had a big accident And it was just the end of the company So now in the security world we have a similar term and it's a security culture And what this means is that if you have a good security culture, then it's not only the CTO who says well All my developers are writing secure code. So come by with us. It's not only the promotion It's not only compliance to check all the checkboxes But what this means is if you have a good security culture then people really truly internalize the Importance of security and they will argue for it. They will change your behavior for it They will prioritize it. It doesn't mean that you have to have perfect security Because that is impossible But you do have to be very aware of the kind of risks that you're taking and the kind of impact that Certain vulnerabilities may have you or certain threats may have in your in your company But there is a bit of a difference with industrial safety and That is that if you have a big security incident in your company, it may not have the same financial impact So if we just go back one year There was a series of data breaches as last pass which is right in the core in their core domain They say give us your secrets. We will keep them safe And then they had a string of data breaches now. I cannot look into their culture and organization I don't know if they have a good safety culture So I don't want to comment on that But what I do want to show is that this company is still in business And I think they had a dip in a number of customers. They have but I think they're actually Going back up again. So if you look in a security perspective having An incident that goes right to the core of your core domain Might not even be the end of your company. So there are less financial incentives to invest a lot in in security Regulators have caught on so in Europe There are now regulations that if you have a data breach you have to pay a hefty fine and those fines can be millions of euros In total so they're trying to create that financial incentive, but there is still a bit of a difference In safety in between safety culture and security culture. So why are developers so important? Well, I think that developers are important because we have to take our professional responsibility so if we are We have our responsibility for our work and we have to argue for it And this is often a bit of a negotiation. You have a project manager. You have a product owner They come to you. We want to release next week. Can you do that? Then you say well If we do that we have to cut these corners so better or not And then you start up the conversation But someone has to argue for security and because developers are typically the people who are involved for the longest in that development Process, I think there's a responsibility for developers to stand up for security culture for security to argue for that It's part of your professional responsibility But that's difficult because if you want to argue for security you have to be an expert in it, right? So to improve the security you have to be a security expert And this is a big problem Because if I look at myself if I want to become an expert in anything It's probably probably in developing software. I also do a bit of ops. I do a bit of security Sometimes I do a bit of front-end development if it's really necessary But I cannot be an expert in everything So this is a problem and I think a recent tweet by Kelsey Hightower illustrates this principle very well We cannot expect developers to become an expert in everything that idea just isn't sustainable So, how are we going to do this? How are we going to do this as developers? How are we going to make the change in development? Well today? I'm here to tell you that well You you see that hole there that check of the gun that's that needs to go off. You don't have to become a security expert you can actually Contribute to security without becoming an expert, but how do you do that without feeling lost? I think there is a very very good Initiative within the security world that that's there to help us in the security world. There is a principle of shift left And what that means is well They kind of use a caricature of the past to sell this just like how agile uses a caricature of waterfall to sell the Benefits of agile in the security world. They say we used to do security very late in the process So we used to do it at the end developers weren't involved design We didn't really care about security design. We did it in the end. We hired a team of pen testers We found a million vulnerabilities then we had to go back releases had to be delayed We had to rewrite stuff redesign stuff a lot of costs associated with it So we shouldn't do that. We should take security and shift it left Now obviously if you just take security and shift it left and then don't care about security after That's also not good. So actually some people are arguing for start left So you should consider security throughout your entire software development life cycle So and why is that important for us? This means that now a lot more people are writing resources That tell you how to do security as a developer. We don't have to reinvent the wheel and That is really important for us developers We can just look at resources online and all of the things that we can do they are not rocket science Nothing that I'm going to tell you today is rocket science You don't have to be an expert to implement them and that is basically what I'm going to tell you in the rest of my talk I'm going to tell you how you can navigate that landscape. How you can learn about security How you can apply that in your work without feeling overwhelmed. So why is that important? Well, let's zoom in on the first security principle that I want to show you today And it's a term called defense in depth. It's typically illustrated with a castle And what this means is that if you want to do security? Well, you cannot rely on a single security measure So here you have a castle and if you look at this castle, you have a mode So if you want to get into castle, you first have to cross the mode that you have to get past the wall And then you're in the inner courtyard But all the treasures are in the actual castle, which is a fortification onto itself So you still have to make it into the castle there guards everywhere rooms are locked So you have multiple layers of security. This is what defense in depth means And this also illustrates why developers are important a lot of companies these days that buy a vendor An on-premise cloud environment. They invest a lot in edge security So if not if nothing gets into your systems, then we're safe, right? But the problem is every layer has holes So if we ignore the part in the middle where the developers write the applications we can still get in So that is why in a true start left or shift left environment developers are very important In the safety industry they typically Illustrated with this model. This is the Swiss cheese model by James reason I'm not really going to go into it But there is one important point to make here in this model you have various barriers between Normal and a disaster or in our case a security breach And the realization is that there are always holes in barriers So in software, you might have a zero-day Vulnerability just lying to wait there for someone to pick it up You might have a misconfigured firewall And we call those things latent conditions there are holes that are always there in your system But you might also have active failures for instance You might have a user of your system handing out their past password in a phishing attack Handing them the keys to an application So in this model and I think that's really cool You have latent conditions and active failures that were holes in your system everywhere But once those holes align That's when we need to get in and that is why developers are important We are responsible for some of those layers and we should implement them This is enough about industrial safety if you want to know more. This is a good book Which has a lot of overlap with security. It's a nice book to read so what can you do to prevent those holes in your project and This isn't rocket science. I'm not going to tell you anything that's really difficult But I'm just going to show you how I do it So in my opinion for me, there are three main pillars and the first thing is that you have to learn about secure design principles And I don't mean about big architecture principles that you have to design into your system But coding patterns just like you learn about repositories and observer patterns and stuff like that There are also secure coding patterns that help you keep your code and application secure look into them practice with them The second thing is There are a lot of mature security practices these days look into them adopt them They're often very easy a lot of them are automated which I love as a developer There are a lot of tools that we can use use those tools get familiar with them and finally know how to mitigate Common vulnerabilities and this one is really important. There are a lot of top 10 lists out there But I'm just I'm going to tell you later that that is not enough So these are main my main three pillars for the first I'm not really going to take you through a long list of design principles. I'm sure you can all Google It would be a bit of a waste of our time to go past everyone. I've selected a few here The the extra cards under under validate input indicate that there are a lot more to find But I do want to zoom in on the first one and this is one that I've encountered in Production a lot of times I sometimes do code reviews for other projects And this is the no and less principle And if there's one thing that if you go home that you should check is if you're doing no and less or deny by default Which is a different name for the same thing. So what am I talking about? Well, let's say that you're using a nice API framework in Python If you create an API endpoint in Python It's really easy in most frameworks like fast API Django flask You just write a function or a class you map her out to it and hooray everything works But what this means is if you just create an endpoint it is open by default. There's no authentication There's no authorization and This also means if that's someone if someone refactors your codes and down the line You have no mitigations in place During that refactor that decorator may accidentally disappear or someone Has a really complicated feature to build with a lot of business logic and everyone is focused on the functionality And then they forgot to add that base class to the inheritance list of the class. So if you have Yes, unless and you forget something then suddenly something is open So what I typically try to do is I try to invert that it's denied by default unless There is something that gives someone access and this is a principle that you can do today And this is one that I think I've reviewed five or six projects over the last two years This was present in at least four of them most were minor one was very major. So The second thing that I want to talk about is mature security practices And this again is going to be an introduction in how you can learn about mature security practices because I can talk about this For two hours and I only have about 11 minutes left So mature security practices mean that you just have practices that help you enhance security So, how do you know what they are? Well, luckily in the security industry people love standards And we as a developer we don't have to look at standards to see if we're compliant But we can use them as a guide and not every standard is as accessible to us developers As the other one. So if you look at this slide, I've made it Kind of like a hierarchy of standards in terms of high-level abstractness to low-level close to the doing and I'm going to show you one That's really close to the doing that basically just tells you you can do this and your project is more secure So right at the top. There's one that maybe some of you already know which is an ISO standard 27001 and this is really abstract if you look at this standard in detail It doesn't really tell me what to do as a developer I can't take the rules from this standard to my workflow and know what to do Luckily below that there's a model called the software assurance maturity model or SAM for short This is by an organization called OSP. They recently re-branded from the open web application security program to the open worldwide application security program just to highlight that it's not just about web development And I really like this organization because of their logo. They're called OSP So their logo is a wasp inside of an Oh, which I think is really cool So if you look at this model, you'll find something like create a formal definition of the build process so that it becomes Consistent and repeatable. This is already more concrete as a developer I can already kind of imagine what I can do to make my builds more secure But it's still a little bit removed from the actual practices that I have to do And that's why there is a fairly recent project, which is the oh wasp DevSecOps maturity model Now DevSecOps is just DevOps plus sec Or D some for short and this is much closer to the doing still so in the in the D some model you might find a practice that maps to the build process like pinning of artifacts You do have to learn the security lingo a little bit But if you pin your artifacts your dependencies to images that you're using that is one way to ensure that your build is more repeatable So if you zoom in on that project, you're going to find a lot of practices that you can just do today I do have to mention I adapted this sheet from a talk by Timo Pajol. I asked for permission and he was okay He's one of the leads on that model I do want to show you a little bit what's in that model So if we zoom in on the oh wasp DevSecOps maturity model, how can you use it as a guide? That's actually a really simple model You can just look it up online. It has five dimensions And again the disclaimer the terminology here is slightly different than how we use it as developers So testing and verification is mostly about verifying and testing security although unit tests are also in there But if you then zoom into one of those dimensions like build and deployment you'll find sub-dimensions build deployment patch management They are really familiar to us And if you then look at something like patch management, you're going to get a hierarchy of practices that you can do today That you can just implement in your workflow. So here are a number of practices Practices rated against several maturity levels I've heard that some security experts don't really like the gaps in this because that messes with their scores But for me as a developer, I don't really care about that I can just look at this and say hey What's what do we mean by nightly builds and should I do them and I can look up what nightly builds are and Bit of a spoiler. They're not the nightly builds that I was used to when I was younger I grabbed the latest nightly build of a Linux distro and wrecked my computer every day What they mean by this is if you have a built pipeline Just run it every night. You don't have to actually go to deployment But most of your automated tooling security scanners dependency scanners They are in your pipeline and if you have a long-running surface that you rarely update Chances are that you've not run your build pipeline for weeks sometimes months So just schedule a pipeline run every night and make sure that if your scanners now fill because the security Definitions have been updated that you get an alert in the morning So you know that you have some work to do and this is a very simple practice that you can start doing today and Now for those long-running applications. You just get alerts about outdated dependencies and stuff like that. There are also Related techniques in here like automated patch PRs, but these are really simple things that you can do There are also some dimensions in here that you might not check out as a developer And I urge you urge you to do so. Anyway, so this is the culture and organization and then specifically the design Subdimension this mostly has to do with stuff Like how are you going to make sure that you design security securely in your organization? And you might not feel as Familiar with this as a developer, but there's a technique in here It's called simple threat modeling which I think is really important and everyone should check out what this means Is that if you're in a very early stage of your project? You should just think about what are the threats that that are potentially in this project? How severe are those threats? What is the impact? What is the risk? And then you can get an idea of the things that you should think about while designing your application while implementing your application I say ideally you do such a workshop with a security expert who knows how to run these But if you don't have one just do it yourself Grab a whiteboard start drawing your routes and your relationships between your services And just analyze what are the vulnerable bits and make sure that your design counteracts that and not only at the start If you're going to make a major change, please do another threat modeling session so for instance if you run a webshop and you're expecting a Christmas sale and You expect a big run on your website and you want to make your website more performant You're going to change all your caching rules. Do another threat modeling session. What are the threats there? Should we mitigate some stuff? Should we build and test to? Not cash too too much things because if you don't you might end up like steam They were heading to their one of their famous Christmas sales Someone ramped up all the caching and they started caching individual account pages Which meant that if customer a was the first in a caching period they added stuff to their shopping cart Then the next customer would see that the shopping cart of the previous customer What's worse if this happens with credit card information if you visit your own payment information And you see that of the previous visitor. That's obviously not a good idea So you can make a threat model you can analyze what is the sensitive information? What is The not so sensitive information. What is it that we can cash and you can take steps to prevent failures? Don't rely on memory. You can build a security integration tests that just Verifies that you're not caching something sensitive so that if someone a year later changes to config You don't make the same mistake, but in a threat modeling session. You can think about such changes Well, and finally No common vulnerabilities. I think this one is pretty obvious There are a lot of top ten lists out there that list the most common vulnerabilities now I hope none of you are just formatting in raw Arguments into your SQL statements. So I do urge you to dive a little bit deeper into all those vulnerabilities I also urge you not to stay passive. I don't really like reading passive lists But there are a lot of challenge websites out there that have a vulnerable website and they ask you find the vulnerability And that's a great way to not only get to know the vulnerability But to also see the impact and a lot of those websites also have common techniques to mitigate those vulnerabilities So don't reinvent the wheel and finally and I think this personally this is the most important one If there are vulnerabilities that are identified within your own projects share them with your colleagues Don't be afraid. Don't shame each other. Don't put the blame on each other But if there are certain vulnerabilities that in your domain are in specially important It's important to talk about them and that is probably one of the most important things if you're handling a lot of PII personally Identifiable information and you've noticed that you're logging that in production and it goes to vendors That's a data breach personal information is now with another company You've lost control of re information if you discover that talk about it to other developers because they may be doing the same thing So that is really important Well and to wrap it up if you do want to implement stuff take it slow Don't add six security scanners to your pipeline overnight Because the only thing that you're going to teach yourself is how to ignore those millions of alerts that you're getting So take it slow take it one step at a time. You don't want to teach people how to ignore good security advice You also have to be pragmatic and it's kind of related to the first point You don't have to be here You don't have to compare yourself with the biggest companies out there, but if you're currently here work on Getting to this maturity level first be pragmatic about it and also always make a cost-benefit Benefit analysis. That's what your threat modeling is for and also be vocal We can only truly build a security culture if we do it together if you talk to your fellow developers if you organize a Capture the flag exploit this vulnerability workshop together do stuff so that you make security a topic that is talked about in your company and if you're Confident do also talk about it with people higher up in the company So that you also get the support from your product managers from your product Owners from your CTOs out there. So be vocal and that's all we have time for today This was me the slides are available on discord in the talk slides and artifacts channel or whatever it's called And thank you very much