How Empires Fall: Recklessness, Defenselessness and Trojan Horses, JFrog, Risk-Based Security

A lawyer at a DevOps event? But of course! In this video, we’ll review the less obvious aspects of DevSecOps and continuous security – continuous and cautious license compliance, universal and recursive scanning, and “quality over quality” security intelligence. Learn more about how JFrog Artifactory and Xray can help you integrate security and compliance into your DevOps pipeline, by watching this key session from swampUP 2019.


> Learn More About swampUP 2020 <


All right. Welcome everybody. Here’s the name that takes your imagination to ancient empires like ancient Rome and ancient Greece, and you expect to see pictures of, maybe, Trojan wars, and I don’t know what else. It will have nothing of that. The title is a complete lie. Instead, we will do something very practical and, hopefully, very useful, and we’re going to talk about three different aspects of DevSecOps, which not be trivial for the average Joe software engineer that heard something about DevSecOps, knows the importance of security, but maybe not have to think about interesting twists that might present a very big problem to the point of empire failures and very big companies finding themselves in very deep shit because they didn’t pay attention. It’ll be very embarrassing if all of you already thought about everything that we are going to talk about. That will be obvious, if that’s the case, very, very soon, because I will ask you number of questions.

Questions from your lawyer that I’m sure you see every day, in your corporate environment and questions might be, for example, “Who is not paying attention to licenses?” Who knows not paying attention to licenses is trouble? Who knows that if you don’t pay attention to open source licenses, your company will be in trouble? Everybody knows that. Perfect. Great. Thank you very much.

Who has an open licenses leased, which is distributed with their software every release? You said you know it’s important. What’s up? Okay, you are in the right place. Awesome. Good. Okay. Let’s say some day, someone will ask you for this lease that you don’t have. Do you know how to start going about? Who knows how to collect open source licenses in their product? Okay. Okay, you just don’t do it because, who cares? This is how empires fail. I have to remind you.

Okay, who actually continues governance of open source licenses in their organization? JFrog people, which makes me and our lawyer very happy, but apparently no one else. You are in the right place. I don’t how frequently you have those conversations with your lawyer, based on your answers, not very frequent. We have this conversation with our lawyer now. So, let me introduce you to [inaudible 00:03:19] Eyal Ben David, JFrog General Counsel. He is a real lawyer, and-

Hey, everyone.

Okay, bonus question. How many people saw a lawyer in staging a software conference?

In a t-shirt.

In a t-shirt. Hands down. No one ever saw a lawyer in a t-shirt. So, Eyal, thank you for joining us, and thank you for the opportunity to provide this view of a lawyer for us software engineers, and tell us what you care about when it comes to open source governance in the swampUP or any technical conference.

Happy to do it, and Hi, everyone, but, [Baruch 00:06:25], I thought we were going to start with a lawyer joke. You skipped that.

Yeah, where did you find [crosstalk 00:04:06]-

Where’s the lawyer joke?

Where did I find my lawyer? Obviously-



I’m glad we discovered-

In the bottom of the sea. [inaudible 00:04:15]

For sure. All right, so, hello, everyone. My name’s Eyal. I’m GC at JFrog. I promise it’s 5:00 on a Tue-

GC stands for garbage collector.

There you go. There it is. You came up with that, just now. Nice. I know it’s 5:00 on a Tuesday, and I promise not to dive into any deep legal concepts, but we are going to talk a little bit about software licensing, specifically open source software.

Yeah, absolutely.

A little bit about my world, of where legal meets tech, meets business, and how that intersection is relevant to this, when empires fall. To follow up on Baruch’s questions, how many of you work for a company or corporation that has a policy defining what open source you can use, what you can’t use in creating your proprietary software?

So, we know you don’t update it. How many of you are aware that it exists?

Nice. All right, about half. My follow-up question is, how many of you have opened that policy in the past month? There we go. All right. So, a little view into my world and we were thinking about what would be interesting, and there’s 90 different examples that we can give of where it becomes relevant and why it’s relevant, but we wanted to talk about M&A. M&A transactions something that we like to read about-

