Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Securing Microservices: Preventing Vulnerability Traversal

Securing Microservices: Preventing Vulnerability Traversal



Stefania Chaplin is looking at OWASP recommendations and Kubernetes best practices to find out more about how to secure microservices and reduce vulnerability traversal.


Stefania Chaplin’s experience as a Solutions Architect within Cybersecurity, DevSecOps and OSS governance means she's helped countless organizations understand and implement security throughout their SDLC. Stefania enjoys optimizing and improving operational efficiency by scripting & automating processes and creating integrations. She is an active member of OWASP DevSlop.

About the conference

QCon Plus is a virtual conference for senior software engineers and architects that covers the trends, best practices, and solutions leveraged by the world's most innovative software organizations.


Chaplin: I'm Stefania Chaplin, aka devstefops. I am a Solutions Architect at GitLab. I'm going to talk about securing microservices, preventing vulnerability traversal.


A little bit about me. Who am I? What are we here to talk about? I've got quite a famous example I'm going to talk you through, when talking about vulnerability traversal within microservices. Who is our audience? Thinking about the silo of the teams that we need to work with. How are we going to approach this? How do we fix this? What are some frameworks that we can use? I'm also going to look at some specific types of vulnerabilities. Most importantly, why are we here? Why are you listening? Why am I talking? Why are we looking to secure our microservices? A little summary, and then Q&A at the end.

Who Am I?

Who am I? I used to be a developer, mainly using Python, Java. I did a lot of work within REST APIs. I'm one of those cool people that I can just read JSON. That's the way my mind works. If you need a particular value, I can tell you the order of square and squiggly brackets to get you there. Then I moved to the wonderful world of security, focusing within DevSecOps, AppSec, and also CloudSec, so securing our cloud and microservices. Now I work at GitLab, the DevOps platform. If you do want to talk to me about GitLab, I love talking about it. This talk is not a GitLab one, as you can see, devstefops.


What are we here to talk about? I want to start a bit with a story. I say a story, it wasn't that long ago, it was a couple of weeks before Christmas. I'm not sure if anyone remembers or came across, Log4Shell could be the worst software vulnerability ever. This headline was not alone, there were lots of equally strong headlines about this. Log4Shell was related to a component called Log4j, which is a Java component used as a login framework. It's very popular. It is used in a lot of different types of applications. The thing about this vulnerability is there is a vulnerability scoring system from 1 to 10. This was a 10. This was as high as you can get. When we think about components, for example, Log4j, if anyone has come across xkcd before, I would recommend it. Really good. Very clever IT related and entertaining images. Here we have, this is August 2020, all modern digital infrastructure. Then at the bottom, a project some random person in Nebraska has been thanklessly maintaining since 2003. That little component that is Log4J within this context, because it is a logging framework used. I'm not going to say by everyone and everything. However, Ernst & Young, and Wiz, did a study and they actually found that 93% of cloud environments are vulnerable to Log4Shell. What they found, 45% security protection, 20% have high privileges, that's awesome. That also means that 80% do not. Seven percent are exposed to the internet, so we've got some real risk there. This Log4j, Log4Shell, it was a 10, so this is obviously quite a big deal.

The vulnerability scoring, what does it mean when it's a 10? I've got a screenshot here. It's a little complicated. It's based on a number of factors. I have configured it here, we can see the attack vector. For example, can I do it via a network, or do I have to be physically there? Similarly, attack complexity. Is it easy or is it hard to complete this vulnerability? Similarly, do I need privileges, user interaction? We start to have these different scores. I would check it out at CVSS Calculator. You can start to play around. This example, I can do it on a network. It's not hard. I don't need any privileges or user interaction. That's going to be a 10. What does that actually mean? We have this calculator, and the way that it is ranked is you have your criticals. They are your 9 and 10s. In terms of prioritization, this is where you want to start. I've worked in application security a long time, and we always say, start with the 10s. Start there. Then go down to the 9.9s, the 9.8s, we go to one decimal place, and you've fixed all your 9s. Awesome. Ok, let's move, let's go to the highs, because what you'll often find with vulnerabilities is you can actually start to link them together. For example, a high, maybe this is a denial of service. Medium, you're probably not worrying too much, I have a nice Bumblebee. However, these are things like path traversal. If you dive into a directory, and you manage to get in somewhere, if you can move around, what happens when you end up in the etc folder? Then we want to get to a happy world where we only have lows. Ideally, we want to remove those too, but we want to work our way down. Have your line in the sand, and keep moving that number lower, and also have security checkpoints as you go.

