It. Last March, with the coronavirus spreading uncontrollably across the United States, cyber soldiers released their own contagion by sabotaging a tiny piece of computer code buried in a popular piece of software called solar winds. The hidden virus spread to 18,000 government up a secret backdoor to the 18,000 infected networks. Microsoft has assigned 500 engineers to dig into the attack. One compared to a Rembrandt painting. The closer they looked, the more details emerged. When we analyzed everything that we saw at Microsoft, we asked ourselves how many engineers have probably worked on these attacks? And the answer we came to a new phone or a laptop. You trust that that is secure when they give it to you. And what they've shown us in this attack is that is not the case. They have the ability to compromise those supply chains and manipulate whatever they want, whether it's financial data, source code, the functionality of these products, they can take control. The hidden virus spread to 18,000 government and private computer networks by way of one of those software updates we all take for granted. The attack was unprecedented in audacity and scope. Fives went rummaging through the digital files of the US departments of justice, state, treasury, energy and commerce, and for nine months had unfettered access to top level communications, court documents, even nuclear secrets. And by all accounts, it's still going on. Hello and welcome here to this video. It's a pleasure for me to see you here and what we want to talk about today. So today we want to talk a little bit about how to start with security inside DevOps environment. What is main or what are the four main areas of cyber defense and what you can do. What was leading to this executive order of cybersecurity and why build info or build metadata is a very good weapon against cybertext. If you're interested in this, stay tuned. By the way, my name is van Robert. I'm developer advocate for JFrog and I'm mostly running around in the german woods. So far I'm here on my second day of hiking inside the german woods. I'm taking you here to two journeys. One is here to the german woods and the second one is to the cybersecurity. And if you like it, give me a thumbs up and subscribe my channel. I really would love to see you as my new subscriber. So enough around, let's start. Okay. As a small appetizer in the beginning I want to talk a little bit about what happened in the short pass. And this was this solar wins hack because this will show us the different possibilities or the different angles we have to look at to see where are the attacks are coming from and what we can do against these different attack vectors on our side in our daily developer business. So, first of all, who solowinds? Solowinds is a company in us, and they have approximately 300,000 customers. And this is a regular software company, but they have a special product. And what the product from SolarWinds? Well, the product from SolarWinds, what makes so interesting is that they are producing software to manage network infrastructure. And managing network infrastructure inside a company is a very critical part, because you have access to the whole communication part inside a company, and you can get all the information, you can redirect information, you can disconnect connections, and so on and so on. So the network infrastructure is a very, very critical part. And if you have software that's managing the network infrastructure, you need very high rights. So per definition, this is running with administrative rights. And if you are able to compromise this piece of software, you have a very, very good possibility to break into a lot of different subsystems. And this was more or less the case. But they not try to find a weak point in this software. They have done completely different approach. So if it is not the approach to find a weak point inside some piece of software, what an attacker could do, and this is really new here at this story. So we have so many compromised software already. But there was a special thing. So the hacker group, a person or group, you never know. But the attack was not against this product itself. If it is installed somewhere, it was against the CI environment inside the SolarWinds company. So inside the SolarWinds network, they broke into this one, searched for the CI environment, and then they manipulated the CI environment itself. Why? What they've done is they search for place inside the CI environment and compromise the CI environment in a way that with every new build. So with every binary that was produced, they are adding some compromised binary to this one, so that after the build was finished, the regular binary that was produced is a compromised binary already. And the functionality. So what happened? So they manipulate the CI environment. The CI environment was able to build the next binary. The next binary was released, and this release was provided via an automatic update to 300,000 customers. 300,000 customers means that not 300,000 servers are potentially attacked. No networks, every network will have a bunch of servers. So we are talking about 300,000 potential networks or network combinations or compositions that are attacked by this one. So what happened here? So they built this compromise binary. They pushed it to this automatic update stream. And approximately 15,000 to 20,000 customers asked this automatic update to load this binary to verify it's a binary that's provided for SolarWinds for sure. And then they installed it and updated their own installation of this Orion platform. So the product from SolarWinds, and then the software has done nothing for two weeks, and then it starts searching around. So what's going on in the network? And started loading different binaries from the Internet as well. And with this, every infection bind SolarWind, or by the initial Solarwind compromise binary was a different infection. Because if you have just one infection and okay, this is the open door, and you're closing this open door, it's fine. But this software was so cool that it was grabbing different binaries, started to install different things inside the network and so on. So every infection with the SolarWinds hack was completely different. So if you are removing the original SolarWinds infected binary, that's just closing the door, but you have a bunch of open windows, it's a nightmare to get rid of this stuff. Mostly what was necessary, well, mostly it was necessary to destroy the whole infrastructure and start from scratch and then make sure that there is no infected binary somewhere so that all this stuff could happen again. And then you must be able to identify this so that's never imported again. But we have a few different points now from the solar wins. And we have some reactions because this attack was so huge and the impact was really, imagine potentially 300,000 networks infected. And what are the customers of the solar winds platform, from the orium platform, us governmental institutions, healthcare, banks, military, space, automotive, all these companies with huge networks, because they need software to manage this huge network. So this infection, the solar wins hack, was really a nightmare. Okay, for sure, this solar wins infection was really a disaster. And it hits a lot of governmental institutions as well. So we have different departments. I don't know if it was defense as well, but it was definitely infecting a bunch of different governmental institutions from the US government. And this was leading to a reaction. And this reaction was called the executive order of cybersecurity. So I'm not a us citizen, so if someone told me about there was an executive order, I had no idea what this means. So what is an executive order? An executive order is something that is changing the way the governmental internally works. It means the US president is able to give this executive orders. And with this executive order, okay, let's describe it like the US president is like the CEO of a company and inside this company, I can't change the law from outside. So tax law or whatever, but inside this area of the law or all the rules, I can change the way the company is operating internally so the internal processes I can completely reconfigure as a CEO. And this is exactly what a president can do in us with his executive orders. He can't change law, he can't change the way tax are calculated or whatever. But what he can do is he can define changes of internal processes. So how the it is operating, how whatever thing is going on. So the internal way of operation, this could be changed by the US president. And the US president, Ms. Biden has done it. So there is this executive order of cybersecurity. Before we are talking about the content of the executive order of the cybersecurity, we have just in mind that this is just switching the way the internal it department is working. And I want to explain a little bit about the four different main areas you have. If you're fighting against cyberattacks as a regular developer, we have possibilities every day. And I want to highlight the four main areas before I'm talking about the content of the executive order of cybersecurity and then what we can do against it. So I spoke about the four main areas, or tool areas we have against cybertext. And the first one I want to highlight is zaster static application security testing. So what does it mean? Static application security testing means that you are scanning in a static context all parts of your whole tech stack. So first of all, it makes no sense to scan just one layer or one technology. If you want to have really the full impact of all scanning technologies, you need the possibility or you need a tool that will give you the knowledge or the information about the full impact graph. It means really of all tech layers. So whatever tool you're using, use a tool that is really able to scan all different technologies, not only one single technology. So static application security testing, what does it mean? You're writing some code and then you could scan your source code. Scanning source code is okay, it's more and more important all the time. But so far it is asked on machine learning, pattern matching and all this stuff. The technology is evolving quite fast, but the results are not really, they're not so strong so far. So it's too early to just trust the scan of your source code. On the other side, the opposite of source code is binaries. So scanning all binaries is a very robust technique so far, because, you know, they are binaries. You know the fingerprints, you can identify if they are compromised, you can identify what kind of infection is inside. And then if you're looking at all the different pieces inside your tech stack, I assume that most projects will have 99% binaries compared to source code. Well, I will cover this in a few minutes. But so far as the static application security testing, what does it mean is it's scanning every single component. The pro of it is that you can do it immediately. So if you're writing the first line of code, you can scan all components. What are all components? Your libraries, your dependencies, operating system, compiler, tooling, CI environment and so on. So all this stuff, the negative part here is that you're missing the dynamic context of an application. So you can scan configuration files, but you don't have the dynamic context of this. And then you don't know what it really means in production later. So you can guess, but you can't really verify it. So the static application security can start very early. You have a bunch of tools, it can scan 100% of it. You're missing a little bit the dynamic context of the system, but it's a very robust and fast technique. The next thing is the opposite of it, the dynamic application security testing. So what's dynamic application security testing? Dynamic application security testing is exactly the opposite of dust, the static application security testing, because here we are doing this hack approach, so the application is running already and then we try to break into the system. So we're looking at this facade. We have no clue what's internally used, we have no access to the internal components. We just see what is the API we can use to attack this system. Attacking this system means we need some defined attack vectors, and the most attack vectors are defined based on the most common vulnerabilities. The most common vulnerabilities are a definition of vulnerabilities of the most available source or mostly available in web systems. So it means SQL injection, heap dumps and so on and so on. So there's a list of these most common vulnerabilities, 1015, 50, whatever you want to have. But the main thing is here you can start with dust earliest if you have something that is running already, so it's way later inside your production pipeline or inside your product lifecycle, because you need something that's running. The next thing is it's good that you are scanning the dynamic part, but it makes just sense if it is nearly production. If you're running dust on a test system, you're missing all the possibilities to identify if this is for example a weak configuration. Do you have too many open ports and all that stuff? So the runtime of dust, and this is really a bad point, is exponentially, mostly exponentially. So it's really taking a lot of time because you need this system running and then you need to really activate every single attack vector at once. And the system must be strong enough if you want to use dust against it. So that's surviving. It's a good and a bad thing. So you need to test it mostly in production. But on the other side, if production is surviving, then it's really good. But the main thing here is that you have mostly software as a service tool. So cloud providers, so your application needs via VPN or direct Internet connection so that you can use this software as a service approach when they are attacking your system. The whole thing must be installed already, it must be near as production as possible and then it will take some time, you will have the feedback. But the attacks are mostly based on this miscon. Vulnerabilities means if there is a new attack vector, the tools mostly not, they are not so easy to configure against new attack vectors. So it's mostly not possible to define your own attack vectors with this. There are some different approaches with this tool so that they try to do with fuzzy logic or whatever, try to identify new attack vectors, but mostly they're based on the most common vulnerabilities. If there is a dedicated new attack vector, it will take some time. I assume that this provider software will try to update it as fast as possible. But again, this is quite late in the production. So we have dust, static application security testing. We have dynamic application security testing. Dynamic application security testing, by the way, is not able to test 100% of your system. It's just able to test directly the functionality that's provided outside in indirectly all layers internally. And what would be the next step? If you have the static one? If you have the dynamic one, what's the next one? And this is called IAS interactive application security testing. The combination of zest and dust is called is interactive application security testing. And interactive application security testing means that you are mixing both approaches and adding new functionalities, like this interaction part. It's done during the time. So you have first of all the functionality of the static application security testing. You have the functionality of the dynamic application security testing, but in an approach that you can do it inside your development environment or inside your CI environment, and it means that you have something like a security debugger. So you're running this application, you have access to all components. During the SAS part, you have the dust part that is running with the miscom vulnerabilities against your system. You are analyzing during this time, this behavior of your system, and then you are manually defining new attack vectors. So you are really doing step a, doing step b, analyzing what's going on, try to break into the next layer and so on. So this interactive part is a very powerful part and the combination of both is just a logical next point for sure. But if you want to have an effective, is this interactive application security testing? You need some developers, cities are testing, but now we are talking about protection. So runtime application security protection. The big difference here is that this approach makes only sense in production or on production systems. It's an agent like approach. So you're adding an agent, this agent is adding something like debug information to your system and then it's possible to identify an ongoing cyber attack. So what does it mean? So you have two possibilities. With this software or this approach, you have this monitoring approach. It means that you are monitoring and alerting and you are analyzing all data flows inside your application in real time. So something is going in, something's going out, there's user interaction. If the user interaction pattern is good or bad, or you should identify something or whatever, so it's really analyzing this machine learning approaches, what's going on in the system and try to identify this is an action that is not good, or there is a cascade of actions that are not really what's mostly going on here. And then you have the second possibility, not only alerting, you have the possibility to switch off automatically. So the system will identify there is something like in cyber attack, I will switch off the system now, and then it's just shutting down. So with this runtime application security testing, the approach itself is perfect. So I don't want to say something against the approach, but this approach is just possible. Inside productions makes just no sense in all earlier stages. So it's really late inside your production. And if you are identifying just there, you have a weak point, then it's quite expensive because you have to go to the earliest stage in your production and have to do all this stuff again. The next thing is that if you're using this rust approach, it's not a good point to start with security. It's very good. Add on to security because quite often if you have developers or users of the system or administrators, then they say, okay, if there is something not good, this will catch all of this cyber attacks. And this is difficult and a dangerous mindset. So you have to be aware of this, that it could happen, and you have to work against this mindset inside your environment if you're using rasp tools. So rasp itself is perfect. But now we are coming more or less to the point. If you have this four different approaches, what should be the first approach? If you start with security, what is the order to introduce different steps of this one? So we have now this four different ways or these different strategies against cybertex, known vulnerabilities, unknown vulnerabilities and so on. So it's now the right time to decide what is the tool you should focus on or not really the tool, the technique you should focus on. If you start with the cybersecurity or with a security topic inside your development chain, having in mind what happened with the SolarWinds hack. So the SolarWinds hack, it was a hack against the CI environment. And with that we have two new dimensions to look at. First of all, you have to protect yourself against consuming compromised stuff. And on the other side, you have to protect yourself against distributing compromised stuff. And this is really the new thing. So the attack against supply chain, so they searching for multiplayers, they're searching for weak points inside the supply chain to attack. Did you ever check your own CI environment against known vulnerabilities? Have you ever hardened your CI environment? Have you firewalled around your CI environment? And so on and so on. What's with your agents? What's with your compiler? Did you ever check if your compiler is not compromised? So all these different things we need to have in mind, because we have now attacks against all components inside the production line or supply chain. Okay, so if you're new to security, what would be the best place to start or the best technique to start for this? Having in mind what you have, first of all, you have this runtime application security protection. This is definitely not the best place to start or not the best tool to start because it's in the end of your production line and it's just identifying active cyber attacks and then it's just too late. So the next thing is we have these two main areas, a static application security testing and this dynamic application security testing. The interactive application security testing is a mix of both. The interactive application security testing, okay, means that you need the knowledge of how to attack a system. I assume that for this you need dedicated people or you need high skilled or high trained people to do this. If you don't have them, it makes no sense to do the interactive application security testing. So if the last two things that I hear left over is static application security testing and dynamic application security testing, my personal approach is always try to identify as early as possible weak points. It's like quality, it's like performance, it's like everything. So shift left with security. Shift left means that you start with security as early as possible inside your production line. And now comparing this zest and dust. Dust needs a running system already and it's not able to look inside your system. So you don't have the full potential of finding all known vulnerabilities on the other side. With zest you have the possibility to start immediately with the first line of code inside your ide, with a plugin to get all the knowledge about dependencies and this stuff. And you can fight against known vulnerabilities immediately. Having in mind that the amount of known vulnerabilities is way bigger than the amount of unknown vulnerabilities, it makes sense to focus first of known vulnerabilities. So what you need, you need a vulnerability database that is a superset of different vulnerability databases. The different vulnerability databases must be merged. So we at JFrog, we know that whatever vulnerability database you're choosing, you have just a subset of vulnerabilities. So we have this approach of merging different vulnerability databases to build this superset. Okay, if you have this one, then identify what is better to focus on, source code or binaries. Source code is mostly a tiny part inside your whole application. If you're comparing in all layers, what is the balance between binaries and the balance between source code? You will find that in most systems, the amount of binaries in the corresponding lines of code are huge compared to what you're writing by yourself. Inside your application you have a few lines of code and a bunch of binaries. In the operating system you're just adding a few configurations, and you have a huge amount of binaries inside your virtualization environment, kubernetes environment, and so on and so on. So you have mostly 99% binaries compared to what you're writing by yourself if you're looking at the whole text. So you need a place where all binaries of all tech layers are coming together so that you can have the full impact graphs, knowledge about all layers, all binaries that are really used and how they're used together. And if you have this one, then with a knowledge of known vulnerabilities, you're protecting, again the biggest part of vulnerabilities, and you're protecting the biggest part of your whole tech stack against these known vulnerabilities. So, focusing first on static application security testing, because you can use tools, you don't need special knowledge about it. You're not only limited against most common vulnerabilities, you can use the knowledge of all known vulnerabilities, and you can do it immediately, even if you're doing it right inside your ide with some plugins that you're connecting to your security tool, and that will scan your binaries, your dependencies, immediately if you are adding them to your bomb. If you know a little bit more how to do it in a practical way, I would suggest to look at my YouTube channel. I have a few examples, for example, how to harden the Vardin stack. It's an open source project. And I will show you how to find against this polymorph or this polyglot environments where you have different technologies that are hidden by different other technologies, but you want to have the full impact graph and so on. So, have a look at my YouTube channel. There you will find some talks about how to use tools, what tools you can use, and what is the potential of scanning against polyglot environments. So my recommendation is start with dust. Then if this is established, then try to add dust to your test and later to your production system so that you have this dynamic application security testing. It depends if you have people that are really skilled in this area that you can. After this merge, birch approaches with two. Two is this interactive application security testing. But mostly it's start with dust, go over dust, and then finally at RasP as well. So yeah, this is more or less what I recommend, but I'm not the only one that thought this is a direct and good approach, because now we are talking about the content of the executive order of cybersecurity, or the content of the executive order of cybersecurity. So, Mr. Biden gave this executive order of cybersecurity. And the content is the following. So every software that's operated, used, created by the US government must fulfill the requirement of creating an ANS bomb is a software build of material. That means that all component this software is built of must be written down in terms of what is the version, where it's coming from. So the reference in the repository and fingerprint and all this stuff. So it means you need really 100% complete component list of all components of software that they're creating, that they're using or operating by themselves, or they're using directly or indirectly. Okay, so what does it mean? So if they're using something on Amazon, then Amazon, the whole tech stack must fulfill this S bomb. Otherwise Amazon is not able to make money with the US government. If you're looking how much money the US government is spending on software or software operations, then you will see it will affect immediately not only the US market. I'm in Europe. Should I take care of this one or should I be prepared? Well, I'm working for a company. This company is creating a product. This product is used by a company that's working for the US government. Right. You're in. So it is more or less affecting the whole economy because so many companies are working directly or indirectly for the US government or producing software that's used by the US government that over short or long, everybody will be affected by this one. So what's an SBom? S bomb is a list of all ingredients that you need to create the sofa. So it's a full component or dependency list. But on the other side, this is nothing new. And if you're looking a little bit around what's available. And now I want to talk a little bit about the metadata of build information. Okay. Metadata of build information or the metadata of a build or built info. Let's call it build info. So what's built info? Built info is a context of how to create binaries and what is content of it. It's all dependencies. It's a date times operating system that's used agent name, library versions and so on and so on, compiler version and so on. So the build information is something that is describing the context of how to create this binary. So if you have the description of this binary, then it's a superset of the S bomb. So if you need the S bomb and you have a possibility to create built info already, then you have this S bomb. It's just subset of the information you need. Why you should use built info instead of pure S bomb? Well, if you want to analyze if something is attacking you or there was an attack against your systems, you need a lot of information about the context of how this binary is created, this compromise binary for example. And then it's good if you have all this information about what's the agent name, the operating system version patch level, and so on and so on. So that you can identify what was a weak point or what is different at this dedicated area compared to others, so that they use this for nativ and so on and so on. So if you want to have something from postmortem analysis, if you want to have a description, so that you can recreate exactly the context of some situation. You need the build info. So if you want to know more, search for the term build info and you will find information about how to get all this information with free available tools so that you can create this build info. And inside the build info, one dedicated part is the S bomb as well. What you need to work efficiently with build info is you need a tool that's representing it in a nice way. You need the possibility to combine it, for example with vulnerability databases. So you have here the build information. This is immutable, you are not changing at any time or not in the future. And then you need something that is correlating, for example the actual list of vulnerabilities with this build information so that you know later we have an update in vulnerability databases there are new vulnerabilities. Correlating it to the build information from binaries that are created already. Then you see this vulnerability is here active in this build information that was used or that's part of the creation of this binary that's running there in production. So you don't need to scan production, you just need to hold build info so that you are able to decide what vulnerabilities are active inside your production environment. So what you need, you need a place where you're storing all binaries so that you have the full impact graph. If you have the possibility to store in one central place all binaries from Docker images of maven dependencies, debian repositories and all this stuff, then you can come with vulnerability scanner that is scanning the whole amount of binaries. You need a place where you're storing this build info so that you have the information what was part and so on. And then you have a whole package against non vulnerabilities. You have the package against attacks like the solar wins hack. If you want to get rid of infectious binaries, for example, because what you need to do is there is a vulnerability and then you need to know what are the places where this binary is used. So this jar is used in this web archive, it's asked in this docker layer, it's used in this docker image consumed by this helm chart running there in production. So that is what I mean with a full impact graph. So everything together about this cybersecurity stuff, we have a huge amount of attacks, we have no attacks against the supply chain. Focus first on known vulnerabilities inside boundaries, because with this you are protecting the biggest part and it's the fastest way to sort then add the dynamic application security testing if you're doing this already and maybe later the runtime application security protection if you have the possibility and allowance to use agent based approaches in production. On the other side, how to prepare for the SBOM well, search for build info and you will see what tools are available to create this information of what is used for creating a binary. And then you have the SBOM already and it's cheap because you can do it for free and you can do it for your open source project. So if you want to make sure that your open source project is used or is able to be used in all environments, start creating S bombs and then you are safe at this site. So for this I want to say thank you that you attended this talk or this video and I hope you got a few new impressions. If you have more questions about this one, don't hesitate to contact me. Twitter, LinkedIn, YouTube and just don't use email. Don't use email. This is a disaster. So use everything but please don't use email. But in the end, if you have any questions, feel free to contact me. I'm giving free workshops. We can have a discussion on different social media platforms and so on and then let me know what are you thinking about it? What's your approach? Do you have any experience with these approaches already? And let's start a good discussion about the topic security because this is a really hot topic. So what I'm doing next? Well, my day is done. It's the second day of my hiking trip, so I will now pack my stuff. I have my base camp here from last night. I will pack it now. Together we'll have something to eat. We'll walk, I think in this direction to my car. It will take, I don't know, two 3 hours and then I'm done for today. And I hope you enjoyed not only the topic but the environment where I'm here as well. And if you like to have more of these auto starlight here, related videos or Java related videos, check out my YouTube channel. I really would appreciate to have you as my new subscriber. So whatever time you're watching this, I hope you enjoyed it. Have a good rest of your day and the only thing I can say thank you very much. Stay safe and see you're.