People know what M&A is?

Oh, I’m sorry, mergers and acquisitions. I think they all do. Yes. I see everyone’s nodding. All right. When we, at JFrog are in general when companies look at a target for an M&A for an acquisition or a merger, one of the first things we’re going to look at, and that’s far as that list of open source components, the thing that Baruch mentioned before, that we weren’t sure that everyone has. The reason we’re going to look at is mainly IP ownership. The main thing we want to determine is, is this company that we want to buy? Is this software that we want to acquire? Do they own it? Now, the question of owners isn’t always a yes or no question. We want to see if there’s any third parties that may have any claims on that IP, if anyone’s going to come back and ask for royalties, if anyone’s going to have any questions regarding that ownership if we buy it later, and are we going to be able to make money off that software, moving forward, or do with it as we wish?

What is the problem? Okay, so I have an [inaudible 00:06:20] star top, and mighty JFrog want to buy my company. What can go wrong?

Well, let’s talk about some examples, Baruch. Let’s talk about some examples of when that can come into play, when our IP ownership couldn’t be relevant. Let’s think of some examples from the press that we saw in the past few weeks.

Yeah, you know [inaudible 00:06:36], I think actually… At JFrog, we had this experience, when some transaction actually failed on IP ownership.

We did, and we looked at different transactions over the years. We’ve looked at different companies, and it’s not the one thing that you’ll say yes or no to a transaction for, but it’s something material that you look at. We’ll look at that IP ownership, see if there’s any copyleft licenses, and the ownership-

What are copyleft licenses?

Ah. What are copyleft licenses? Let’s ask around. Are everyone familiar with the term copyleft licenses? Really, in a nutshell, a copyleft license is a license similar to the GPL. It could be a reciprocal license, meaning if we use it inside a proprietary code, we may have to share that code back to the world. Although, we may have share it back-

What we call a viral license.

A viral license. Exactly.

So, if we use a GPL, we are essentially GPL, regardless what we want to think of ourselves.

In certain situations, and let’s talk about that. Let’s talk about the LGPL.

Oh, LGPL. LGPL. Who heard about LGPL? Who knows the difference about GPL and LGPL? Perfect. No one knows. Yeah, [Evan 00:07:41] knows. What’s an L-

Evan knows the difference. Nice.

LGPL is a license, which was supposed to make GPL less viral, and it’s like many years ago, they made this difference between static binding and dynamic binding for languages like C++, and they say if you statically bind, if you compile our source with your source, your code is not open source. That’s the viral part. But the L, lesser, comes to say, “But if you only do the binding dynamically in the run time, then, it’s not a big deal. Then, you don’t have to open the source for us.”

So, Baruch, can I use LGPL on my proprietary software?

That’s a great question because this is exciting how the technology changes the meaning of a legal document. LGPL was written with terms that make sense for a certain technological [inaudible 00:08:42]. Then came Java. In Java, do we have static binding in Java? Everything’s dynamically binding, and certainly, LGPL is a completely safe license. There is no static binding. There is no viral. Let’s all use LGPL. But, then [inaudible 00:09:02] came. How do [inaudible 00:09:04] in [inaudible 00:09:04] work? It’s all static. We’re always compiled together. So, suddenly the same LGPL who looked absolutely safe for us Java people, now, is absolutely open source viral. It’s like it’s changed it’s meaning 190% because we use a different programming language. That’s super cool and, obviously, super scary.

The one thing we would suggest is that policy that we discussed is not something we can write, throw in the drawer, and not look at, ever. It’s something that has to be dynamic and has to evolve along with the technology, and something we should properly revisit, study, and teach on an ongoing basis.

So, you should see your lawyer more.

You should see your lawyer more. There you go. Let’s talk about some other examples, Baruch. Another question for the crowd. If there’s a project or library on GitHub with no license… This may be an easy question. I’ve asked about 20 people in the past few days, and I got a wide variety of answers. Can I take that library and use it in my proprietary software? Who says yes.

Technically, you can.

You technically can. True.

Are you allowed to?