Why Log4Shell could be the worst software vulnerability ever. Hopefully, now you can get a better understanding. It was a very common component, and it was a very high vulnerability. It was very easy to execute. The way it was accessed was before any authentication. That was the thing, poor Log4j. If you think of the person in Nebraska, this is how the Log4j maintainers felt because after the critical, that was a remote code execution, so someone could go in and execute code remotely. Then next came a denial of service. That was fixed in the version 2.16. Then came another denial of service, so fixed in 2.17. Then finally, another RCE, another remote code execution. You've really got a mix. That's just this one component. When you think about your microservices, unfortunately, it might look a little bit like this, you're going to have bugs all over the place. What we're trying to prevent is, here, I have Log4j, and maybe it's got in within a particular process, within a particular service, for example. Then, what happens if it starts moving around, and all of a sudden, it's within your main application within your critical data. What we really want to do is we want to have checkpoints that will prevent this vulnerability traversal, and our beautiful ladybugs from getting into our microservices systems.

Common Pain Points

Common pain points, Log4j. How do you know what is where? Also, on this, how do you prioritize? Siloed teams, so lack of ownership and accountability. The person that creates the service, do they then own the service? Are they responsible for security? Who owns what, for example? Then, delays, fails, or worse. What this means is you don't want to have any bugs in your system. Then, what happens if something goes down? We hope in a microservices system, you can fix things quickly, patch quickly, scale back up quickly. What happens if the bug moves around? Also, what happens if your team is spending the majority of that time fixing bugs, or doing patches, or fighting fires? You really don't want to have that from a cultural perspective, also in terms of careers and attrition as well. Ultimately, you do not want to be front page because of a vulnerability, because that obviously has massive impacts for brand as well.


Who are we talking about? I'm going to talk to you about my silos. I'm really talking about the main three. I do have one over there, sometimes that's corporate. Let's focus on these three. I've got my developers. They might be provisioning microservices. They might be provisioning environments. They might be running the applications within the microservices. They might be developing processes. They're usually going to be the ones writing the code. Developers, I used to be one, we like new, shiny. We tend to be quite intelligent, quite creative. We like to stay within our tools and within our world. Then you have security. Security are usually outnumbered. I've seen different ratios. I've visited a lot of different organizations in my time in security. One time I spoke to an organization, they had about 130 devs, and 2 security, so 1:65. I wanted to applaud them, because I was like, that's the best I've ever heard. Because on the opposite end, I've been to places where it's 300 to 1 AppSec. Similarly, when you've got tens of thousands of developers, ok, you may have a large AppSec team, but there's always going to be quite an outnumbered ratio. One of the things I like to think about is, how can we empower developers? How can we get everyone to be 1% better? I'm a big fan of compound interest and incremental gains. I'm not saying we want security to become developer and vice versa. Start to break down these silos. Let's start to be on the same team. Let's start to work together.

Finally, you have Ops. While devs like new and shiny, Ops likes stability, literally measured. One of the areas of importance is reliability, availability, latency, uptime. Ops wants things to be stable. Square peg, square hole, sometimes devs come along with this weird shape. There can be a bit of an issue there, and DevOps is great for that. What I'm really talking about, it's not a case of buy all these tools, do all these processes. It is more of a case as well about culture and about changing how we work together, because we are all on the same team. It's not about the bad guy who did this. Who did what? When there is a situation, how do you deal with it? Is there psychology of fear? Is there a culture of fear, or is it more proactive? Ok, there's a problem, who knows what? How do we fix it? Then afterwards in the debrief, how can we do better next time? Because when you have these three groups, there's kind of tribes, they speak differently, they have different influences, different importance. It's very much about getting everyone to work on the same team and work together. Because you don't want to end up like this. Here I have my Ops silo is not doing so good. It's a little bit broken. Because what might have happened somewhere within our environment, there might be a cryptominer that got into one of our Kubernetes instances, and has spawned 200 pods. We're maxing out our AWS bill, and Ops has been paged in the middle of the night, what's going on? How do we fix this? What we want to do is have a more proactive approach, think more secure, secure by design.

