Transcript
Stefania Chaplin: I am going to be doing a talk, “Secure by Design: Building Security into Engineering Workflows and Teams”. You’re here to learn from me. I would love to learn from you. I’ve actually got some Slido questions throughout the presentation just to find out a bit about your challenges, if you’ve tried doing things, where you’re at, so it helps me tailor a bit more. I’ve got four or five questions in there. I’ll start with what you’ll learn. We’re going to talk about how security needs to be integrated early and continuously. Communication and collaboration, so the people side, the humans are critical. Also, automation, having standardized, automated processes. I think it was Forrester once said, manual processes are doomed to fail, so we’re going to talk a lot about that.
Who am I? I’m Stefania, aka DevStefOps. I’ve spent the last 10 years working first as a Python developer, then in a variety of security organizations as a solutions architect, working with all of the different organizations across all of Europe, North and South America, a little bit of APAC. Actually, since my last QCon, I’ve actually left to focus on my own business, DevStefOps, where I teach effective communication workshops to technical teams, focusing on security champions. I’m going to talk a lot about that. These are some of the organizations that I’ve worked with who’ve seen me speak, so some of the brands there. I’ll be talking about some of those experiences.
This is the first Slido question. This is a multiple choice, as in, you can answer all the answers, but that’s a bit excessive. It’s just about finding out who are you and your role and focus. It’s, are you an IC, a manager, director? Which area are you working in, developer, security, operations, product, or architecture? Just so that I can tailor what we’re saying. We got about 40 answers. Lots of developers in here. Then, in terms of level, we’ve probably got quite a few managers, ICs. Strong development cohort.
What we’re going to talk about, first, why security matters. Then we talk about the three key things, people, processes, and technology. Then, finally, some key takeaways.
Why Security Matters
Why security matters. I’m going to start off with just a quick overview. What is DevSecOps? Because this is a very popular buzzword that has been thrown around. It’s not a case of just having security in the middle. We do our development. We have a release candidate ready. We do some scans, and then it’s over to ops. DevSecOps is about security at every single stage, so that you have these multiple checkpoints, and you have safe, secure delivery. Some of the other key areas. Shifting security left, so into development, and also shielding right. Early detection saves costs. Some of you may have seen this graph before. This is actually from NIST. What it talks about, the cost to fix a bug. Developers, I’m sure you know that if you have a little flag, “I’ve just introduced a library, Log4j. Sounds familiar. I can’t remember why.
That’s a big red flashing button. Do not use this version. Do not pass Go”. You can quickly make the change in your IDE without anyone knowing, and then move on and commit, and move it down the lifecycle. Say if you don’t have the alert, maybe you haven’t had the training, or you don’t realize in coding, or maybe even in testing, and then it gets past the pen testers, but all of a sudden you’re realizing in production. That’s going to be a lot more expensive. There’s going to be risking of company damage. There’s going to be egg on your face because it’s never that nice releasing critical vulnerabilities into production. Having this early detection and shifting left can really help. Because what we’re trying to do is go on the proactive, the preventative measures, rather than, “There’s an incident. It’s on fire. Reds everywhere”.
The early morning phone call is like, what’s going on? When we look at shielding right, this is more on the operation side. Everything around monitoring, logging, checking that our environments are consistent, using ephemeral instances. Because using proactive security, it’s like eating your vegetables, crossing your T’s and I’s. Proactive security is always cheaper than reactive. Detecting issues early can really help with this.
The other core area of DevSecOps, and this comes back to the original DevOps. Who here has read, “The Phoenix Project”, by Gene Kim? This comes from that area. What is a feedback loop? We get feedback. We analyze the feedback. Then we act on the insights, and then we do it again. This is good in an iterative approach. How long between these three stages? Is it minutes, hours, months, years? There’s always a big change depending on what industry you work in. If you’re working in a tech startup, great. You’re probably doing best practice. When you’re working in embedded, if you’re working in defense or telco, where it’s like, yes, if we make a change to our production 5G systems and 911 can’t be called, we’re going to have a problem. You also have to take it in context with where you’re from. In terms of with the Phoenix Project, it discussed with three ways.
At the top, this is the first way. This is waterfall. Dev does stuff, and then it goes to ops, and then waterfall. Not much happens after that. This is where you have things, if you remember the wall of confusion, or, it works on my machine. That’s a big constant of the first way. Then we have ways of giving ops feedback to dev. It’s like, we’ve done all our build, we have our prototype, and now we want to put it in production. Then ops is like, it’s not going to work because it’s the wrong system or however the problems are. With DevOps, what you have is this very fast feedback. We had waterfall, then agile, then DevOps, and DevSecOps is integrating the security. It’s about feedback, because if we can feedback fast, we can make changes fast.
Small changes are a lot easier, cheaper, and quicker to fix than big changes. I talk about it with my non-technical friends. I’m like, can you remember how we had Windows 95, and then we had Windows 98? That’s three years between versions. Now we have Microsoft 365. We’re iterating constantly. This is a good example of the three ways. Because what we’re really looking for is this real-time iteration and implementing changes quickly based on feedback, so we can have these quick improvements and faster security responses.
I’m just curious, because I’m going to talk about my experience with a security breach. Have you ever experienced one? Yes, with a significant impact. Yes, with a minimal. No, never, or not sure. Because if you don’t want to answer, I’ve put that there for you. I think my first ever breach was a personal one. I was about to go talk in Sweden about 7 years ago, and my Steam got hacked. I got an email being like, yes, your video game, they’re trying to steal your credit card. Nothing bad happened, so that was minimal impact.
Then, more recently, my Amex got done, and it was like 240 of a currency I didn’t recognize. I’m like, that sounds big. Thankfully, it translated to £3.50, so it was ok. These are some personal experiences. I’m sorry to those who have had a breach, because it looks like it’s over half. It’s almost three quarters. To those, no, never, I’m really happy for you. Touching all the wood, let’s keep it there. Because when we do have a breach, we also want to minimize and contain the impact. Having the proactive steps to make sure that they don’t happen. I don’t know if anyone’s ever experienced one of these before. There I was, at 6:30 a.m., and I get a call, we’ve been hacked. This was actually a Swedish telco company that had called me because they had been hacked, and they were worried that it was to do with their GitLab instance. What do they do? They call me at GitLab to ask we’ve been hacked. I asked them what had happened, what’s the scope. They had been locked out of their systems. It was around their pipelines. They were obviously very worried calling me at 6:30 and asking, what do we do next?
At this point, I logged on to our systems to see, had we had a company breach? Was this a GitLab problem? Was it to do with their instance? It actually wasn’t anything to do with GitLab. It was to do with one of their other internal systems that affected their pipelines and delivery. It is never nice for anyone to get that call because security breaches do not sleep. We live in a 24-hour world. I do not wish these calls on anyone, but they are bound to happen if you’re not looking after your proactive security.
What happens when we have this miscommunication? Say I don’t answer the phone, or say that we’re talking in a team and then there’s some confusion. We live in big organizations, global teams, multicultural environments. It’s really easy, especially if we’re not sleeping or eating and drinking coffee and stressed, to misinterpret each other and to get a bit stressed out, like rub each other up the wrong way. It’s really important when it comes to security incidents to think about clear communication so that we don’t end up in this stressful environment. What can happen? We can have security gaps. Maybe we misinterpret what we meant. Yes, can you fix that, or can you update that, or not having clear instructions. It can have an impact on productivity.
I did a short role for an event earlier this year, and when I was speaking to the person in charge, their email responses were so cryptic that I then had to go to someone else who had worked there a bit longer and be like, what does this mean? If ever I asked the person, they would get angry at me for not knowing. I would really recommend Beth’s talk, from the BBC, about psychological safety, because that gives a lot of practical tips. If you’re in that situation, not great for trust and morale.
Then, once you’re having these security gaps, these can lead not just to team or personal problems, but also financial and reputational losses and impact our customers. At the end of the day, we like doing tech, and we love our tech jobs. It’s fun to play with tech and talk to machines, but we usually will work in organizations, either someone else’s or our own, and if our organizations don’t have customers, then we don’t really have an organization because you need to listen to customers, find out what they want, provide them a solution or a service that they want. They give you money, basic economics. If you have front page breach news, then this can have a big problem. Miscommunication, even the small ones, can affect every level, from productivity, to customer trust and financial health.
1. People (Key Pillar)
Let’s talk about people, building a security culture. Why am I talking about this? We talk a lot about people, processes, and technology, and I really want to focus a lot on people because we are not machines. I’ve got that literally as my next bit. We are not machines, not yet at least. We work as individuals in teams, and especially, like I mentioned, in these global teams, high-stress environments. It’s really about working together, about collaborating, about understanding different motivators, and meeting each other at our level. I don’t know if anyone has ever had to deal with an incident, and then you have to speak to someone not in the development team, and it’s like, now I need to speak to the exec board about what’s going on, or to legal, or someone in the go-to-market because our customers are saying, why is the service down? It’s really about understanding the motivators and people, and building a psychological safety, and just having empathy and communication.
I worked at GitLab, and one thing we discussed, we called it short toes. We’re not trying to step on each other’s toes. Assume positive intent because we are trying to work together and have this shared responsibility. Different mindsets. We have developers. Developers, very creative, very good at problem-solving, very technical people, but very interested in how to create, how to develop. Security, they’re a bit more potentially reserved about risk mitigation and protection. In the olden days, we used to say, do not pass Go, do not collect 200 pounds, we need you to pass the test. Finally, operations. This is about stability and consistency. For example, operations will want to make sure what’s in production is stable. Developers are like, yes, there’s this new framework, let’s use it, it’s 5% faster. Then, production, ok, but it breaks everything, so maybe we can’t use it in production. Security is like, are we doing it safely? What you end up with is different goals, but you still have the shared responsibility.
Psychological safety, there are four levels. When you’re in a team, how safe do you feel speaking up? If you can spot something wrong, or if you have an idea, or if you disagree with the consensus, do you feel that, ok, included, I feel welcome here.
Almost all my career, I’ve been the first woman in the team. My proud moments myself, when I left GitLab, I went from the first woman in the team of 10, so let’s say 10% women, to then there were 7 out of 21. That was up to a third, which was awesome. When you’re in a minority, it can be hard to feel included, even if it’s not intentional.
Then, do you feel that you can ask questions without feeling stupid? This especially affects juniors. Are you, as more senior people, creating an environment that junior people can ask these questions, so they’re not like me with my email change like, what does this mean? Spending 20 minutes, half an hour trying to figure things out. Do people feel they can contribute? When they have an idea, I have an idea for a new feature, for a way of doing things, or, could we do it this way? Even better, challenging. Do we feel, I can be bold and step out and be like, “Actually, if we do it this way, I can see this problem happening”. I don’t know if anyone attended the Black Hat conference, they had the women with the lampshades on their heads.
I think when it went on the internet, a lot of people had a lot of strong opinions, but at the time, I don’t think anyone internally within Palo Alto felt that they could speak up and say, yes, maybe this isn’t a good idea to have this on our booth. Psychological safety matters, because if you can speak up, you can innovate, and you can fix problems faster, and you can stay secure.
Here are some practical collaboration tools and strategies. When you do have security incidents, what happens? Do you point the finger? Is it like, we need to hide, or is it, ok, this is the problem, how do we fix it? How do we make sure this never happens again? There’s a book called “Radical Candor”, by Kim Scott, and she comes from the FAANG/MAANG world, and she talks about how to give feedback. I think there was an example, instead of saying, you’re terrible, it’s like, perhaps we could look at another way of doing the build, don’t point it at the person, point it at the work. Having check-ins, so this could be face-to-face.
If possible, people do like to go for coffees, or virtual one-to-ones, or group areas, cross-functional teams. I’ve always been a member of the different groups, the video games group, the neurodiversity group, the women group, the LGBT group, so having opportunities to meet people from other teams. Also, for example, security champions, having the opportunity to cross-collaborate these teams as well. Documentation and knowledge sharing, always a good idea, and having these joint problem-solving sessions. To have all this, you need the psychological safety first, because what’s the point of having a joint problem-solving session if no one feels safe contributing or speaking up?
Security as a game, so I’m going to show you two graphs. What we have is a bar graph of ages, so we have under 18, 18, 34, 35, 44, 45, 50, 65, and the top one’s similar. I actually attended a talk by someone in security at Audi, it was definitely one of the German car companies. He was talking about security champions. He showed these graphs, and he said one of these is the average age of developers, and the other one is the average age of people who play video games. As you can see from these two graphs, they’re very similar. How can we make security more of a game? Having gamified challenges in security training, so making things fun, like, let’s lower all our CVSS 10s, and whoever does it gets a star, or a badge, or we have a leaderboard. Or you can also tie into exec buy-ins, so whoever reduces the most critical vulnerabilities gets a free lunch with the CISO, or the VP of engineering.
If you don’t want to do that, and you don’t want to speak to exec, maybe it’s just an afternoon off, or maybe it’s a video game voucher. Considering that as people and motivators, there’s a strong correlation. I could actually ask this, who has or enjoys playing video games? We’ve got quite a strong correlation. If we can add gamification into the way that we work and into our workflows, we’re going to see a lot of improved productivity. I would recommend Trisha and Holly’s session, that’s another one. It was talking about developer productivity, developer joy. It said, if we can find joy and happiness, we will be more productive, which leads to organizational success. If we can find joy and security, we’re going to have a much better result. We can increase awareness, motivation, and retention of these security practices, and we can turn it into a rewarding experience, making it fun and impactful.
Next Slido question, this is around security champions, which I’m going to be talking about a bit. Do you have security champions within your organization? Answers include yes, no, considering it, and not sure. Security champions are usually developers who have been either nominated or volunteered or sometimes voluntold to be involved in cross-functional security initiatives, and they act as an additional part of security, but embedded within the developer teams. Most of us are yes. About a quarter no.
Then the rest not sure or considering it. Security champions, why are they great? It drives a culture of security across teams that really helps with the cross-functional. Also, security champions are good at speaking to developers in their language because they’re developers. They’ll sit in the security team, learn about the risk and incidents, and then translate it, go to the developer team, and be like, yes, we really should update these dependencies because otherwise it’s this easy to get hacked. You can even lean or show them like, “This is how Log4j works. This is why we need to use it”. It reduces risk, improves response time, and it creates this collaborative culture because you have this shared responsibility, and security is everyone’s concern. I’m going to talk about some organizations who I think are doing it well. My caveat is, I haven’t got legal permission from anyone. This is what I have seen.
I know all these people, and I’ve seen it on their LinkedIn’s. I figured LinkedIn’s are public enough to me. I’ve just taken some of what’s been best practice that I can share with all of you. These are some of the organizations that I work with their security champions programs. What do they have? I’d say number one, and this is for any transformation project, having executive sponsorship. Having your HIPPO, your highest paid person’s opinion. Having someone at the top who agrees, who signs in, who even just comes to the beginning of the meeting or the session like once a quarter, and be like, “Everyone, this is a really important initiative for the company. Really looking forward to everyone’s contribution because this is really important to us. Thanks. Whoever wins, you get a lunch with me”, or whatever it might be. Having that buy-in can really help herd the cats and align the teams.
When I was at GitLab, I also worked with Barclays and they had executive sponsorship at a really high level, which has helped with their DevSecOps transformation. Cross-functional collaboration. Like I mentioned, with security champions, they sit in both teams. It’s a bit like me with my English dad and my South American mom, and then it’s a mess. It’s understanding how very different people work and communicate, and how to get the best results out of both of them. Something else they do, and this is also where I get involved, is continual training opportunities. These organizations, they’ll host workshops internally. They’ll get this expert security speaker in. Someone from the security team. Someone from the developer team. Externals like me that specialize in effective communication. They’ll have these on a monthly or at least a quarterly basis so that these security champions have an opportunity to step away from their day job and everything that’s going on and focus on learning.
If anyone has read Stephen Covey’s, “The 7 Habits”, sharpening the saw. It’s really about taking that moment for proactive development. Having a definition and ownership. For example, having it in your Slack handle, having it in your job title, just so people know. Yes, for the core engineering team, I’m one of the security champions. That way if a developer is like, yes, I think I’ve just used HTTP instead of HTTPS, maybe I want to talk to a friendly face before I go officially report it to security. Also, these ongoing feedback loops. This comes back to my slide from a bit before about feedback loops. Having the ability to iterate quickly, because this really improves the culture. It reduces risk, and enhances collaboration. Because security is everyone’s responsibility. You want to have success built in to every team.
2. Processes (Key Pillar)
Processes. My people bit was my biggest bit. I have a little bit of processes in tech as well. This is about integrating security into the workflows. Another question for everyone, because I’m curious to learn from you. What is the biggest challenge you face when integrating security tools into your workflows? I think it’s a multiple choice. You might have three challenges you face. Is it the tools? Is it complexity? Lack of knowledge? Resistance. Integration. Leadership support. Having that executive buy-in. Training. Scalability. High cost. There might be another one. I thought I had time in here. Let’s see what some of the results are saying. Lack of knowledge. This is an interesting correlation, because lack of knowledge might suggest insufficient training.
Insufficient training has actually come in at almost a close number two, followed by integration as well. Which comes to my build versus buy, which I’m going to talk about at the end. That’s really interesting. This is the thing. We want to create psychological safety so we can address exactly this, so that we can talk to our security teams or our engineering leaders, and say, “I want to understand security better and use it more, but I don’t know how”. That makes us vulnerable. Especially when we’re senior, we don’t always want to say, I don’t know. ChatGPT is great for this, because you can just double check when no one’s looking, so, like, now I have at least some base AI knowledge. Having that psychological safety so we can ask the question.
I’m going to talk about what we can do in terms of security at every stage. I talked about security everywhere. What does that actually look like? We start in the top there just at plan. For example, threat modeling. Do we have security in the planning stage, figuring out, what are our assets? What are the avenues that we can be hacked? What’s at risk? How are we doing our encryption, our data? Having a security mindset in that process. Development. Do we have secure coding? Do we have practices that we use or methodologies? Do we have secure coding training? Do we have an understanding or a base plate of what’s acceptable and what’s not? Security as code. This is where we’re taking our security policies. Security as code can be throughout, but having policies.
For example, we do not want to let any CVSS 10 out of 10, no passing Go, no collecting 200 pounds. Or, say, for example, maybe if it’s a low, maybe like a 3 out of 10, maybe we’ll let that slide for now. Having these rules and these policies. Then we get to security types of scanning, which I’ll ask you a question about in a bit. Static code analysis, dynamic code analysis. We have penetration testing. We have so much more. We have container scanning. We have API fuzzing. We have loads. Once it’s ready, test. Now you’re ready. You’re usually ending the development process. Maybe you want to digitally sign it so we can verify with integrity that this is ready. Move over, this is more in the upside. Around, are we transferring it securely? Are we encrypting things? Do we verify at each stage it is what it says it is? How is our configuration? Infrastructure as code is awesome. Before, if we had a problem, we had one physical server. No, we put the screwdriver in, we screwed it in wrong, or that server’s gone bad.
Now with infrastructure as code, one line change can affect thousands of servers. If you’re not updating your libraries, it means you could be vulnerable to potential attacks. Within ops, security scanning, patching, auditing, monitoring, and analysis. Then we go around this loop. Who confidently feels that they’re doing all of these stages and more of security? I’ve literally spoken to hundreds, if not thousands of organizations in my lifetime, and I would be very surprised, even the defense companies or the banks, it’s very rare that everyone is doing everything perfectly. We can all try and do as best as we can, and also take the context, what is most important to us? For example, if we care a lot about our data, if we’re a healthcare company, we’re going to focus a lot of security on that, for example. Very much about context. What we have, security all the way out, our software development lifecycle. It’s within our workflows. We have this collaboration. We want to have rapid feedback.
I think the most important thing as well is when these ping like, red alert, we want to make it in developer-friendly language. Instead of, you have a reflected cross-site scripting within this method, and you’re like, what’s reflected cross-site scripting? I’ve heard of stored, but what is it again? Instead, you get a simple, because of this function, because of this method, this leaves you possible to be attacked, and we suggest either update this component or change this line. Having that developer-friendly explanation and remediation, because then as developers, we can fix it a lot faster. Having this security at every stage reduces costs, prevents issues, and enables faster, more secure software delivery.
Which of the following security tools are you currently using in your workflow? You can answer as many as you know of, so there is a not sure. What I find from experience, before I see the results, most organizations start with SAST, so that’s when you’re looking at your static code analysis. Then, especially with software supply chain attacks, people can move into dependency scanning. Pre-AI, SAST was about 20% of your code, and then dependency is about 80%. Then with AI, I’m like, ok, so where is AI-generated code in all of this? Obviously, people are using more containers, so it varies. I used to work in dependency scanning, a company called Sonatype, about five years ago. Maybe I’ll just share this headline with them, because they’d be very pleased to see this, because at least when I was in software security about 7 years ago, this was not as good. Well done everyone for looking after your dependencies, because it used to be almost the opposite with SAST. Embedding security in the workflows. Here I have an example.
Here is a pipeline, and what do we have in the test? We have first stage build, then we have test. We have code quality. We have container scanning. We have ESLint SAST. We have Gemnasium dependency scanning. We have open-source license scanning. We have Node.js scanning, Retire.js dependency scanning. Secret detection, Semgrep. We have test as well.
Then, a little bit further along, we have DAST as well. What we’re trying to do is get all of these security scans into our workflow, because the last thing we want to do as developers is, ok, let me just run it through this scanner, and then, I’ve got the results, and now let me take that and run it through the next one, and take it and run it through the next one. We want to have it automated. We want it to be integrated, and like I mentioned before, vulnerabilities reported in developer-friendly language. Having these automated scanning tools, and especially catching vulnerabilities early, prevent costly fixes later, reducing risk, and increasing deployment speed. Should also say, lowering deployment pain.
In terms of best practices, like I said, same caveat as before, this is what I know from knowing people and being involved in projects, and also from what they publicly put on social media, but here are some companies that are doing this really well. What do they do? They have seamless integration of security across their development lifecycle. These fast feedback loops. When any person introduces a vulnerability, how quickly before they’re told about it, and how quickly before they have the ability to fix it. Are they waiting on tickets, and chasing, and being told 6 months later, or is it minutes and hours? Having this collaboration, proactive risk mitigation, so having this proactive and continuous improvement, culturally and technology, and yes, really security-driven culture to improve this resilience.
3. Technology (Key Pillar)
I think I’ve got my last section, technology. Buy v. build, what do we do? I’m a bit biased, I have worked at a lot of security tool companies, so I often get asked these questions, do we buy, or do we build? Talking about build. It’s great, ok, we’re going to build it. We know exactly what we want, and we’re going to build it ourselves, so it’s tailored to our needs. We have total control over the features, what we want it to do. We can invest in it ourselves. That’s a bit of a double-edged sword, because if we’re investing it in ourselves, if anyone knows some basic economics around opportunity cost, any time that we’re investing in, “Yes, we’re going to make a security training platform, or we’re going to build our own pipelines”, that detracts from our core business.
For example, if we’re a bank, do we want to be a security training provider? If we’re a MedTech, do we want to be fully responsible for our pipelines, or can we outsource that? Because you do need in-house expertise, resources, and it is time-consuming. You think, now I’ve built it, but I’m sure you’re familiar with, you build it, you maintain it, you’re now responsible. You’re the person for this. However, when you buy, you have faster implementation, lower upfront cost. Yes, you have to pay for the license, but, usually, especially when you’re dealing with smaller companies and bigger, if you speak to the product managers and say, I want this because it will help me with this, you’re probably not the only person who says or thinks that.
Product managers, if they’re good, will say, this is a common feature request from some of our best and biggest customers, so maybe we should focus on this. I worked in a company, it was security training, and they would say, yes, if someone was willing to spend 100K, then they can have whatever language they want. We had COBOL. We had Dart, Flutter, Swift, PHP. We had a bit of everything. Really, it’s about which approach makes sense for your organization. I am biased to the build because it’s, what is your core product? Any time you spend developing in-house tools, it’s taken away from what you do as a business. We work as developers, we want to build, it can be more cost-effective to buy. I would recommend talking to your suppliers and saying, you’ve got what I want, but I want also this as well. When can you do this? Does anyone else want it? Having it as a collaborative approach.
What challenges do you face when automating security in your workflows? Lack of expertise, integration issues, too complex, resistance from teams, tool compatibility, insufficient resources or time, difficulty in maintaining automation pipelines, lack of leadership, or high cost. I get that. I don’t know if anyone’s heard the phrase, you need to meditate for 30 minutes. The person says, I don’t have time to meditate. Then they’re like, in that case, you need to meditate for two hours. If you don’t have resources or time, if you don’t have the time to automate, it might be worth taking a step back and thinking, what could I automate? In an ideal world, if I did have resources or time, and make an ROI about it.
Every day, I have to spend 20 minutes manually configuring this process. Twenty minutes over a month or over a year. What’s my hourly rate? All of a sudden, this 20 minutes a day is costing the business thousands of pounds. While, actually, if I took one workday or one developer or a small team to automate this, we would have standardization, we would have time-saving long time. I’m going to talk a little bit about automating security, because this is ideally what you want to look like. I used to be a Python developer, so I automate everything. That’s what I look like when I’m at a computer. How can you do it? Simple things. Integrating automated security testing into the pipeline.
The example I had with the GitLab pipeline before. Automating incident response and remediation. You can set little toggles like, ok, we expect this to be normal behavior, but if anything else is abnormal, someone gets pinged. Just we want to be notified, so we’re not relying on manual checking of dashboards. Security as code can do standardization, and also automating dependency management, so where your dependencies are coming from. Are you using a local repository? Are you using a random shared drive? How are you getting all of your different components? Also, security tools into the IDEs, because if you have this automation, it makes security easier, it helps with audit, it helps with compliance, it helps with the day job, and it’s faster, more secure development.
I’m going to give some examples of tools. I’m not here as a vendor. This is an example. It’s actually Rakesh Chatla who did this. Here we have an architecture of a DevSecOps flow, and some of the tools involved. These are almost all open-source tools. We have Checkov, that’s infrastructure as code scanning. Anchore is static code analysis for coding. Then we have OWASP. Who’s heard of OWASP? OWASP is great. It has a lot of free tools. Great for playing around. Then we have Falco as well, which is more on the deployment side. These are really good, because they’re cost-effective. If you want to try introducing things, automating things, some side weekend projects, it can be really cost-effective. You can customize, flexibility. You have the opportunity to do community-driven improvements as well. This is more on the build. You can build it yourself with open source.
As you can see, there’s a lot of moving parts. You have to do a lot of integration glue. If we look at vendor tools? GitLab, they do CI/CD, but you have the security at every stage. Snyk, very much a security company, and they’re focused on all of the different types of security you can have within DevSecOps. GitHub, similar to GitLab, these are the CI/CD tools, but they actually have these really cool advanced security features. If you’re using either of those, I’d recommend that you reach out and find out a bit more about what they’re doing in the space, because they’re not just pipelines anymore. They’re good, you get the comprehensive support. You get documentation. You can also speak to their product teams and say, we want this, or, what are you doing about this? A lot of time, these tools do want to speak to you to find out what you need. Comes back to what I said about businesses, customers, happy customers.
Key Takeaways and Book Recommendations
This is just my takeaways, my book recommendations. What are my takeaways? Security needs to be integrated early and continuously. Shifting left and also shielding right too. Communication and collaboration are critical for a security-first culture. This comes back to the people side, to the human side. This is something I specialize in a lot. Finally, automation is key to scalable security. In terms of book recommendations, I like to give five under three different sections.
If you’re interested in DevSecOps, I did mention “The Phoenix Project”. There’s also “DevSecOps” by Glenn Wilson. He’s a really awesome guy. Also, “Accelerate”, which is the science behind high-performing organizations, and that’s where the productivity metrics came from, not the DORA Security Act. If you’re interested in collaboration, so this is around psychological safety, Amy Edmondson does some great stuff, “How the Best Teams Use Failure to Succeed”. Also, I’m always telling this to people, “The Culture Map”, which is all about communication. Finally, my book, “Mastering Effective Communication in Tech”, coming soon.
This is actually more like, if you’ve heard of Net Promoter Score, there was a funny meme about this, because they asked the question, how likely are you to recommend? Then there was a meme, and it was about operating systems. The person said, zero, I do not go around recommending operating systems. I asked this question, if you are talking to someone about secure workflows, people, process, technology, collaboration, if you are talking to someone in QCon about the session you attended, how likely would you be to recommend? In fact, you got it on an emoji scale.
Questions and Answers
Participant 1: You talked about shift left and IDE integration. I’ve tried to do that with SAST, which can be complex, slow, false positives, cross-application on a monorepo, and it didn’t work very well. Would you have any tips or suggestions?
Stefania Chaplin: Which SAST tool were you using?
Participant 1: GitHub Advanced Security.
Stefania Chaplin: There can be challenges, yes, especially with a monorepo, but if you change two lines of code, how that affects everything else. With the false positives, that can be part of a big issue. I don’t know if you’re still using GitHub Advanced Security, but definitely reach out to them and let them know so that they can change the system, because no one wants false positives in the system. I’m not saying it’s your job to report it, but I’ve worked in a lot of security scanning companies. When I was at Sonatype, we prided ourself. We had a security research team, so our false positive rate was very low compared to one of our competitors, Black Duck, for example. It does change, case to case, and especially with a monorepo, it can be slow. Sorry that you’ve had that experience. I don’t have an easy answer other than, I’m very disappointed in GitHub that their advanced security had this issue, but potentially speaking to them and they can also advise some solutions for that as well.
Participant 2: If I want to start doing DevSecOps, what would be the biggest impact point to start with?
Stefania Chaplin: I think it depends where you’re at and who you are. Are you in a position of power where you can bring tools in and make change, or are you more of an individual contributor who wants to do the good thing? I think you said the first one. Then I would have a look at the estate in terms of, what does your business do? What applications do you have? What languages do you have? A really good place to start is with security in the pipelines because you want to go into the existing developer throne.
Then when you’re shifting left, you want to start looking more at either end, threat modeling and pen testing. Then you can start with all of the different verifications, for example, build signing at different stages, monitoring and logging in the operations. I usually start with security in the pipelines just because you’re probably running a lot of pipelines. Every developer has to turn their code into an application. That’s usually a single point where it’s a good first step. Then you spread out from there. It will also depend on what your company does, what your applications do. If you’re working in a tech company, if you’re working in a defense company with satellites, you’re going to have slight different nuances.
See more presentations with transcripts