Are you allowed to? Good. I see the answer is pretty commonly, “No,” and it’s obviously clear that if we take that without a license, we’re using someone else’s copyright work, which we, then, will have that IP ownership question that we discussed earlier.

And people do that quite as much… quite as much. People do it all the time.


The real question is, [inaudible 00:10:31], it’s… Think about yourself. You found a library on GitHub. Will you check the license? Who will check the license? No one will check the license, so, yeah, please stop doing-

We see a few. We see a few, and they’re mostly for JFrog.

Yeah, yeah, yeah. Well, that’s some of our old JFrog people. You’ve trained them well. You know a ridiculous example. A code that someone put the [inaudible 00:10:56] background on their LinkedIn header. You know, in LinkedIn, you have your header, which is like a white picture? Someone took some kind of code, put them there just for illustration. Next thing you know, it’s in someone else’s product.

If you guys read the papers today, that was one of the items.

So stop treating code as, it’s not important who it belongs to, because it is important.

Let’s talk about another fun example, a log you wrote couple years ago, or maybe a little less, but a couple years, a company named Lerna, a product named Lerna-

Yeah, it’s a [inaudible 00:11:30] project and was like a year ago. Yeah. Who heard about the Lerna incident? Oh, you didn’t.

Evan, again. His number one student.

You are here for a treat. It’s one of the best stories I ever learned about licenses.


Go ahead.

Agreed, agreed. Learna, an open source project, distributed under MIT a couple of years ago, for reasons, which, political reasons that we definitely don’t want to get into if they’re right or wrong. Released a version with an MIT license, calling out with a tailored MIT license, calling out certain enterprises by name, in a certain corporations that they were not allowed to use that license or that library within their software. Now, if you can do this, if you can’t do this, if it’s legal or illegal, if it applies or not, that’s a question for later, and we’re happy to discuss.

For today, the point that we wanted to make is we, as a company, we want to know that this license has changed. We want, at least, to have the conversation as Baruch says. You want to go talk to your lawyer and make an education decision on if you want to keep on using that library in your software. It may or may not harm you, later down the line.

Now, there is [inaudible 00:12:33]. Not only they changed this license. They did their best to do it in the most sneaky way. How many of you are familiar with [SemVer 00:12:43], Semantic versioning? Oh, majority of you. You know how semantic versioning works, so a major version breaks. Right? You expect a license change that will disallow usage of your library for some companies, will be a major version, because we want, if we use, now, a certain version, Version X, before we update to Y, this is a conscious decision. We see what changes. We check the release notes. One of the items in the release notes is license change. You cannot use it anymore, and we were like, “Fine, we will stay on Version X or we will use it as a [inaudible 00:13:25] tool, maybe for, whatever.”

Now, what about the patch version? Most of the [inaudible 00:13:34] managers will download a patch version without asking you. It will be automatically updated. If they manage to change the license in the patch version, all those companies that were called out as not allowed to use this software, will be in breach of license without anyone in the company knowing that that happened. I have goosebumps [inaudible 00:14:04], today, when I think about it, because this is how you take a huge corporation, starting with M and ending with icrosoft, down. This is how you do it. It was evil genius, but, think about it. You can be in this place, any day.

Baruch, that example’s good with two MIT licenses. What would’ve happened if they switched from MIT to GPL? Then, it could be even more detrimental. Exactly the point, exactly the point. I think what we’re getting at, and I think that the point is that we have two main key, core advices that we want to give, or two key practices that we need to follow. First thing is we need a policy. We need a policy that we learn, we study, we practice, we visit every day, hopefully. The second is actually to use that policy and make our users aware of what open source components and libraries we have in our software.

It should be continuous, though. License government should be continuous as your continuous integration, continuous delivery, continuous security. Continuous license government is a part of that. The customer, or the stakeholder, that dictates how this government’s [inaudible 00:15:20], is right here. This is your lawyer. This is your counsel that you will ask, “Okay, Eyal, tell me what I’m allowed to use or not allowed to use, and I will bake it into my pipeline and make sure that we are not in breach from the rules that you tell us which are right and wrong.” Those rules are completely dynamic from company to company. One day, I might wake up in the morning and say, “You know what? We will never use any licenses from our competitors because there is some danger that they will try to fuck us over.” Sorry, I didn’t mean to say that.