Who Owns What?

Who owns what? This is a very good place to start when you think about microservices, because ownership and accountability is very important. Martin Fowler did a very famous article, Nine Components of Microservices. One of the ones he talked about was cross-functional teams. Because also when you're working, instead of having your tribes like my silos before, it's like, why don't we do cross-functional teams, and organize around capability? We organize around products. Instead of having a project mindset, we go to more of a product mindset. I'm like, this is the mobile app team, or this could be customer login, or however it might want to be. With these cross-functional teams, where is security? Do we have a security within each team? Do we have one about to five? Could we maybe get everyone to be a little bit more secure? How can we facilitate security, because there's a lot of worry in a CISO's life? It's very much about thinking who owns what and where is security within all of these processes as well. Prioritization is a very important one to think about. High risk, start there. Whether that's the types of vulnerabilities or whether that is the types of applications you want to go for your high risk and your high exposure first.

If anyone's come across Eisenhower decision matrix, I actually use this for productivity. You want to think of your four by four, urgent and important. If something is urgent and important, like maybe a critical vulnerability, you're going to want to do that. Similarly, if something is important, but not as urgent, plan to do it. Maybe those would be your lower vulnerability bugs, for example. If it's urgent but not important, delegate. If it's not really urgent or important, is it worth your time? Because I'm sure there's a lot of other things you should or could be doing that are urgent and important. This applies not only to day-to-day life, but also to vulnerabilities as well. It's also worth mentioning false positives, because unfortunately, they do come across. They can come along when you have security, there can be instances where there are false positives. What I say when those come across is, see if there's any way that you can sanitize your results, because developers don't really like being given false positives. See, if you're working with security tools or vendors, how many false positives are you getting? Is it like 1%? Is it 99%? Is it an issue? Is it not? Also, how do you identify them? How do you know that something is a false positive? Because the person who says it's a false positive, they might be a developer who might not have a full understanding. Coming back to my silos, that's why we want to give developers and Ops and everyone just more of a secure mindset. Then, you're just not introducing these vulnerabilities. As much as we don't like false positives, what is even worse, actually, is a false negative. I personally would rather have a larger list, which might have false positives than a smaller list, but then miss some bugs. Because then if it's unknown, if you don't know that you've got vulnerabilities in production, then you're in more trouble than if you just have a list of false positives.


How are we going to do this? I'm going to talk about some common frameworks. I'm going to go a bit granular and talk about some specific vulnerabilities. The reason is, is a very popular insecurity and it'll give you a bit more of a like, huh? Because I'm hoping if I can make everyone in the school 1% better at security, my job here will be done. The Center of Internet Security has this awesome framework of control. This is V7, I think there's just been a V8. What I would recommend for everyone, just focus on the basic, let's start there. Especially with security, we want to build strong foundations and move our way up. For example, the first two are just inventory and control of hardware, and then our software assets. Yes, do this. Back to Log4j, do you know what is where? For example, Log4j, do you have a software bill of materials listing all of your open source components for all of your different microservices? Simple, yes, no, maybe.

Similarly, some of these other ones, for example, continuous vulnerability management, adding the security. Looking at admin privileges. Configurations, and also maintenance, monitoring, analysis of logs. Logs are so important. As a developer, I didn't like writing them, I just found it a bit tedious. As security, I'm like, that's so important. Because when something does go wrong, and unfortunately, it probably will, you really want to know what is happening. If you have someone bad in your system, what are they doing? If you don't have logs, and if you're not monitoring, then you're not really going to know. They could do a lot of damage. I'm hoping if you haven't already, at least now you're inspired, work on the basic.

