The majority of software supply chain attacks involve Java-based systems. However, the complexity of third-party libraries, which often make up 80-90% of applications, makes them hard to scan, review and analyze. This is where MergeBase’s Java Runtime Protection comes in as a unique capability in the industry.
MergeBase’s SCA Runtime Protection provides visibility into the Java libraries and methods an application uses, giving a proactive way to monitor, analyze and block potential vulnerabilities. This is especially crucial since the majority of the software supply chain industry only informs users about the existence of a vulnerability at a library level without noting the actual vulnerable function.
Learn more about Java Runtime Protection
In this webinar, Jim Manico, Julius Musseau, and Shannon James Smith will present how you can reduce 3rd-party risk proactively by hardening your applications from zero-day attacks.
- Use Java Runtime Monitor to identify all unused software in your apps.
- Block all unneeded Java libraries and functions from rogue execution.
- Don’t wait for a CVE tomorrow; break your attackers’ kill chains and reduce your exposure today with Dynamic Application Surveillance and Hardening (DASH) from Mergebase.
Ready to protect your applications against software supply chain attacks? Try for free or book a demo with one of our experts and learn more about this unique and proactive feature.
Video Transcription
Shannon James Smith: All right, everybody. Welcome. Good morning. Thank you for joining us today. My name’s Shannon Smith, and I’m joined here by Julius,co-founder at MergeBase, and Jim Manico, one of our advisors and CEO at Manicode, which does application and security training. Hey, Jim, how’s it going?
Jim Manico: Doing fantastic. How are you doing?
Shannon James Smith: Great. The amazing green screen you got going on there. It looks like you’re sitting in front of Mount Shasta or something.
Jim Manico: Yeah, so honestly, this is live. This is not a background. I’m here on vacation.
Shannon James Smith: Oh, we don’t believe you.
Jim Manico: I’m up in Mount Shasta. This is real. This is a real hot tub. This is not a background.
Shannon James Smith: You’re using that CGI stuff. That green screen’s incredible.
Jim Manico: That’s actually Mount Shasta right there. Black Butte. I’m up in Mount Shasta, but I figure I’m on vacation. I got a hot tub. But I can’t let a hot tub or vacation get in the way of informing the world about third-party library supply chain Runtime Protection. So I’m happy to be here with you, Shannon.
Shannon James Smith: Yeah, thanks so much for joining us. Really appreciate you taking time out of your vacation.
Jim Manico: Absolutely.
Shannon James Smith: This is going to be a nice, quick mini-session as we’re doing it and not taking too much of people’s time, so hopefully, you’ll enjoy yourself there and the view and the session. Okay, so today’s topic. Last time we talked just about Runtime Protection kind of in general, I did a little introduction. I’m going to go through the slide deck again today, just for a couple of minutes.
But our topic today is about application hardening, basically using runtime monitoring and protection for MergeBase in order to reduce your attack surface proactively, before you’re attacked and before there are CVEs, and harden your applications and lock down all the unneeded third-party components as needed.
Okay, so just real quick, in case you missed our first session, supply chain security is not going away. In fact, it’s under massive attack, and it’s been escalating. Prior to 2020, you hadn’t heard about it all that much, but about 2016, it started to come onto the radar, and then it spiked up pretty quickly. Since then, it spiked up much more quickly. Right? In 2021, we saw a 650% increase in software supply chain attacks.
Gartner predicts this will continue increasing by at least 100% a year for the next few years. The majority of CIOs and CISOs know that they’re vulnerable to these attacks and are looking for solutions. The primary solution nowadays is just software composition analysis, which is MergeBase’s core business and platform. But how did this problem come about, right? Well, the way it came about was 10-plus years ago, there were less than 50,000 libraries and repositories out there in GitHub.
Jim Manico: And Shannon, if I could add just real quick-
Shannon James Smith: Please.
Jim Manico: Why do people build third-party libraries in the first place? I think this is a really important question. The reason that people build third-party libraries is that there’s a really complicated problem in computer programming that they don’t want to have to keep rebuilding, so they build a third-party library.
The point I’m trying to make is, just to add to this slide, third-party libraries, by their nature, encapsulate complexity. So when we look at all these third-party libraries that we depend upon, they’re hard to scan.
They’re hard to review. They’re mammoth complicated, especially the frameworks like the spring and Struts and all that. So I think the complexity of libraries, this slide really illustrates some of the key problems. I just want to put it out there. The problems are even more than this. They’re hard to review. They’re hard to analyze. And they’re moving constantly and changing. And yet we depend on them on an epic level more than we should, I dare say. So this is really a big problem, Shannon.
Shannon James Smith: Yeah. And you can see the number, from 46,000 to 28 million. Right? We’re talking about a 61,000% increase in the last decade or so.
Jim Manico: Absolutely.
Shannon James Smith: Now you’ve got millions of libraries, hundreds of versions of each library, and multiple distribution paths. You got all kinds of problems in here, like poisoning. And I mean, the list of problems goes on and on.
Jim Manico: Absolutely.
Shannon James Smith: But the majority of the problems actually center around Java, which is why we released Java Runtime Protection first because they have more critical than all the others combined. I’ve heard a stat that 90% of data breaches start, in one way or another, with Java. You don’t have to tell Equifax about this. They had a Java Struts library that was popped, and they lost $5 billion in market cap in one day, and they never really recovered from that, from a valuation point of view.
Jim Manico: I think what’s interesting about Equifax, Shannon, is that Equifax didn’t even note the breach until many months later when they updated their data protection system. So they had this multi-million dollar data protection system that wasn’t updated, so it didn’t even see the exfiltration, but months later, some engineer updated the certainly, and then they saw it. So Equifax’s supply chain attack was blind to Equifax for months. That’s nuts.
Shannon James Smith: Yeah. Yeah. People realize, “Hey, I just bought this application,” or, “Hey, I’m building an application, and all the source code that we wrote, we’ve scanned, and it’s safe.” Well, it turns out the majority of your source code that you wrote is usually 10 to 20% of the app. The third-party or open-source components are usually 80 to 90% of your application. And those vulnerabilities in those third-party components are what we are focused on with software supply chain security.
Jim Manico: And Shannon, the SCA industry is horrible in letting you know if you actually have a problem. If the function that is vulnerable is something you’re actually using, most of the industry ignores that. They just say the library you’re using is a problem, not at the atomic level. So there’s a huge problem. There’s a huge amount of vulnerable code that we’re actually deploying live, and we don’t even really understand, even with some of the state-of-the-art competitors that we have, whether or not you’re vulnerable or not.
Shannon James Smith: And that’s a great point, Jim, because that really is what differentiates MergeBase from all the other SCA companies out there.
Jim Manico: Yes.
Shannon James Smith: MergeBase is the only company that gives you visibility into production and into ops with Dynamic Application Surveillance and Hardening. So we’re looking at what applications you’re running in production and telling you what libraries and methods they have that could be vulnerable. We’re giving you ways to monitor them and even block them in case of serious things like Log4j or Struts. And so, really, that’s what we’re talking about here today: a unique capability, Runtime Protection specifically for Java.
MergeBase has released this and is coming out with, as Julius will show us later, a one-click protection version of this, where people can literally just point it at an application, push a single button, and lock everything down that’s not being used proactively, which is really what today’s session is about, is talking about proactively hardening your stuff before there’s a known vulnerability, and blocking yourself from all the things you’re not using, and reducing your attack surface by 50 to maybe 80 or 90% even with the click of a button, at the end of the day, with Java Runtime Protection.
Julius Musseau: To be fair, I’ll be showing the earlier version of that. It’s not quite a one-click. It’s taking a few clicks. The one-click protection is under active development.
Shannon James Smith: Right. Yeah.
Julius Musseau: It’s coming.
Shannon James Smith: I always like to use the analogy; I just moved into the Biltmore Estate. Hey, I inherited this estate. It’s got 150 doors in it and a couple of hundred windows. And after my wife and I had been living there by ourselves for about six weeks, we realized we used six of those 150 doors, and we only used three windows. So hey, I got a novel idea. Why don’t we lock all the 144 doors we’re not using so that nobody can walk in randomly at any time of the day or night and violate our privacy. Right?
And so you think that’s such common sense, but we don’t do that with our applications. We pull in these third-party components. We use one or two functions in the library, and all the other functions in that library we leave access to. And they could have a zero-day on them, or they could have a CVE on them tomorrow, and they’re not protected. But why not lock them down if you’re not using them? That’s the basic premise of Java Runtime Protection.
Okay. Let’s talk about this in some more detail here. I’m going to go back to this intro screen here. So how long, Julius? First of all, I learned a new stat last week that I want to share with everyone, and this should’ve been on the first slide here. But when Log4j was announced on December 9th, over 200,000 attacks were launched, according to Check Point Research. Over 200,000 Log4j attacks were launched within the first 24 hours of the CVE being reported. And within a week, there were 1.2 million attacks. Some of those were actually coming from state-sponsored people like China, et cetera. And so the-
Jim Manico: And Shannon, one more real quick.
Shannon James Smith: Go ahead.
Jim Manico: There was active exploitation in early January, way before the release, because that’s how we discovered that Log4Shell was an active problem. We saw that on Weibo. This is the Chinese version of Twitter. We saw a lot of Chinese hackers actually talking about this exploit, and they began using it in an exponential fashion.
There’s a researcher, Free Wortley, who was on the series a couple of months ago, who was tracking Twitter, saw the check-ins at the actual Log4j project, where they were trying to fix it, and went live with it because it was under active exploitation.
So the only point I’m trying to make is that December 9th shows up, and we saw an increase of a couple of million attacks. There was already some nation-state-level attack going on before that. So even before we know it, the zero-day is out there. So think about that one for a second.
Shannon James Smith: Yeah, yeah. Our last session was on patching, how it takes time to deploy it, and everything else. But I mean, let’s be realistic. Who can patch within 24 hours unless you are the software developer? And even if you do patch within 24 hours, you still have to deploy it, and you have to test it, all this stuff. Right?
Jim Manico: What about DevOps? The DevOps world tells me, “Oh, Shannon, I got DevOps. I can just push stuff live quickly, and I don’t need Java Runtime Protection.” What do you think about that? I’ve heard that from a few DevOpsians.
Shannon James Smith: They can push it, but it’s not QA yet. It’s not out on all their servers and all their clouds, and it’s not scaled out yet. And it could break something if they pushed it too fast.
Jim Manico: High five.
Julius Musseau: And then the library itself that’s under attack might not have been patched, so you might not have any library to upgrade to.
Shannon James Smith: Right.
Jim Manico: Absolutely.
Shannon James Smith: There’s that, too. Yeah. So, last session, we talked about how patching can take time. Sometimes people never release patches for certain deprecated software. And Java Runtime Protection’s great for helping close that window faster. But in the case of major things like Log4j or Struts, when those things get announced… I’ve now learned since our last session that hundreds of thousands of attacks can happen in the first 24 hours and millions of attacks within the first week.
I mean, patching is just not a realistic way to reduce your risk in those scenarios. Whereas Runtime Protection not only can help you literally close that window in minutes. Once you know about it, it can actually help you close that window before you know about it.
And that’s what we’re really talking about today, is basically looking at your application, monitoring your application, monitoring how your application uses all the software libraries that you’ve brought into it and all the methods within those software libraries. And the ones that are never used, just use Runtime Protection to block them. If a zero-day pops up tomorrow, you’re not vulnerable to that because you’ve already reduced your attack surface, and then you can’t be attacked there anymore.
Jim Manico: I also like the idea that Java Runtime Protection that I can enable immediately buys me time to analyze the library, to do the actual update, to slowly do QA, and to be more judicious about when I do release because I probably want to update the library. I want to replace it or something. But I like Runtime Protection because, boom, within a minute, I got this dealt with. And now, I can take my time to deal with it in a more robust fashion and stop myself from being attacked by these problems.
Shannon James Smith: Yeah. I mean, instead of weeks or months, your vulnerability window is now minutes or a day or two at the most. Right?
Jim Manico: And I think that’s important because what’s important is not so much how many vulnerabilities you have. That’s just going to happen. I think what’s important is your ability to reduce the exposure window. That’s a much better way of measuring risk. You can’t really measure risk statically, in my opinion. I need to see how the application lives over the course of many months.
If we both have a hundred vulnerabilities in our app, Shannon, you and I both do, and my vulnerabilities last for months, and your vulnerabilities are getting runtime protected in real-time, even though we have the same vulnerability count over time, the actual risk of your organization is radically less than mine, even though we have the same vulnerability count. So that vulnerability counts in a static point of time, that’s not a good way to measure risk, and it never was.
Shannon James Smith: That’s a very good point. If I’m driving a hundred miles an hour down the road on a little square thing in a back road for 10 minutes, and then I stop, that’s not very risky. If I’m driving 100 miles an hour all the time, I’m through town, and then it starts getting really risky. Right?
Jim Manico: Do you actually drive 100 miles an hour? Are you one of those speed demons?
Shannon James Smith: No, no, no. Those were my younger years.
Jim Manico: My girlfriend, she calls me… Whenever I’m driving fast, she’s like, “Hey, Mario, why don’t you slow down a little bit?” That’s my speedy name is Mario.
Shannon James Smith: Well, speaking of driving fast, let’s let Julius take us through a quick drive-through of Runtime Protection, show this interface, show how easy it is to look at what you’re running, and click the Block button, basically.
Jim Manico: Julius, how are you doing, buddy? How are you doing, Julius? I miss you.
Julius Musseau: Oh, I am doing well and doing well. Yeah. So, here I’ll show off the attack surface reduction. Right? So what we’ve done here, I mean, these are all our SCA scans. But here, at the very top, we have Runtime Protection as well. So one of our systems here has the Runtime applied. And this system it’s preseeded with very horrible, vulnerable libraries. But one thing that’s interesting about it is this system has been operating and running and doing its thing for the last few days, a few weeks here.
And Runtime Protection is carefully keeping track of all the usages of these libraries. I can just sort by that. Right? You can see that the Tomcat Library is very important to this system’s operation. Quickly scroll down. There’s sort of this long tail that happens. So a lot of these libraries, they’re hanging out. They’re just getting called a little bit. Right?
Some of them haven’t even been called at all since the application was started up. So that these libraries here, all these zeros, these seem to be part of the start-up routine, but they’re not really used at all after the application is up and running. So I think of these libraries, all these zeros as… because-
Jim Manico: Go up. Go up for a second.
Julius Musseau: … what we’re measuring here is-
Jim Manico: Look at like Tomcat FileUploader. Right? Oh, talk about-
Julius Musseau: Yeah.
Jim Manico: Talk about a scary piece of code.
Julius Musseau: Yeah.
Jim Manico: You’re actually doing a multi-part form upload being received on the server. That’s not going to pick up, but the file upload library gets attached to other frameworks. So it’s-
Julius Musseau: that’s true.
Jim Manico:
It’s all over the place. Every framework in the Java ecosystem uses it.
Shannon James Smith: And it looks like there’s a 9.8 in there. Right? So if that’s not being used, are we able just to block that?
Julius Musseau: Yeah, yeah, yeah, sure. I can just hit that and hit Block.
Jim Manico: Sorry, buddy.
Julius Musseau: Oh, no, no. We need this.
Jim Manico: That was two clicks.
Julius Musseau: Yeah, yeah, it was two clicks. Yeah. Well, we’re working on the one-click.
Jim Manico: I’m okay with two clicks. I like two clicks.
Julius Musseau: But I just wanted to make a point here. I think of systems as having a lot of, almost like, the space shuttle, you know how it’s got those engines, all those engines that get it up into orbit? Right? When you’re launching your system, a lot of libraries are used to get your system up into its running state, but then a minute, two minutes later, these libraries are never used again. Right?
So you can block them, turn them off, shrink your attack surface, and shrink the amount of libraries present in your system. And then, when I really go to the bottom here, now you see these libraries here, these are the unloaded ones. They’re not even used during start-up. They’re there in the classpath. They’re present, but we don’t… Why do we-
Shannon James Smith: That’s all attack surface that is totally unneeded.
Julius Musseau: Yeah. It’s totally useless. Yeah.
Shannon James Smith: If a zero-day 10 came out on one of these tomorrow, they could come in through there, even though you’re not using it actively. Right?
Julius Musseau: Yeah. I mean, that’s a common misconception in the industry too. They’re like, “Oh, the library is not being used, so I’m not vulnerable.” A lot of people seem to think that. And-
Shannon James Smith: Okay. So right now, you just block all those unloaded libraries that you checked. Right?
Julius Musseau: Yeah. That’s right.
Shannon James Smith: But basically, the new one-click, code name One-Click protection feature that’s coming out, would do this for you automatically. Right?
Julius Musseau: Yeah, yeah, yeah. You just click-
Shannon James Smith: Literally, you’ll have just a wizard where you can just say…
Julius Musseau: Yeah.
Shannon James Smith: … “Anything that’s not being used, I want to block it.”
Julius Musseau: You just click up here, yeah. And then it all-
Jim Manico: Julius, what’s-
Julius Musseau: Go on.
Jim Manico: What’s really interesting about this, I think, is that there’s a company called Castor, one of the original Java shops on the planet. Right? They built a little free tool that lets me point at a Java app and looks at any third-party libraries I’m not using.
A couple of years ago, I used this in several of my projects, and it was insane the number of Java libraries that I have set up that I just flat-out don’t use. And look at all the attacks recently from Log4j, Struts, and Spring and similar. They’re often dynamic reflection-based vulnerabilities that let me call other classes in the classpath.
Julius Musseau: Exactly.
Jim Manico: So put this all together, and I have all these junk classes I’m not using in the classpath, and there’s some kind of reflection vulnerability. Now those libraries that I don’t need for any reason can be used for exploitation. This is really a problem in the Java ecosystem, Julius.
Julius Musseau: Yeah. Yeah. And, I mean, in all the ecosystems, actually. Software engineers oversubscribe to their dependencies because they believe there’s no harm in that. “Oh, let’s just bring down everything that everything needs.”
Shannon James Smith: “I might need it later. I might need it later.”
Julius Musseau: Yeah. Maybe.
Shannon James Smith: But the hacker’s thinking the same thing. “I might need it now.”
Julius Musseau: Yeah, yeah, exactly.
Jim Manico: This is what started in the ’90s. I remember doing Java, like Java 1.0.2 in ’98, using 53rd-party libraries, which is that early in the Java ecosystem. This is how we were taught to develop.
Shannon James Smith: Yeah. Yeah. No, it’s great to have everything with you, right, until you want to start finding an attack path. Now you got so many more vectors to come in with; it’s just a matter of time before you find one. So you got to reduce that attack surface, and that’s what Runtime Protection does for you.
Guys, we’re at 20 minutes here. This has been really helpful and useful. I think we showed off how you could be proactive and how easy. You can do it from your hot tub. I mean, it’s not a hard thing to do. But God, it can make the difference between $5 million in market cap shaved off in the next 24 hours. This is a big thing, and we’re excited for people to be able to start trying this out and using it. So thank you, guys, for your time. And we’ll now do some questions from the audience. Yeah.
Julius Musseau: We’re here to continue the conversation. Go ahead, Shannon.
Shannon James Smith: Yeah. Oh, you already upgraded everybody. Great. Thank you, guys, for all attending. Yeah, we were going to try to play it off by wearing the same clothes, but Julius just ruined the surprise. No, I’m just kidding. Yeah. It’s wonderful to have you guys, especially the return visitors, today. Thank you for coming. Yeah. Jim may join us for Q&A if he can break out of his training session. But yeah, that’s why we had to record it because he was busy this morning.
Yeah, so do we have any questions right now? You can chat questions or Q&A questions, or you can just take your mute off and ask questions if you have any questions about Runtime Protection, hardening your application, protecting it against zero days, what this means, and why it’s important. No stupid questions. So feel free to ask them.
Al White: Shannon, it’s Al.
Shannon James Smith: Hey, Al.
Al White: How are you, man?
Shannon James Smith: Good. Good to see you.
Al White: And you as well. Quick question, besides the fact that I’d really like a hot tub to ask it from. How easy is it for customers to do a proof of concept on this?
Shannon James Smith: Yeah. Like we showed you today, I mean, most of the features and functions that you’re using here are something you can literally do in minutes or hours. Right?
Al White: Right.
Shannon James Smith: So it depends on how wide the scope of the POC is going to be. I mean, if they want to use it in development for SCA, if they want to use it for SBOM, if they want to use it for Runtime Protection, it’s all one platform. So it installs pretty easily and fast.
To start integrating it into your SDLC and things like that, of course, that’s going to take a little bit more effort to get it smoothly integrated and make sure, whether you’re using GitHub or GitLab, and your repositories are LinkedIn. We’ve tried to make it really easy to integrate this thing in so it just becomes a seamless part of the whole process, with Runtime Protection being the final result, looking into the ops side of the cycle.
Julius Musseau: The Runtime Protection, specifically, is currently only available on Java or Java bytecode-based platforms. So Gradle, Java. What are some of those other Java-based languages? Kotlin. There are a few others. So there is that limitation as well, Al.
Al White: Okay. No, that’s good to know. It’s just, obviously, nice to be able to offer it to potential customers and know what it’s going to be. It’s not going to take weeks for it to happen.
Shannon James Smith: No, no. Yeah, our normal, standard kind of POC timeline, just for people, is like two weeks because they usually can get a pretty good handle on it within that time frame. For more extensive POCs or larger customers, we’re happy to extend that if needed. But yeah, within two weeks, normally, people can get a pretty good handle on how this is going to work and the benefits. It’s not a huge time commitment from them, basically.
Al White: Great. Thank you.
Shannon James Smith: Yeah. Okay. Yeah. Any other questions from the audience today? We got another five minutes here.
Julius Musseau: I’m just sharing the Runtime Protection, the system that we have applied the Runtime Protection to here, just on our dashboard here, so you can… Still trucking along.
Shannon James Smith: Yeah. So, just to clarify, the normal procedure for Runtime Protection is you normally start with runtime monitoring, and that way, you can see the usage stats of every library. And then, you can go into the individual libraries and look at the usage of the individual methods, and you can see if a method or a library’s being used or not or how often it’s being used.
And then, once you’ve determined like, “Oh, this is dangerous, and nobody’s using it, and we’ve been watching now for a few days or a few weeks,” you can feel comfortable going ahead and blocking it. And so it’s basically a manual process at this point. I mean, it’s a fairly easy manual. I mean, it’s got a nice, easy-to-use interface. Even I could do this.
But we’re also building a feature that will kind of do that analysis and that blocking automatically for you, which will be out in a few months. We call it One-Click Protect at the moment. But that’ll give people the ability to, basically, use a wizard to do this and kind of speed the whole process up and just kind of point one-click protect at an application, give it the amount of time you want it to monitor it, see what’s being used and what’s not being used, and then to implement the blocking on anything that’s not being used or anything that’s very dangerous.
And the fallback position is, if you’re using something that is dangerous, I mean, obviously, eventually you want to patch that and update it. However, you can still turn runtime monitoring on, leave that on, and then set alerts. So if you have an IR team or an MSSP that you’re working with or a SOC that’s running 24-7 for your company, you can link that runtime monitoring into that process. Right?
And so if somebody uses that method or that library that’s vulnerable, you could look at the usage, and who’s using it and how they’re using it, and have a better idea of whether or not that might have been a dangerous or an attack. Is that an accurate description, Julius?
Julius Musseau: Oh, yeah, absolutely. Yeah. Yeah. Here I’ve just got the Log4j one. It’s just that one little method A, the JNDI lookup. And what’s nice about it, right, is that the vast majority of systems would never use that. Only crazy people would ever use that in the normal course of their systems. Right? So if this JNDI lookup starts triggering, that’s a bad sign. And the Log4j team; they ripped it completely out. This method does not exist anymore in Log4j. I mean, that gives you a sense of how important it is.
Shannon James Smith: Oh, wow. I didn’t know that. That’s a great story. Yeah. I mean, the real point is, like Jim said… I think that was a great point… back in the early days of Java, why not include every library available? Back then, there were maybe a thousand or a hundred libraries, and you saw the stat that I showed from 2009. There were 46,000 repositories on GitHub, and now there are 28 million. I mean, obviously, nowadays, you’re not going to include everything.
Otherwise, you’d need to ship disks. Right? But people still, just by the nature of the old way of thinking 20-plus years ago, when application security was not really even a term yet, people just included everything for the convenience of it.
Julius Musseau: Oh, and they still do. They still do. I don’t see a lot of careful shrinking and curation of what libraries you include in your systems, myself. I see a lot of developers; they’re just focused on, “Let’s get this working. Let’s achieve the use cases that we’ve committed to. Let’s get these points, our Agile sprint points, done on our two-week sprints. Right? They really just want to get things working. They don’t want to keep things really neat and clean, and minimal.
Shannon James Smith: I mean, you kind of think of it like you’re racing a car. If you’re taking a road trip, you want to bring everything you can with you, so you have-
Julius Musseau: Just in case, right? Yeah.
Shannon James Smith: You’re taking your car anyways. Might as well use the space. But if you’re racing around a track in circles all day, you don’t want all that extra weight in your race car, right, because it’s just going to slow you down. And performance and security are very tightly woven. And when you actually ship an application in production, you really don’t want to send anything in there that isn’t needed to get the job done. Right?
And that’s the same thing from an attack surface point of view. That was an incredible demo you showed, all those unloaded libraries that were never, ever even used, and it’s just gobs and gobs of attack surface. As an application security hacker, I mean, they must just drool when they come upon an application that’s just got like 50 unused libraries waiting for them to find the next zero-day.
Julius Musseau: Yeah, we did, actually. We did a peer-reviewed, reproducible study on that. How many libraries are there in systems, and what percentage is coming from the core team? Yeah. Maybe I’ll-
Shannon James Smith: I’m curious. What would your guess be, just given that you’ve been in this for over five years now, deep?
Julius Musseau: Yeah, my guess was-
Shannon James Smith: What would your guess be? Of any normal application that’s shipped, how many of the methods in all the libraries are actually used? What percentage? Would you say 10% or 20%?
Julius Musseau: Well, you’re asking me, right? And so my-
Shannon James Smith:what would you guess be?
Julius Musseau: My guess would be less than .1%.
Shannon James Smith: Now. No, my guess would’ve been, as a safe marketing claim, “Reduce your attack surface by over 50%.” But you’re saying-
Julius Musseau: Oh, no. 99.
Shannon James Smith: … over 90%.
Julius Musseau: Over 99. Over 99%.
Shannon James Smith: Over 99%, you can reduce your attack surface with Java Runtime Protection. Wow. Okay. So we got to do some more research on this. But we are at the bottom of the hour here. Thank you, guys, so much. We can stay a few minutes extra if there are any final questions that popped in into anybody’s head.
Julius Musseau: But we won’t be hurt if anyone leaves early or not early.
Shannon James Smith: Yeah. But no. Yeah.
Julius Musseau: At the actual time.
Shannon James Smith: Unless someone’s speaking up, I’m going to call it right here at 10:30 and respect everyone’s time. And hope you join us in two weeks. We’re going to be doing the Web Application Firewall or WAF, WAF versus Runtime Protection. And I’ve been doing a little research on WAFs lately, and I didn’t realize they had caught on so much.
There are tens of thousands of people out there that are WAF engineers because Web Application Firewalls are so complex, and you really need to babysit them. And Runtime Protection’s pretty simple, as you can see. So it should be an interesting session. I hope to see you guys again in two weeks.
Julius Musseau: Yeah, thanks for coming.
Al White: Thanks so much, guys.
Shannon James Smith: Thank you, Al. Thanks, Julius. All right. Take care.