Not sure I’d say that. Yeah.

Yeah, that was… No. Then, let’s not use any of those. We need, on the same day, come to work, impose those rules and make sure this will never happen again. So, let’s do an [MO 00:16:15]-

Let’s do it.

… and you will tell me what I need, and I will do that.

Let’s do it.

All right. This is my… Okay, there is a tool for that, that you don’t see, but you will, in a second, and it’s called… Anyone know? [Brian 00:16:31] knows, but he wasn’t in that rehearsal, so it doesn’t count. JFrog Xray. Surprised?

Whoo. Ooo.

Yeah. So, you might have heard about JFrog Xray as a security analysis tool, and we are going to talk about this aspect of Xray in a second, but it also has the same principles of continuous security, as continuous license governs. You can set up a policy, which is usually, or by default, you might consider a security policy, but also you might set up a license policy. So that will be… License compliance is a good name for a license compliance policy, I think. The way it works is I want it to be a type of a license, and I want to find the rules that Eyal will define for me, and he will say, “Blacklist,” or license blacklist, or something. That’s my rule. That’s what we want to say, and we want [inaudible 00:17:44] licenses. Again, Eyal gave me the list, and one of the lists is, let’s say, “Don’t use C…” What was the name? CPAL. What was the name? Forget the licensing [inaudible 00:18:02]. Great.


No, C something. Oh, my God. Sorry about that. I blacked out for a second. I know where to check, in [inaudible 00:18:14] or in Xray. I didn’t check in Xray. So, discard. I will do it once again in a sec, and J Unit. It’s a license that J Unit carries, and J Unit… I don’t ant to use J Unit in production, obviously. One of those can be don’t use simple one. Here you go. I want to ban this license because I don’t want to use in production, licenses from tests.

So I will create a new policy. Now you remember it very good because I did it twice, and that will be license, and we’ll define a rule, and that will be band licenses, and we will do ban licenses, and that will be CPOL. Here we go, CPOL. This guy… Oh, and also, I don’t want any unknown licenses because I don’t know if they are good or not. I will prefer to stay away until I get clearance from a [inaudible 00:19:24]. Okay, so this is good. Now… I didn’t do anything. Now, I can set up… Not discard, save. Ah, sorry. Long day. Now, I can define watch, and I can say, “I want to watch… Name for a watch. What’s a good name for a watch? Nightwatch. Well, not so good. We don’t have Nightwatch anymore, so let’s do license watch, because night watch is not a thing any more. What we want to is we want to watch all the builds that go through the [inaudible 00:20:08] continuous license compliance. Every build, I want watch, and now, Old Bills, and now I want to attach the policy, which will be my band licenses policy. The internet is a little bit slow, but not horribly slow. License compliance. That’s my thing.

All right. Now, I’m done, and let’s try to build something that has J Unit as a dependency. So, that’s my Jenkins, and it has its build, and I’m going to say, “I want Xray scan and I want my build to fail. Now, in 22 seconds, more or less, we will see how the build fails. I started it, and that’s the blog, so it builds, obviously. That’s what takes the longest Now, download some stuff, downloads the internet, obviously from [inaudible 00:21:20] factories. Boom. It failed. It failed. Yeah, that’s a good failing demo. [Shlomi 00:21:26], thank you. It actually failed because I didn’t configure something right, but, in a really failing demo, that will fail on security [inaudible 00:21:38]. That’s a meta failing demo. I managed to fail a demo that was supposed to fail.

Supposed to fail.

Yeah, no, but I apologize. It was a long day. I won’t rerun it again, but I think you got the gist how we do… it’s supposed to work. This is it, and this is how you bake your license compliance into your continuous [inaudible 00:22:03]. With that, let’s talk about something else. That was the compliance part that, apparently, you didn’t think about, so you are going to start think about now.