Then we can move to foundational. There's a lot of good stuff going on there. I'm going to talk a little bit about application software security, because that's where Log4j was. Also, these lessons can be applied throughout. It's not just applications. It's the entire of microservices architecture as well. I'm going to talk to you a little bit about OWASP, which is the Open Web Application Security Project. They do a top 10 of types of vulnerabilities. They just released a new one for web applications at the end of last year. I'm one of these cool people, I know my top 10. You could have asked me, what's A6? Then I would have been able to tell you, security misconfiguration, but it's changed now. The new top 4 is insecure design. This is a very interesting one, because for one, it actually includes a lot of types of vulnerabilities. Vulnerabilities have something called a CWE, which is a type. There are like over 40 types within this insecure design, because you're really starting to shift or start left looking at threat modeling and thinking, how can we design securely? Because it's a bit like if you have a car, you don't want to test brakes by crashing your car into the wall to see if the brakes works. You probably want to test your brakes before then. Maybe you just want to design good brakes, because brakes are quite important in cars. The reason I'm highlighting this is because this is the first time in any of the OWASPs that we've really started to think more laterally about how we design software.

The other ones that are worth mentioning, because I'll be talking about them. Access control, I give it a thumbs up. It basically means like, you're in our system, you can do whatever you want. You don't really want to be telling everyone to do whatever you want. Similarly, authentication. This is your front door. For example, who are you letting in? If you're letting anyone in and you're letting them do anything or everything, you're not going to have a good time. This is the web version, great for developing applications. Within microservices, we use a lot of APIs. There's an API top 10 as well. We have our API top 10. If we look at the two vulnerabilities I was talking about, so your thumbs up, for example, can everyone do what they want? Yes. That's our number 1 and 5. I'm going to go into what these mean, so don't get intimidated about the difference between broken object level authorization and broken functional level, because hopefully you'll understand by the end. Also, authentication. This is our top two. This is with APIs, how accessible, how easy is it for people to get in because you're not authenticating correctly?

Authentication and Authorization

Authentication and authorization, what do they actually mean? I know I've alluded to it, but Okta had a great definition. Authentication on the left confirms users are who they say they are. You just want to be doing that at every stage. I always say this about security, who can do what, and how? Because with the authentication, we're looking at the who. Like, who are you? Are you really you? Then the authorization on the right, gives users permissions to access a resource. This means, ok, I've checked who you are. You're allowed to do this. I had a house example. My authentication, that's my front door. Then my authorization is, once let in, can they open the safe, for example? You can get quite sophisticated at this. For example, you might need a worker to come in, and they only need access to the spare room and they have a key to get into a cupboard where there are pipes or something. It can get very sophisticated. This is what we recommend. You do not want to have an open door and permissions for everyone.

Broken authentication. An API is vulnerable if it permits a couple of things. Credential stuffing, this is, if you've got a big list on the dark web of credentials, and you just start like going for it, stuffing credentials within APIs. Similarly, brute force. For example, maybe you've got a username, you don't know the password, so you're brute force attacking. Within APIs, you might have lack of resource and rate limiting, which is, how many times can you hammer an API in a certain amount of time? That's another vulnerability in itself. When we look at authentication, we want to have it even stricter, specifically around the credentials. If you have weak passwords, weak encryption keys. Also, if you're sending sensitive details in the URL, you do not want to include tokens. For example, if we think back to my beautiful picture of microservices with all the bugs, maybe our first bug was just a leak, we leaked a token. Maybe that token was someone senior, or maybe they weren't, but once we got in as that user, we found we could actually do path traversal. We could wander around the system. You are as strong as your weakest link. You really want to try and lock your front door very suitably. In terms of preventing it, make sure you know all your possible flows, mobile, web, different links, SSO, one-click.

