How Does a Developer Do Security

Hello, I’m Ixchel Ruiz. So good evening, good afternoon, good morning for wherever you are connecting from. This is How Does A Developer Do Security and I have tons of material that I hope we can go through and a demo and a really practical advice to actually do security as a developer. So who am I? My name is Ixchel Ruiz, I’m a Senior Software Developer and a DA at JFrog. So there is my information, my social information. I’m in Twitter, Mastodon, LinkedIn, and of course you can reach me through the JFrog webpage. A little bit about me, I’m from Mexico, I live in Switzerland. I’m a Java champion. I work for JFrog. I’m very active in different organizations, open source organization like the CNCF, the OpenSSF, like CDF.

I recently collaborated into some books. The latest one is DevOps Tool for Java Developers. So as you see, I have two passions. One, well I’m a developer, but also it’s about sharing knowledge and DevOps, security and Java. Today it’s real important that we as developers think about security because the world runs on software. Security is, and it should be, the first level citizen in our professional life. So how do we do security as developers? The first thing that you should ask Ixchel is where. Where do we actually focus on security? And my answer is as a consultant, as a developer, is it all depends. Well it all depends. Security has to be part of the entire software supply chain. The next question you should be asking me is like Ixchel, what is software supply chain? Oh, thank you for asking.

Well the fact that the software supply chain is everything that involves creating software from our JFrog perspective, it’s about duration, creation of consumption and the entire process. Because remember we are a DevOps. So this is again and again and security is so important because when we are attack and in any part of the software supply chain, it’s very expensive. For example, in this particular report from Anchore in the 2022 Software Supply Chain Security Report, 62% of thousands of people or organizations that were acquired said that they have been affected in the last 12 months and attacks and vulnerabilities are so easy sometimes to exploit and they are coming up so frequently that it’s super important that we have a really good understanding on the ones that have a great surface of attack and are easy to exploit. So for example, there are companies that are already trying to pay bounties for it.

For example, this particular company, [inaudible 00:05:10] is going to pay up to 2.5 million for each of the vulnerabilities that are high spread attack and low effort to exploit because those are the ones that are going to create the worst damage. So being in security actually does pay off. And in the last months, we have seen again and again information in the news headlines like attacks, how it’s actually impacting all organizations, all part of the industry. And as I said, it is so perceived by the industry. So the industry and our customers right now have in their mind securing the software supply chain. It’s going to be part of the one or two main focus in 2023 and 2024. And it’s really clear why is this happening? Because they have increased 742% in the last three years and that’s the average annual increased by the way.

And this is from the 8th Annual State of Civil Supply Chain. And for example, the number of renewable vulnerabilities reported in 2022 have quadruple compared to 2016. This is from the CVE details. As you can see, every single thing that I’m showing here, you can follow actually the report and the link or sometimes even the report. 95% increase in cloud exploitation. And even if we see more CVEs coming again and again, there’s some really bad news if you only focus on CVEs, well that’s an improvement. But there is a problem. For example, in our own security research we noticed that 78% of reported common CVEs on top of the DockerHub images are not really exploitable. So this is part of the problem. You are going to be focusing sometimes in things that either do not have CVEs or do not matter, they are not applicable to you.

So it is important that we understand how our software is being shipped by how the security is being established since the beginning. And one thing about our software is for example, 78% of the software that we are creating has hold from open source and 85% contain open source that is more than four years out of date. So it’s not a problem that we actually use open source because that’s not the problem. The problem is sometimes that we don’t research enough on our sources and the worst part is that we don’t keep it up to date. So we need to have caution when we are using software. But don’t think that I’m going to denigrate open source, I’m a lover of open source. I truly believe in open source and these problems that I’m going to describe apply to open source and to closed source. So let’s review really quickly in the last 10 years, the six massive attacks that we have heard actually. For example, Target, I’m going to talk to you about Target. And Target in 2013 had a huge attack and they literally came from the air conditioning.