Continuous security, on the other hand, this is something, which is constantly undermined. You are sitting in the depths of [inaudible 00:22:24], that means you are security conscious people. You know that security is important. Right? Okay. Who uses Docker? Everybody use Docker. Great. Who scans Docker with security tool? Okay. This is disturbing. I would still expect everybody to do that but, apparently, you are in the right place. When you pick a security tool, everybody have this checkbox, we do security image [inaudible 00:23:02]. What does it mean, and whether it will find a vulnerability inside proprietary application binary, on any of the layer deep of your Docker image, this is something that you won’t find on those shiny bootlegs that you get in conference for your next security [inaudible 00:23:30] scanning tool. To tell you a little bit about why it is important, I want to invite the person who was there during the arm work to support 24 different package types in [inaudible 00:23:46] factory, and he was there through the entire… all of the 24. Yossi Shaul, Senior Architect at the CTD Office at JFrog.

Thank you. Thank you, Baruch. Before we start, let me explain what does it mean scanning a Docker image? Darker image is usually built upon some kind of Lenox distribution, and those distributions bundle usually with several components, sometimes a lot of different components. When we are talking about scanning a Docker image, basically, it boils down to opening the various layers inside the Docker image, fetching the list of installed OS level components, like the LPM files, WM files, and comparing it, against the vulnerabilities database. That’s what it means and, as Baruch mentioned earlier, a lot of companies knows how to do. We also know how to do it. Is it an important thing to do? What do you think? It is.

It will actually catch the next [inaudible 00:24:59]. Right?


[inaudible 00:25:02], if you remember, that’s what it wants. It was a system level binary inside your Docker image.

Yeah. It is an important step to do. Everyone who uses Docker image should do it. No wonder that all of the companies around scanning Docker images popped out in the last couple of years, and everybody’s trying to provide this kind of service.

I have a question for you, Yossi. What you actually did, you went through the operating system in Docker, took every binary that’s installed there, got [inaudible 00:25:44] check some ID in some way, went to an external database, compared if it’s there, and reported if it’s safe or not.


All right. I have my own application, which I added to my Docker image. Obviously, the checks [inaudible 00:25:59] of my own application won’t appear in any of public databases, at least, I hope so, because no one knows about it. It’s my application. It does something very unique to me, and no one else in the world knows it. So how this tool will help?

It won’t. It won’t help in this case. You mentioned tablet, for instance, how it was a vulnerability in open [inaudible 00:26:22]. So a library that it is installed in mostly every Lenox exhibition, and a scanning of Docker image will find it.


But, let’s take, for example, another famous or infamous data breach, Equifax. Anyone heard about it? Very famous one, but it’s not unique. It was famous because it was huge company that almost everyone knows about, and it was a shame that it happened, but this guy-

Yeah, yeah. You’re in Israel, but we got the blow.

This kind of vulnerability is a vulnerability inside a proprietary application that is packaged in a specific packaging. In this case, it was probably a job application. It’s probably a raw file. A simple scanning of a Docker image will not find this vulnerability. In order to find vulnerabilities of third-party components, whether in the Java world or Nougat or [inaudible 00:27:26], or NPM, plenty other technologies that you have, you need to do something else. This something else is what we do in Xray. It’s a deep analysis and deep scanning of all the components that we can find inside a Docker image or any other technology, for that matter. What we basically do, we take the Docker image. We scan for the basic [inaudible 00:27:52] level vulnerabilities, like everyone else does. We have our own extensive database. We compare and then we move on to the next stage.

The next stage is scanning everything on the file system and trying to find out whether it’s a component that we identify, and if it is, we match it against our own database, and we also do another thing. We also perform a deep scanning. In a lot of cases, I said, I mentioned it’s a proprietary application. We support multiple languages. It means that it might be a ZIP. It might be a [inaudible 00:28:28]. It might just be a directory inside the Docker image. So we need to scan all of those files, and if we find an archive, we know how to open it and do a [inaudible 00:28:40] and deep scanning inside those archives. For every file, we calculate the signature and try to compare it against a well-known vulnerabilities database. This kind of scanning is something that you can use to find vulnerabilities in a third-party components, and a lot of them.

