The Quick Wins of DevSecOps

 By the way, my name is Sven and I’m developer advocate at JFrog and mostly known as the man in the woods. If you can see I’m in the forest right now. And I just love it because it’s a perfect time to think about complex IT challenges. So together with me, you are now on two journeys.

 One is to the DevSecOps world, the other one is here to the deep German forest. And well, let’s see what we can do and enjoy.

 What is the difference to other topics with security if you want to integrate it into the DevOps world? Well, let’s see what was the DevOps world?

 The DevOps world normally is something that is focusing on the development of this process, how to build software and if you’re reading Wikipedia, you will see it’s most likely describing from coding, building, testing, packaging, and all this stuff until it’s running production. And the common thing here is that all of this mentioned steps are dedicated production steps. But now, we’re talking about security.

 Is security a production step? No, security is no production step, security is something that you must integrate in different steps and mainly, you have to integrate it in every step, because security is something like quality. So let’s see how we can include this one or better what we learned from the past and what we can do now to work with this topic of security. So in the past, we have this Dev and Ops teams, and they have booze, they are production steps. And they had in common that the Dev pod was creating the binaries and the ops pod was grabbing this binaries over to repository like Artifactory, for example. And then pushing to production, let it run.

 The shift from ops and dev together to DevOps was focusing on technical requirements on different production steps and all this stuff. So this was running well, and is now more or less established. But now we come with security, if security is everywhere, means that every tiny step has something to do with security, because security is not this dedicated step.

 Okay, the final question is, how to integrate security in the DevOps world to be in dev sec ops environment?

 It’s just, you have to think about security in every production step, I will show you a different ways and how we can go with shift left as much as possible.

 But in general, security is something that is more like a culture, everybody must be aware, it’s not just a product, a product will help you because as a human, you’re not fast enough. But it’s not just buying a product, and it will not slow you down. So if if you’re doing it right, you have the possibility to have the security implemented in a way that’s just not slowing you down.

 Even if you’re doing it right, it will improve your quality as well because quality and security, they are just good friends. But we’ll we’ll come to this topic a little bit later. So, how to Integrate security? Well, everybody’s part of it. It’s a team responsibility. It’s something like a culture.

 Read a little bit more about this one. And we’ll find out that security is like quality.

 It’s just everywhere in your pipeline. Okay, these dev ops or dev sec ops, but people are talking about site reliability engineering. Can we combine this one? What’s the difference? Well, the main thing is that site reliability engineering comes from the Google universe, so they have this approach of, we have a dedicated engineers that have to work on automate all this stuff. And the definition from Google is that SRE is mostly focusing with maximum 50% of its working time on operations, and the rest is development. So what does it mean?

 In the end, it’s more or less the same. It’s dev ops just in one person. So it’s a very experienced developer that is focusing on operations or it’s a very experienced operations guy that is now focusing on development. So whatever you take, so this SRE, site reliability engineer, is more or less exactly the middle between Dev and Ops. So fit this post together? Definitely. Because DevOps is just a process, it’s a way how to organize all this stuff. SRE is a role. So does SRE fit in a dev ops or dev sec ops world?

 For sure it fits perfectly, because these are mostly the people that are exactly in the middle and the huge potential here is that this SRE, this service reliability engineer, can glue both parts together, the security in the operations and security in the dev part, and take this as a chance. And well, the short answer fit this together. Definitely.

 Okay, we saw that dev ops and SRE that are merging or fitting perfectly together. But what I’m explaining in the next steps is not bound to DevOps, or SRE, or whatever. So even if you have a very classical project management style, if you have dedicated teams, you can use everything I’m explaining right now, because this is a little bit more generic. So security is not bound to a dedicated product management style.

 Security is something that you can implement everywhere, but the full potential, what I’m explaining, you will get in a DevOps or dev sec ops environment. But now, let’s talk about an example. And the example is… solo in tech. So surprise, surprise, what was the big incident during the last one or two years?

 It’s Solarwinds. So I don’t want to go into all the different details of the Solarwinds hack, but I want to mention a few things that are very inspiring for what we’re doing next, or it’s best thing what we should use this lesson learned. So first of all, this hacker group broke into Solarwinds. So who is Solarwinds? Solarwinds is a company that’s creating software platform that is used to manage network infrastructure. And well, surprise, surprise, if you’re managing network infrastructure, first of all, this is the most critical part inside the communication structure of a company. And the second thing is that, well, to manage infrastructure, you need to hire right, like an administrator. And so this was a perfect target, because Solarwinds has approximately 300,000 customers that are using this software. And what this hacker group has done is just they broke into this Solarwinds environment and use Solarwinds as multiplicator to all of their customers.

 But what happened? How did the Solarwinds hack work? So what happened here that this hacker group broke into this IT system from Solarwinds, Solarwinds is producing software, and the main target was not to destroy things or to make it unavailable or whatever, they just compromised the CI environment.

 Wow, the CI environment? Why? So what they have done is, they changed the build in a way that was every build they’re producing right now, they will add some compromised binaries from this hacker group, and then their official update, or their official release contains already compromised code. And just having one that this will be spread up to potentially 300,000 customers is amazing.

 It’s a huge amount of potential targets, so instead of targeting the final target or just attacking the final target, what you’re just doing is you’re going to multipliers and this will have now two views. So one, if you are the next Solarwinds, or if you are a consumer of Solarwinds. Say, we have two dimensions we want to have a look at because we have to fight against both sides. So if this is a new quality of attacks, that they’re going against the supply chain instead of the final target.

 Well, then we have to be prepared and say as I choose, did you ever scan your Jenkins CI against known vulnerabilities?

 Fight against all these attacks, what does it mean? What can you do? So talking about the DevOps environment, you have two parts, two main parts. You have the Ops and you have the Dev parts. So where should you focus?

 First of all, if you’re focusing on the runtime environments, and scanning runtime environments, I’m not sure if you really want to have it but if you want to test and running environments, you’re talking about DAST, dynamic application security testing frameworks and what they’re doing is they’re looking at your environment like a black box, they have no knowledge about dependencies, they have no knowledge about the technology you’re using.

 But what I want to highlight here is that this dynamic application security testing tools, they are attacking your system, try to break in and they need the knowledge how to do all this stuff and this is based on the most common vulnerabilities. And if you want to have some special attacks, then you need to customize these tools, you need this special knowledge, sometimes you have cloud environments that are not able to be customized. So what else can we do? Because we want to focus on some low hanging fruit, the quick wins, the biggest impact you can have inside your environment and this definitely incites a static party.

 Okay, we spoke about the dynamic application security testing and what is the opposite? Well, the static part, SAST, static application security testing, and I’m personally focusing on this one because it has so many benefits, because we are not only focusing against this most common vulnerabilities from auto because this is just a small amount.

 Now we are focusing on everything. So on bad code, we are focusing on known vulnerabilities, on compliance issues, and so on and so forth.

 Why? Because we have all semantic information, so we have everything about all components if you’re focusing on the static analyzers part, and we can do it even earlier than running in production. So if you’re just scanning during the time it’s running in production, it’s too late. So I want to fight against all vulnerabilities as early as possible and that means I have to do it in the dev part, not in the ops part.

 Ops isn’t good at on, but the main focus should be on the dev part, because this is earlier, this is not running in production, and you have way more information you can use to harden your system and this is why you should start on focusing on this static analytic topic. Okay, if we are looking at a forte stick, then we see that dependencies are 99% of our whole test stick. Why? So during the time we’re coding, we are writing some code, but most likely, we’re adding more lines of code directly or indirectly via dependencies or transitive dependencies.

 If we are then pushing this one to an operating system so that it must run, for example, on line x, we are configuring a little bit of [inaudible] but the rest of the operating system is a binary, it’s a dependency we are grabbing. Same with Docker, to start with the front statement. So we are adding dependencies, and samples, Kubernetes, and so on, and so on. So looking at the whole tech stack means if you’re talking about what we’re doing by yourself, make out what we are adding somewhere, by the dependency, this is biggest part of all ticklers.

 If we want to efficiently fight against known vulnerabilities, we must first focus on dependency because this is by far the biggest part in your tech stack. Let’s start with compliance issues. So what is the behavior of compliance issues?

 Why we should scan for them? Why this is part of the security? Well, security is not only a vulnerability, security is compliance. So securing the business as well. And it means if you’re adding dependencies, and that’s the biggest part, it makes sense to check all dependencies direct or indirect ones to make sure that we don’t have the wrong license at the right place. And this is just poison for the business. So what do we need to start fighting against compliance issues?

 First of all, we need someone who’s authorized to decide what is the right license for what part of your production line, because then you need some legal advice or whoever is able to decide it to make sure that you have an initial list of allowed white labeled license and black labeled license, so not allowed license. So if you have this one, then the good thing is the machine can just start scanning. So with this yes or no license, or if there’s exclusive no license for transitive or direct dependency, why you should scan it always with every run? Well, mostly, if you’re scanning first in project, if this is running under the right license, you don’t have an issue anymore with is because this mostly is not changing. But you have two things that could change.

 First of all, the project itself can change, for example just look at this. Java. ee, Jakarta. ee, NoEclipse. ee stuff. So there’s always a change of the dependencies. And it could be that the project maintainer from the dependency you’re using is not, well, so clearly with his maintenance of his dependencies. So maybe he is changing from Google Guava to come to collections of whatever. And then you have different license maybe or maybe not, but it’s always good if you’ve constantly checked, if there’s anything regarding compliance issues.

 But what’s happening if you have a compliance issue, so what is the work you have to do? So compliance issues, they’re good and bad in the same way, because the good thing is you can combine them. The bad thing is if you have a compliance issue, then you have to remove this single dot in your whole text x or this single dependency, and then you have to make sure that you’re changing it or replacing it by semantic equal implementation.

 This is not trivial. So find something that is just running on a different license but doing exactly the same what you’re expecting. So this can make some trouble, but mostly, the change of dependencies or transitive dependencies after you checked the license ones, is not so often. So if you have something, it could be really hard work. But mostly, if you’re clean, then there is no big issue, on the mid or long term. Be aware of attack vectors, different attack vectors. So talking about vulnerabilities, you have this common vulnerability scoring system cbss. And then we have this ranking between this different vulnerabilities between very risky, not so risky and so.

 If you want to know more about CVSS, I have a dedicated YouTube video that explaining the CVSS in detail. But the main thing I want to highlight here is that you need some tool that’s aware of what is the CVSS value of a known vulnerability. And the next thing is, even if there’s a low CVSS value, have a look at the full impact graph. So you need all dependencies over the whole tech stack, because you can combine different vulnerabilities to different attack vectors.

 Different attack vectors mean that the full amount of possible weak point in your application is not just every single point of a vulnerability, it is, in addition to this, the whole composition of all different attack vectors. And this means that even a low risk vulnerability can be combined with something else that can be very risky for your environment.

 What is the good safety build against known vulnerabilities and compliance issues? Well, one thing that is really, really good is a good test coverage. Why? Because talking about known vulnerabilities, you have to switch to different versions of the same dependency. So if you have a very strong test coverage, then you can just change versions in a way that you don’t have vulnerabilities anymore. And at the same time, with good test coverage, you can just check if there’s new composition of the same dependencies in different versions that is doing exactly the same what you need.

 If you have compliance issues, TDD is even more powerful because if you have to replace with a semantic equal implementation, you’re very happy about a good test coverage, because then you can switch between different implementations and check with your test coverage, if everything is running well. So TDD is one of the best safety belts against known vulnerabilities and you need a very strong test coverage. And one of the strongest test coverage I personally knew is mutation test coverage. Because it’s way stronger than line coverage or branch coverage.

 Check out my YouTube channel, I have the video that’s explaining the testing itself. But whatever test coverage you take a strong test coverage is your safety belt against known vulnerabilities and compliance issues.

 If test coverage is one of the best things against known vulnerabilities and compliance issues, so then you need something that’s managing all this dependencies, because composition of new dependencies or the replacement of dependencies of all tech layers must be part of this fight against known vulnerabilities and these compliance issues. So you need a single point, a logical single point where all your repository managers are managed, so that you have all these dependencies in one place. And then with one tool you can check, not only one tech layer, or one technology, or one, whatever, you can just scan the whole tech stack everything. And with everything, I really mean everything. So for example, your Maven dependencies, if you’re coding a Java, your DBN repositories, your Docker repos, your Helm charts, but even, for example, in your tooling, think about a Solarwinds tank. So the attack was against a supply chain means that if you have a Docker image with your Jenkins inside, just scan it so that you know and be aware of all this vulnerability at that time.

 So you need one single point, we have the same point with Artifactory because we know all these different repository types and we know all this metadata. So we are understanding not only the dependencies, we are understanding the transitive dependencies, until the last element as well.

 And then with Xray, Xray is a scanner, we are using all this binaries and this knowledge that’s inside Artifactory, including belt information and all this other stuff to give you the views of full impact graph about all known vulnerabilities and all license you’re using in your whole tech stack. And this is focusing on 80%, 90%, 99% of your whole tech stack. So if dependencies are by far the biggest part in your whole tech stack and you want to start with security, focusing on dependency, focusing on an efficient dependency management, focusing on scanning those dependencies against vulnerabilities and compliance issues.

 What are you doing if you’re infected with sort of attack? So the short answer is just identify all components that are infected, remove them and install from scratch was clean ones.

 Is it so easy? Well, if you have infected components, and you don’t know what other components are using this one, then it’s more or less a very, very long, long, long work and a lot of effort if you’re doing it correctly. So effectively, we have the support within artifactory query language, it’s an SQL query language where you can select different artifacts and then you’ll see they are used in some other parts, or they’re used by some other components because with X ray, we have the full impact graph, if you have the full impact graph, we can identify who is consuming what. And with this, it’s easy to make sure that we are removing the infected binaries, and then making sure that all dependencies are replaced by clean ones. So this is one point, if you have a single point where all dependencies are going through, you have the full impact graph, if you add the full impact graph into your query style language, where you can select partially trees, then it can remove everything and start installation from scratch. So this is why JFrog customers are quite happy about this query language, because with it, we can just easily remove the infected binaries.

 Okay, if you know how to fight against known vulnerabilities, there is one term that’s quite often mentioned and it’s very, very important. This is shift left. What does it mean? For example, if you’re shifting left the first time, it means that we are not fighting against vulnerabilities inside the production, we’re fighting against vulnerabilities inside our CI pipeline.

 With it, we can scan or binaries with every build, we can make sure that there’s nothing that is just against us in terms of known vulnerabilities or compliance issues but we can go even further or more to shift left. And this means if you’re just scanning insights as your environment, I’m not saying that we don’t need it, I’m just saying we need something additional.

 Because if you’re working the whole day doing the first commit or after a few hours then pushing towards the CI environment, getting feedback that there are vulnerabilities inside, we burned already some money. So we have to minimize this time as well. And that means we’re shifting even more left.

 Even more left means we are shifting straight away inside your IDEE so if you’re writing your first line of code, you know all the stuff you need. So for example, if this license is correct, do you have anything inside your transitive dependencies or indirect dependency that you should be aware of, do you know something about known vulnerability. And this is done with the IDEE plugin, so we are shifting left straight away inside the IDEE. And then if you’re adding the first line of dependency or your first line of code, you know already everything, what is the full impact graph inside the stuff you’re working on right now. So having it in ci environment means your have the possibility to have it over the whole tech stack, so from your application down to the helm chart.

 If you have it straight away in your IDEE you know everything with the first line of code you’re adding, you’re not burning time, and you’re not wasting your efforts. If you want to try it out, with this plugin. And we have it for IntelliJ, VS code, Eclipse. And it’s open source, it’s available on GitHub. So if you have any need, so you can just make some issues, or you can make some feature requests. Or if you want to push code through just make a metric first. And with this IDEE plugin, you can connect to a x ray instance. This is even possible with a free tier. So you just need to coordinate from your X ray instance your username, password, and then you can connect with X ray. And all the X ray information is then have a look inside your IDEE and how this

 looks like for a developer inside IDEE? I will show you in a very short screencast right now. Now, we have a short view to the X ray IDEE plugin, I just added in a pond dependency. So this is a version of what you’ll have, you will have in the IDE plug in here, some kind of window. I’m using IntelliJ. So, it could look a little bit different on Eclipse or whatever, then it will see as a dependency we added here already, here this 4120 and then you have to hold the pencil tree and you see there is a security issue with objects and data binding.

 What you get is ranking it as a high medium or low security risk. You will see the license information or type version and so on.

 The good thing is you can see here all detailed information for example, if there is already a fixed version available, and what time, summary of the issue itself. One cool thing is if you are somewhere, then you can just go here and say show him project descriptor, then you’re jumping here back to this one. Another thing is, if you decide to exclude, you can just go here and say exclude dependency, what you will get is the dependency exclusion. That’s it.

 The other thing I want to show you how to install it. So in IntelliJ, is quite easy. Again, as a plugin, you’re searching for JFrog plugin, updating it or just installing it. In IntelliJ, you have to do a restart, in Eclipse ir could be different. And then the only thing you have to do is you’re going to the settings of this x ray plugin, adding your coordinates, and then you can just connect your IntelliJ to the X ray installation.

 That’s it. Have fun. Okay, it’s time for the conclusion of what we learned today. So we saw that security is not only one step in your production pipeline, security is something like a culture, security is like quality, it’s everywhere, in every single step of your production pipeline, we saw that whenever you’re choosing DevOps, or the approach of SRE or classical project management, whatever security can be implemented in all of these project management crucial processes.

 What it means is that everybody in your team must be aware of what he can do to increase the security inside this dedicated step he’s working in. And we need the general overview, we need the full impact graph. So we need a view that is focusing on the whole tech stack of all technologies, and all processes. So security is nothing like I’m just buying a product, security is something that is a responsibility inside the team and the team needs to be the aware of it needs the power to decide what must be done to achieve better security.

 Focusing on security in the beginning mean that you should focus on the low hanging fruits, the quick wins and looking at the whole tech stack means that the whole tech stack is by far more than 90%, really, more than 90% in most cases, just management of dependency, it means you need a very efficient dependency management and on the other side, you need something that can handle all these dependencies, direct dependencies, transitive dependencies, indirect dependencies. And for this, we have Artifactory, because it knows all these package managers from Java, Maven over Dabian over Helm charts, Docker, whatever. And then with Xray, we can scan not only the binaries itself, but we can check the dependencies, indirect dependencies, and we can scan for compliance issues as well. So we have some knowledge about known vulnerabilities and compliance issues. And this with focusing on the dependencies means you have more than 90% of your system clean against known vulnerabilities. So if you want to try it out, we have this free tier. And there you can do two things, you can implement it within ci environment, where there’s a working horse and you must automate everything so that the quality is always the same, the security behavior is always the same, whatever time you’re choosing. And on the other side, you can shift left as much as possible. And with our IDE plugin, we are straight inside the IDEE, where you are writing the first line of code. And you need the all this information as well. So for what can you do is next, different things.

 First of all, you can attend a few of our webinars to get more detailed information about distribution, about Artifactory, about security, and so on and so on.

 If you want to have hands on experience, just register for one of our workshops, we have regular workshops, I can give them in German as well as in English. And if you just want to consume something on YouTube, check out my YouTube channel. I have a bunch of these outdoor IT related YouTube videos. So then thank you very much for attending.

 It was really a pleasure to see you here at this conference and enjoy the rest of the conference. Enjoy all the other talks. And well I would really appreciate to see you in one of my webinars, workshops or as a subscriber on my YouTube channel. Otherwise, what I’m doing right now, I will stay a little bit in the forest, we’ll cook a coffee, we’ll eat something, walk a little bit around to going home later and for you, enjoy the rest of the conference, stay safe and see you.