That’s how they enter. The British Airways in 2018. They stole the customer’s credit cards. It was huge in terms of the fine and in terms of reputation. The one that push us to the headlines of every single newspaper in the world, SOLARWINDS in 2020. This actually changed the world. And you will see and I will explain really quickly how it actually changed the world from the foreseeable future. So how this happened, we have seen the massive attacks, the most dramatic ones, but why are we getting attacked? What are our threats? Where actually did it happen? Well, remember when I said that how CVEs have been reported in the last years, that how many CVEs have been registered in the last four years for example. Well that’s great, we can focus, we can use them to have an idea. We also saw that 78% may not apply.

For example, in the case of Docker, may not apply, may not be applicable to you. But there’s also another section of things that can be living in the dark for us. For example, the malicious components. Those are things that are going to bring problems into our source code that don’t even have a CVE declared. So what types of attacks do you usually are going to see out there? Well the ones that are targeting known vulnerabilities, the ones that are targeting unknown vulnerabilities because every single day, you can detect something. Every single day, the state of things that are vulnerable. It’s not that they are becoming vulnerable, somebody is noticing that they are vulnerable or new software that has been released. This is opportunity to start attacking it. And non-code issues like human error, something happened. For example, some of the most famous attacks the SpringShell or RCE vulnerability that was unintentional block caused by an open source vendor.

The SolarWind sunburst, that was a back door. That was intentional. And for example, that large scale NPM attack that target Azure developers with malicious packages, those are malicious components. They haven’t been assigned a CVE. So those are also very important that we take into consideration. For time’s sake, I’m going to go really fast into this one spot. If you have more questions, you can ask them or read our blog post because we go really deep into all this information in our blog post or actually connect for different workshops. So the infection methods that we were going to see, it’s typosquatting, masquerading, Trojan packages, dependency for confusion and hijacking. For example, typosquatting is when we make an error, we spell things incorrectly. For example, that has happened with domains like Google has bought so many domains that are close to Google because they also want to not allow anybody to actually register the domain, but they also want to provide the same functionality even if you make a mistake and a spelling mistake.

But then people are thinking about what is the probability for example that instead of using mplotlab you use another word and then you download or you install or you use an incorrect package. Masquerading is you impersonate a well-known package, you insert a specific small piece of code that is socially obfuscated and this has the malicious code. For example, this is Markedjs versus Marked and you can see that the download, the version et cetera are totally different. So they are trying just to confuse or use something that people are not very familiar and they may use it by error. And usually the malicious code is not tiny but at least it’s a single line of code that it’s usually obfuscated it. The Trojan package. The Trojan package is install something that is really useful.

Here, you are not pretending to be anybody else but you are providing really important or interesting functionality but you are, since the beginning, hiding malicious code inside it. And dependency confusion. What happens? Usually in our organization we consume, we generate different packages or different libraries and there are for our internal use. But for example, somebody outside know our naming convention. So what they going to do is exactly publish a similar package in a public repository with our name convention. So when the next developer is going to request that particular dependency, it’s going to request it from the outside instead from the inside because the version is the newest one. So that’s how they are doing this particular attack. Hijacking. Hijacking is in NPM. We actually need a domain. We need to be owners of the domain. We usually have an account, an email account.

That’s how you actually register packages and things like that. But domains expire. You need to pay for that. So what is happening is there are hackers trying to see what domains are going to expire in the near future. Take control without register. It is now their domains. It is now their email addresses, so it’s totally okay. And then you have this one that we don’t know how to classify because they’re still doing the functionality that they promised but they are doing something else. That was a really great discussion in the OSS Foundation. The other one is for example, what happens if you have multiple maintainers, if one particular domain also expires, for example, we have noticed at JFrog we actually studied that and we saw that more than 3000 packages in the NPM ecosystem have the possibility of being law like attacking that way.