Also, speak to your engineers. This is really why we need to work together because when security are talking to development, and vice versa, we are all on the same team. We're trying to secure our microservices and our applications. Just have a constructive conversation about it without any single blame. Similarly, read about authentication mechanisms. Understand what you're doing. There's a lot of who, what, how? Also, there's a lot of standards. Don't reinvent the wheel, don't write your own authentication. There are some really good ones out there. Because if you're writing your own hashing mechanisms, token generation password storage, I would recommend definitely using standards because they will be more secure. Unless, obviously you're a developer of one of the standards. Also, OWASP, they have a great authentication cheat sheet.

I'm going to start to talk about authorization. Authentication, that's our front door, how can we let in? Now someone's in the house. Looking at APIs, I want to get my information. I'm user1, I just want my data. This is my command, GET user1. It's returned user2. All of a sudden, I wanted my bank details but it's given me someone else's. Unfortunately, this is what happened to T-Mobile a few years ago. Their customer data was plundered, thanks to a bad API. This is the thing, these types of vulnerabilities, it's a sure way to start harvesting data. How do we prevent? The thing about authorization, the real thing is permissions. Make sure that you have an authorization mechanism, you have user policies and hierarchy. Use your hierarchy. Is everyone an admin? I hope not, because that sounds very insecure. Does everyone need to be an admin? Having your different hierarchies of who can do what and how, is a definite tip. I hope everyone can take that with them. Also, using a mechanism to check logged in users, if they have access to perform what they want to do, because maybe someone can try and do something. Just checking, are you allowed to do that? Then also, use random and unpredictable values for your IDs, because if it's sequential, a bit like I tried to get user1, and I got user2, then, if it's more random, you will be a little bit safer. This is object level. I wanted user 1, I wanted my bank details, I got someone else's.

Broken function levels. This is slightly different. I want to get roles. I'm a user and I want to get some stuff. GET user, maybe I want to get a list of roles. Then I got the admin access, I got everything. This is also a real problem. As before it was objects, now we deal with functions. This is what happened to Gator smartwatches. This is an IoT smartwatch, and it started exposing kid's personal data. I find as well, when companies that deal with baby monitors, or kid's smartwatches, or anything personal, I find it always hits a little bit harder. How do we prevent this? Similar. Having consistent and easy to analyze authorization modules, so role based access control, having your hierarchy. Also, from a security standpoint, really, to be secure, deny by default. Have that mindset, deny everything. Then when people need stuff, then maybe we allow. Look at your endpoints, and then be aware of any function level authorization flows there might be, because you also will have to look at the business logic. You might need to look at what's going on, because the reality is you can't deny everything by default, because then no one can do anything. You have to have acceptable flows. Just making sure those are as secure as possible. Because something that can often catch people out, for example, Lambda. Lambda ephemeral appears, it does a job. It goes. What permissions does that Lambda have? What can it do? Yes, it might be only available around for three seconds every Tuesday. If someone managed to intercept and then take control, and that's the Lambda between two very important and not authenticating applications, all of a sudden, you might have a problem.

Now What?

Now what? I come from DevSecOps, and I think there's a couple of lessons to be learned from there. The main one is multiple security gates, because security is not an add-on at the end. It's like, we've built our microservice, now let's add security. It doesn't quite work like that. There's a picture I'm going to show with a lot of information, so I'm going to break it down. Here, we have Dev, and Ops, and they're working together. I'm going to break it. First, we're going to look at the dev side. These are the developers. Maybe we're provisioning environments. Maybe we're writing the code. Maybe we're doing the app. Let's think about threat modeling while we're planning. Maybe we want to have integrations within our developer environment, within IntelliJ, for example, or any other IDE. What application security scanning are we doing? If we're doing Terraform, are we using Checkov or any other providers to check that our Terraform script isn't going to accidentally be unauthenticated to users? For example, other ones in the fuzzing integration test, maybe have a Chaos Monkey, if you're into Netflix, and you want to start destroying things, is a good idea.