Obviously, it comes with a responsibility, on our side, to support as many technologies that are there because that will be the difference between a useful tool and not so useful tool. Let’s see how many of you use Java? Okay, like half of you? How many of you use JavaScript? Here we go. So we need support at least two of those. How about Go? Any Cloud Naked people? Cool. So, we need to support Go. How about There we go. We need to support that, as well. So, you got the gist.

If we don’t support any of that, your next [inaudible 00:29:47] tool that will make and Equifax out of you can be in this language that we support, and we betrayed your trust, and your empire failed. Let me show you how this deep scanning works. You don’t go anywhere yet.

Mm-hmm (affirmative). Sure.

Again, back to our Xray, I want to try build because that apparently not my strong suit. Instead, we will look at an existing build that I ran in a quiet environment, before the talk, so it actually did what it has to do, and it failed as it’s supposed to fail, and that was Docker app. Now, Docker app is a Docker image that has inside a WAR file, and that’s a completely proprietary raw file. This [inaudible 00:30:34] not existing in any database, but inside, we have… Inside the WAR file, there is a [inaudible 00:30:41] folder in each of the vulnerabilities reside. We see that this app definitely has a problem, and when we dive deep into it, we can see that we have 134 vulnerabilities, which is probably shouldn’t go into production any time soon, and look at that. Did I click it? Did I? Did I? There we go. What you see here… Now, it will open all my clicks, obviously, and that’s a resolution that we cannot support. Here we go. Look what’s going on here. We have… It’s just a bad technology day for me.

Okay, we have, here, a strats to vulnerability. That’s the strats, too, that Yossi spoke about, as we rehearsed it before, and he knew that I am going to show it. It’s in the swampUp [inaudible 00:31:42]. SwampUp is just around the [inaudible 00:31:44]. It’s not in any database, which is inside a Docker layer, and now it disappeared completely, which is inside a Docker image. Here it is swampUP [inaudible 00:31:54], and that’s the swampUp [inaudible 00:31:56] that has 76 vulnerabilities. The rest of them are actually in the Docker layer, and they were found by Xray, as well, and you can see, here, that the strats tool vulnerability inside the strats file. So, here it is. It’s just inside the swampUp.

This recourse of scanning can be… That was four layers deep. It can be any depth, with any mix of technologies. If we wanted to wrap this WAR file in a [inaudible 00:32:27] package to install it like, maybe, once inside a Docker image and once on a bar metal, that would work, as well. We will just have one more step in this bullseye that goes even deeper. Right?

Mm-hmm (affirmative).

But I do have a question for you. Equifax, they’re not malicious. They didn’t do it on purpose. Probably when they start to use strats tool, the vulnerability that eventually was used to attack them wasn’t even known. They might even check their builds for known vulnerabilities, but what they had in production is lost, gone from the pipelines. It’s already in production. How can we solve this problem?

Okay. That’s a good point, and it’s actually true. Even if they use a scanning tool, you scan something and the moment you scan it, it might not have any known vulnerabilities and it happens all the time.

Of course.

Requesting or asking re-scan of everything from scratch is not practical. Why not? Because we are talking about terabytes, or even petabytes of data and trying to scan it every time we find a new vulnerability is not practical. So, what we did, and what we have in Xray, is something we call an impact analysis. Impact analysis is basically the ability to answer, at any point in time, a simple question. What if a specific vulnerability has a specific component, has a vulnerability or change license, for that matter? You can get an answer. Which of your files in the organization, which applications, which Docker images will be affected by this component vulnerability? How do we do that? Basically, what we do is… I mentioned that Xray knows to how to scan, and it does a [inaudible 00:34:36] scanning, and while it does it, it builds a graph. It’s a graph of all the components where the parent and the children where the children might be. Another application that has another application inside, down to the list of components. Okay, we take this graph and we save it in the database.