Common payloads. Not that you have to be worried about the malicious code or all this information that I have you provided use that, but they also can have different payloads and this is, for example, you will have stealers. They attack credit cards, tokens, environment variables or they will have connect-back shells or download and execute code in yours. So because I really want to go into the solution part of the problem and the whole point of this introduction was actually twice or two different ones. One is to give you an overview of how broad this problem is. From the industry perspective, they see and feel the pain of software supply chain attacks. We can see that there are different types of threats and we have some clue that there represent a problem because there are a CVEs or CVSS. But there are some that they don’t even have a CVE.

And then even if we have the CVEs and we know that we have to pay attention onto those particular problems, what is going to happen is most of them are not going to be even applicable to us. So security is a huge topic. It’s as huge as it is important. And this is actually the problem that we have as developers. As developers, we already have our own tools, our own domains of expertise, our own programming languages. So attempting to be a security expert is frankly a very, very greedy and almost unattainable goal. But the good news is that we can use tools that are target and fitted for developers that are going to help us. And if these tools are really integrated to our organizations, what is going to happen is that whoever defines the policies in terms of what priority, what are we focusing, how should we focus on this and creating all this knowledge and disseminating it in their organization, they are going to use these tools to configure all that information.

So we as developers, we only need to consume, we only need to trust that our organization has defined the policies, has defined the right duration of information and we are going to use the right components at the right moment. So let me present you some of the tools that I totally recommend you to use nowadays. So shifting left. This is Frogbot and I actually love this particular project. This is a Git bot. What does that mean? That if you are using Git, which probably is the case because that’s the most used control version system ever, you can install it for example in GitHub and GitLab and Gitbucket, in Azure, and what’s going to do is not only check your dependencies but if there is a dependency that has a secure vulnerability established, it will actually generate a report. It will tell you, “Uh-oh, we found a problem.” And it will tell you where in which version. In which version was already fixed, what was the component actually the one that had the issue and it was the one in one component version. And if there’s no issues, it will tell you. Green light. Perfect.

Same thing can happen in the Docker desktop extension. If we already are using docker images and we have seen 78% of the CVEs on top of the top Docker images are not applicable, then it is important that we have that information in our firm group rates or even know if they have any security concerns, even if they’re part of the 78%. The other one, and this is something that I cannot stress how important it is for me and I’m Java developer as I said at the beginning. So Idea is my tool of choice and then I can install, for example, the Idea plugin. And with the Idea plugin, as soon as as I’m typing a new dependency, for example, in this screenshot that I will show you in the demo. As soon as I type Log4j with version 1.2.17, which now we know that it’s one of the horrible versions.

What is going to happen is at that exact moment there is going to be a security analysis on my palm or my dependencies and then it’s going to tell me, “Uh-oh, we have a problem, Houston.” So it’s not even at the kit level, it’s not even when you’re doing a pool request. At that time, it’s already too late. You already code a feature, you already fix the bar and then some suddenly they tell you the dependency that you use for that may have a problem. So it’s a really already a little bit late, but if you have it installed in your ID and it supported by ID and via code, it’s going to be in your development environment at your fingertips. So this is demo time, so wish me luck because this is going to be totally in demo. So this is our part of the screenshots.

Actually, I have to update my screenshots and don’t worry I will do it for when I publish them. For example, this is what I was telling you. In this case, if you see I’m working on a specific branch and you will see why that’s important. I’m in a branch vulnerability I think. Yes, in the branch vulnerability and in this branch vulnerability what I have added is Log4j for core in version 2.17.0. This is a Java Maven project. Then this is the poem file. And immediately when I’m adding this particular dependency, it will actually tell me that I have a problem. And this is part of the information I can get from my IntelliJ JFrog plugin. So it’s actually going to tell me the CVE and if it particularly has this icon, then we are in the best of luck ever because this particular icon says that we have very interesting research from our security team and it’s going to tell us tons of information from remediation details like why does the JFrog security team think that this is very severe or not?