Similarly, when we move over to more of the cloud, to the Ops side, now we have our application, it's been tested, we've done the first half, but then we want to release it. Then we're going to start to do, prevent, detect, respond, predict. There's a lot of areas within that, for example, integrity checks, penetration tests, network and monitoring. I personally think incident response is one of the most important roles, just because, at some point, unfortunately, something will go wrong. How quickly can you recover from that? That is one of the key DORA metrics as well, is mean time to remediation when something goes bad. If someone drops your table, how long does it take to get back up and running? There's a lot of information, you can see we've got 30, maybe 40 different security checks. Yes, you do need all of them, but we can't all start having from zero to hero. What it's about is taking that mindset, so when you think about your front doors, when you think about who can do what, start thinking about your different microservices and how we can stop this vulnerability traversal by having security at every stage. Having it incremental, because it's a lot better for me to figure out I've got a problem in my Terraform script when I see a Checkov scan, versus when it's in production because we've just been hacked because I wrote bad Terraform, for example.

The truth is, and this is a great quote by someone called Brian Foote, if you think good architecture is expensive, try bad architecture. The same is true for security. If you think, all those tools, you're like, how much is that going to cost? Yes, security isn't cheap. Also, neither is being on the front page, and especially in the last two years, we're seeing massive rise in ransomware, for example. It used to be that people would just take our data, for example, Marriott Hotels, Equifax, lots of customer data. Now what we're seeing is, ok, now you've got ransomware, now you've been [inaudible 00:34:26]. It's the same approach to security where you really want to try and have good security and add that to your already good architecture.


Why is this important? Why are we here? Why do we care? Microservices are awesome. I think so. Pros and cons, obviously. What you end up with is cross-functional teams, which is also awesome, and develop, test, problem solve, deploy, and update services independently. Instead of a monolith, you can scale, you can configure at the microservice level. This will lead to faster deployments and troubleshooting turnaround times. When we add security, when we shift left with security, so for example, to Terraform example, using Checkov scanning, or having app scanning as we're writing our different processes, this will mean less downtime. It will also mean less frustration. Actually, I don't think developers, security, operations, no one likes having bugs. No one actually likes them. Security sometimes like finding them, because then it's like, ok, I found a bug, job tick. Actually, we don't want to have bugs. Especially with the frustration, if you find your team is spending majority of the time firefighting, dealing with everything, you're going to be having a bad time. If you shift left, you end up being able to deliver better software faster. All of a sudden, if you can deliver faster, if you've got less downtime, if you can listen to your customers and you can hear what they're looking for, and you can deliver it quickly, and you can innovate and you can iterate, all of a sudden, you're going to start outperforming your competitors. Doing this all together will drive true business value.


Prioritize high risk, and high exposure vulnerabilities. Start with the 10s. Unfortunately, you might have some. Go have a look around. Let's start there, then the 9.9, 9.8. Think, who can do what and how? Is our front door locked? Is it closed? Are we rejecting people from doing whatever they want? That can be applied everywhere in the world of security. As you're going back to your day jobs after this, have a real think about, in terms of with your microservices, how easy is it for malactors to get in, and what can they do? Once you have that, having multiple security gates. Where I come from, DevSecOps, think about having this iterative approach to security, so that you don't end up with, hopefully, any high risk, high exposure vulnerabilities. If you are specifically interested in Log4j, I work for GitLab, we wrote this great blog about it. You can see the link here,

Questions and Answers

Wells: Any advice on how you get developers to feel responsible for security or to care about it?

Chaplin: Yes, it's a bit of a tricky one, especially with security. It's almost like passing the hot potato between different personas. Something that can be really effective I've found with developer groups is make it fun, and make it automated. When I say make it fun, what you can do is you can have, for example, like an internal hackathon. It could even just be an afternoon. What you can do is you can either have red team and blue team or put everyone on the red team. What normally happens is you end up with the senior developers, and then they normally know about a few skeletons in the closet, so they will find bugs. Then especially with the junior developers, that's something like, is it this easy? That can make them realize, maybe I really should care about security. Because also with security, there's been a real change over the last five years. It used to be, if you got hacked, all of your personal data or customer data, for example, would go, which is obviously very bad. Now it's ok, so if you get hacked, ransomware.