How to we use it? Later on, when a new vulnerability is discovered, it’s reported, might be from the [inaudible 00:35:06], that [Van 00:35:07] will talk about in a minute. This vulnerability will eventually arrive to the Xray database and shortly after you have it in the Xray database, what Xray does is it’s taking the vulnerabilities, it’s checking what are the signatures that might be affected from this vulnerabilities? Taking all those signatures and checking, now, in the components graph. Do we have those signatures anywhere inside our organization? If the answer is true, it will calculate all the path back to the root files. Again, root files might be applications. They might be Docker images. It will create a report and send it to you with a list with all the information of what was the trigger for the vulnerability? What are the affected components that you actually used with the vulnerability? If there’s a mitigation, also, recommendations about those mitigations.

Here’s an example of impact analysis. Let’s say you learn now about strats, too. You come at work on Monday, and you ask, “This strats [inaudible 00:36:16] is bad. Do I have it?” You search it, and you find the strats to vulnerable strats [inaudible 00:36:24], and you’re like, “Oh, my God. It’s in a lot of files,” but maybe they’re just lying around and didn’t deploy [inaudible 00:36:30] anywhere. Well, let’s see. I just picked one of them. Okay, they were part of a WAR file, part of web application, and they are part of a Docker layer, and also a build. But maybe this is just an [inaudible 00:36:49] Docker layer. Maybe no one actually uses it. Let’s see if someone uses it. Yeah, okay. It was part of a Docker image, which was [inaudible 00:37:03], but also 62. You know what? Maybe this Docker image didn’t go anywhere.

So we can go and look at this component and see if it was really used, because Xray sits on top of [inaudible 00:37:21] factor, which is your pipeline all the way to production, so you know exactly in which point of time where this Docker image was. Here, you can say, “Okay this Docker image as in bunch of repositories, and one of them is production, and this is where you go, “Houston, we have a problem,” and that’s your [inaudible 00:37:50]. Yossi, thank you very much.

Thank you, Baruch.

Now, when you know how license compliance can fold your empire, how not smart enough security even baked into your process can fall your empire, let’s talk about… It’s almost [inaudible 00:38:15] quality above quantity. Bunch of questions. Who thinks MVD is a good, reliable and basically enough database of vulnerabilities? Okay, Who knows what NVD-

What’s NVD?

Exactly. What’s NV… Who knows what MVD is? Okay National Vulnerability Database. It’s a governed and run database that contains vulnerabilities and, for a [inaudible 00:38:44] like me, sounds like government database should be good. What can go wrong? Equifax… by the way? CVE, which is, kind of, the golden standard in defining vulnerabilities. When you talk about, “Oh, vulnerabilities,” what’s the CVE number? If it doesn’t have a CVE, it does not exist. The only point of truth for databases is the CVE. Then, that’s a stupid question. Who thinks the bigger database of vulnerability you have, the better? Yes. That’s the right answer. Yes, the bigger event, the better.

To talk a little bit about the quality of your database, but also the quantity of your database, I want to invite a person who you already met in this morning’s keynote, Brian Martin, VP of Vulnerability Intelligence, with Risk-Based Security.

Thank you Baruch.

And, I don’t know a better person to talk to you about a database vulnerabilities, database quantity that the person that does this for fun, for how many years?

Since ’93. Yeah, a few years.

We all have hobbies. This guy collects vulnerabilities.

I did it as a hobby, for a long time, and then for work, and then as a hobby, all along, and now, it’s, kind of, both. So yeah.

Why NPV is not enough? Why CVE is shouldn’t be a golden standard and why sometimes quality is not less important than quantity, which is important by itself?

There’s a old line, “We’re from the government. We’re here to help,” and it’s, kind of, a, “Yeah, thanks, but no.” Real quick, on the whole ecosystem, CVE and NVD are essentially the same. There is a hundred percent overlap. You won’t find a vulnerability in one that’s not in the other. The only that really happens is MITRE, who runs the CVE side, will do the assignment. Then, they kick the data over to NVD. NVD will, then, analyze it. By that, I mean they will generate CPE, Common Platform Enumeration, which is designed to make it so that you can automate the process to take those vulnerabilities and work it into your system and assign a CVSS score, Common Vulnerability… whatever.