So it’s going to tell us how the vector of attack it is prone, what are the public sources that we are actually consulting to generate this advisory And for example, the impact graph, it will actually tell you how far away in the dependency graph this particular dependencies is. And if you even want to know even more details about this particular vulnerability, you can actually check all the references. Why did I say that it was was important?

Speaker 1:
Ixchel?

Ixchel Ruiz:
Yes?

Speaker 1:
Someone just mentioned they’re still seeing the demo window and not the code you’re looking at.

Ixchel Ruiz:
Oh my God. Let me stop share and share screen. Thank you very much for that. I was describing this particular thing. So let’s see Idea plugin really fast. This is my JFrog plugin. As soon as I put 2.17.0 I have in the plugin this information and this is the icon that I was mentioning. If this is the icon that you see is the JFrog research where you can see the summary, read the mediation, the details. The public sources how for example the CVSS version 3.1 and the CVSS version two were actually calculated. So you actually know how this specter is actually created. The impact of the graph, as you know like the dependency graph or solution of Maven. It will show you how direct it’s from the app. If it’s a transitive dependency, a direct dependency, it will show you like that. And if you have more information about this specific CV and report, you have even more information about that.

And I was telling you that it’s interesting that I’m using a vulnerability branch and this vulnerability, well I call vulnerability. That branch is not a vulnerability branch. It’s like a branch called vulnerability. And this is where I’m adding this particularly new dependency. And this is important because now I’m going to share another screen which is, wait me a second, really important because and I’m going to show you in the GitHub page that I didn’t have open for some strange reason but now I have open. Now we’re here, perfect. So this is the repository in GitHub and as you can see in the pool request where I uploaded this particular branch, the vulnerability branch, it actually is telling me when I try to open this port request, it actually activated Frogbot checked and this Frogbot check is going to tell me exactly what we expected, that this is severity on this particular dependency Log4J is actually telling me what fixed version it is done, et cetera, et cetera.

And I will tell you, this is the other part that I love Frogbot. If I were to say I don’t care, I’m going to merge it into master because sometimes that happens. So what happens is I’ve merged it right now into my main branch? What is going to happen is in the background there’s going to be another action. And this going to be, for example, this scan and fix. And what it’s going to do is it will figure out that I have a vulnerable dependency on my project and is going to automatically create a poll request where it’s going to fix that particular vulnerability and the last and not the least. Remember the slides and I’m going to stop this share and start the share with this one now. Now you’re seeing it. This is Portman desktop.

Portman desktop is very similar to Docker desktop extension, but this one is from our partners of Red Hat. So if you can see here, I’m scanning Alpine version 3.11 that we know that has some vulnerabilities. So after I scan this particular image, I get all these reports saying that we have one critical, 23 highs, medium and low. And then you can see a lot of also really important information. The impact package, the version, the type, the fixed version, the CVE, the CVE3, the CCB2, a really nice graph of how deep is this particular vulnerability in this particular package, more references. So now honestly at any level we can have all this information in your IDE, even before you create a pull request, even before you push your code into your repository. At that point, you can check it. When it’s already there. You can check it. When you already match it, you can check it. When you are already creating or prefers consuming your Docker desktop images, you can check it. When you are producing your Docker desktop, like your Docker images, you can check it.

So we honestly don’t have any more excuses to not apply security scans in our daily life. Let me share again my slides that are somewhere here share. Perfect. Because I didn’t show the most important one. There is going to be a webinar soon about how CISO do help us as developers to implement security, and I totally invite you to sign up for that one. If you have any questions. Here again are my contact details. If you have any question right now, I’m more than happy to take them and miraculously enough, I finished in time. I hope you had a good time in this 30 minutes with a lot of information. I know I gave a lot, but I always want us to have more data, more information to make the best decisions ever and in this case, to have the tools to make our lives easier and our code more secure.

Speaker 1:
All right, great. Thank you Ixchel. And for the rest of you, we will send you the recording in about a day along with the slides so you’ll have all the great information she shared. So thank you for joining us today.