I was actually talking to someone literally last weekend, who works in IT. Their son is actually autistic and loves Hula Hoops. Because KP Snacks got hacked by ransomware, a few months ago, he could not get Hula Hoops to his son. His son was like, "Daddy, these are not Hula Hoops." With the way that security is moving ransomware, you really do not want to be hacked because then it starts to become serious decisions. First point, make it fun. The second one, automate it where you can. I really liked the question about the IDE plugin, because you want to shift left. You want to get it within the existing developer workflow. You don't want to have a case of where you're going through line by line. You want to have a case where a tool goes through line by line, you get your results. The results are then delivered to a developer in a way they understand. Ideally coupled, you can also get secure coding integrations. I used to work at a company called Secure Code Warrior. What will happen is, if a developer is told, it's insecure deserialization. What does that mean? When actually that's to do with the way that it breaks down from bigger options down to the block of string. Yes, helping developers understand the importance of security, making it fun with a hackathon. Also, with the hackathon, you don't even have to have real prizes, you can have an Uber Eats voucher. You could be nice, you could have an iPad, but even recognition. Recognition is so important. For example, a letter or an email from the CISO, or the VP of engineering, "Well done for your activity in a hackathon." Some people want public recognition, some want private. Also doing that as well. I think definitely awareness, carrot and stick with it. Where you can, make it fun and make it automated as well.

Wells: I worked somewhere where they did something similar, and I was a bit nervous about doing it but it was so much fun. There was so much guidance on here's what you can do, that it was absolutely great. I second it, it was really fun.

We have Black Duck, WhiteHat in our CI/CD, is that enough or should we be thinking about other tools also?

Chaplin: Black Duck, from my knowledge, focuses on open source. That might be the components that you're getting from Maven Central or PyPI. That is one piece of the puzzle. What GitLab offers within its pipeline, you have static code analysis, that's the code the developer writes. You have your open source, so that's what Black Duck is doing. You do dynamic application security testing. Are you leaking anything in headers because it's the running application? Secret detection, are there any API keys or any other credentials out there? API fuzzing. If you've got APIs especially in microservices, that's important. Code quality. I know there's about seven or eight. Black Duck is a great place to start. All developers use a lot of open source, but there is really a very big piece of the puzzle. One of the benefits of using GitLab is you get all of that testing in one place, and you get all the results in one place. Then the developer at the point of code commit, can run their security scans, they can see, I added Log4j version 2.17, that still has lots of vulnerabilities. I need to upgrade to 2.19, for example, or whichever the latest version is. It's a good place to start. I would recommend thinking about having other security tools.

Wells: As we close the platform with security first in mind, we do perform penetration testing twice a year via a specialized third party company. What is your thought on that? Is it too much? Is it not enough?

Chaplin: It depends if it's the only thing you're doing. Because you've said you create a platform with security first in mind, to me, like if I just read the first sentence, I'm like, you're thinking about the secure by design I mentioned at the beginning. Maybe you're doing threat modeling, you've potentially got the security in the IDE, then all the others in the CI/CD. If you have a security first approach, and then you've got security integrated, then, yes, pentests, they're good, but are they enough? I've worked with an organization, what they did, they were actually using Veracode. That's another static code analysis. They would go to the pentesters and say, these are the bugs we already know about from our security tests, we want you to find the advanced ones. I think that's where pentests really comes into its element, because you've got your low tier easy bugs, and that's where you can get the automated security tools. You want your pentesters to really try and find some weird and funky angles, similar to say like bug bounties. For me, the difference between pentesters and bug bounties, it's almost the same skill set. It's just different people doing them. I don't know enough about the rest of the security you're doing. If you're only doing pentests twice a year, that isn't enough. You want to look at some of the other approaches I mentioned. If you already have everything, then yes, I'd say twice a year, or every couple of months is a good amount. Just make sure they're focusing on the advanced pentesting.


See more presentations with transcripts


Recorded at:

Jan 20, 2023