Score, yeah. I shouldn’t laugh. We actually give a lot of input to the CVSS SIG and everything, and they do a score in Version Two and Version Three. They sound the same but, in reality, those scores can be very, very different for the same vulnerability. NV2, it might out as a 4.3. NV3, that same vulnerability, might be a 7.8 or something. So there’s a lot of confusion around that as well. Now that you know about the whole ecosystem, the biggest flaw, and I mentioned some of this earlier, is that CVE doesn’t take a proactive approach. They want all of you to go to them and say, “I found a vulnerability. I need an ID. Here’s the information. Let me write the description for you,” and if you do all that, and they’re in a good mood, then they will publish the ID, if they don’t forget. By that I mean, up to 10 years that they, sometimes, forget. That’s not a joke.

That’s scary.

It is. So, that’s where us taking a very different approach to it-

How different? What do you do differently?

We go out. We have 3100 sources we monitor, right now. In the next year or two, that will be over 6,000. We already have 3,000 more lined up. We just need to get them in the rotation, build out the team a little more. But we have to prioritize that, based on what our customers say. You use this library. You use that library. Fine, we want to take those first. Then, we’ll go out and do the more obscure esoteric stuff. By going out and looking for those resources, we’re able to find a lot more. I spend about 60% of my life in bug trackers. If you have a public bug tracker, I have probably been all through it. It’s my favorite thing in the world. Select all products, Search, Vulnerable, or Vulnerability, or Security, or Exploit. Now, I’ve got a full list of all the bugs or the vulnerabilities that have been reported against your products. Put them in our database. Even if they’re old, it doesn’t matter to me. I want to see that whole picture.

You’re going to pick a new library, you have two choices. It’s important for you to be able to say, “Okay, what does this look for a 15-year history? Well, his library has a hundred vulnerabilities, which sounds really bad. His library has 20, which sounds really good, except for it takes him an average of four days to fix them. It takes him an average of four years to fix them. All [crosstalk 00:43:31] of a sudden… Right. All of a sudden, that becomes a very different view into that library for you to determine, “Wait a minute. If we’re pushing out 20 builds a day, we want his library because we’re going to wait four days, at the most… What? I’m getting a red light back there. Anyway… Yes.

I think the most important question that I felt that was supposed to be asked during the keynote, so you have the opportunity to give the answer, now. How do I buy it? Who should I pay to get this superior database for vulnerabilities.

This is where a bunch of frogs are absolutely crazy, and they embraced my model of sales, and I’m not a sales person. They just gave it to you already. It’s already been in that tray all along. There’s no extra software module. There’s no extra fee. It’s just, “Hey, it’s the right thing to do,” and that’s really one of the things that we’re excited about JFrog, is they have that same mentality. I want my data in every organization. I don’t care what kind of money I get out of it. I’m weird like that. Then, we also like them because their due diligence against us was insane, and their level of expectations against us is the same that we have for ourselves. So, we saw it as just a great partnership, as far as the mindset and how we approach this.

Thank you very much, Brian, and I wanted to summarize, in one sentence, what we saw. Basically, the most important problem is… I know that time’s up. The most important problem is not paying attention. So, [Elaine 00:45:09], I’m not paying any attention to you, and that’s the least of my problems. The bigger problems are when you don’t pay attention for your license compliance, when you don’t pay attention to the videos of what your security tool can do, and when you don’t pay attention for the quality of your database, this is how empires fail. With that, two house holding items. First, the closing remarks. Remember? The rest rooms are… No, first of all, there are feedbacks on your table, feedback cards. Put five in every check box, and you’re done. Number two, you have a unique opportunity to ask questions. Those three [inaudible 00:45:54] gentlemen, especially, the lawyer. You don’t get a free consultation every day. Now, you have 25 minutes with him for free, and that’ll be [inaudible 00:46:03] in the discussion zones, and we all are going to go there now. So, come with us. It will be fun discussion. Brian will be able to finish what he wanted to say.

He’ll answer stuff about car insurance or anything you need.

He’s good in everything. Thank you.


Ask a JFrog Security & Compliance Expert