Black Hat: Stephen Chin, JFrog

Speaker 1: This is Techstrong TV.
Alan Shimel: Hey everyone. We’re back here live in our Mandalay Bay suite at Black Hat. It’s just downstairs. It’s still crazy. Stephen, there’s so many people down there. It’s like I get a little paranoid. I’m still not used to big crowds like that. But anyway, we’re here with my good friend Stephen Chin from JFrog, and anybody who watches Techstrong TV has probably seen Stephen on with us any number of times. If it’s not Stephen, someone else from JFrog. But we’ve got a bunch of different news to go over today. First of all, Stephen, thank you for coming up. Is this your first Black Hat or have you done Black Hats before?
Stephen Chin: No, actually this is my first Black Hat.
Alan Shimel: That’s what I figured.
Stephen Chin: Yes. I’ve been behind the scenes on all of our recent sponsorships of Black Hat, but this is my first time coming out in person, and it’s-
Alan Shimel: What was your impression? Be honest.
Stephen Chin: It’s just huge.
Alan Shimel: It’s just you and I. No one else is here.
Stephen Chin: It’s-
Alan Shimel: It’s a big show. It’s not quite as big as RSA, but it’s big.
Stephen Chin: But I think something else that’s nice about this is more of the folks that we care about in the AppSec market.
Alan Shimel: This is an AppSec show.
Stephen Chin: Yeah, who are doing software security are here, and we’re getting in the right sort of conversation. Discussing stuff with, and we’ll talk a bit about some of the announcements coming from the Linux Foundation and other folks who are here. This has become the place to talk about and to see where the security industry is going.
Alan Shimel: Maybe.
Maybe. I think RSA covers security and cybersecurity in all of its facets. I think Black Hat is very AppSec focused, but I think the interesting thing is if you look at the history of what Black Hat is, Black Hat was supposed to be about researchers showing their latest research. It’s morphed into a want to be RSA in the desert with a specialty in AppSec, quite frankly. I say that with the most respect. I’ve been in security 25 years. I liked it better when it was researchers and Barnaby Jack was up on that stage making ATM machines spit out $20 bills. I’ve seen a bunch or people… I don’t know, we have people in the background, not on camera. When they would go up and disclose vulnerabilities against Cisco before Cisco fixed them, because Cisco was late fixing them. That’s when Black Hat was Black Hat, the wall of sheep and those kinds of things. It’s tame now. It is what it is.
Stephen Chin: I think security research has become a profession. It’s a field. We have this huge security research team at JFrog. We employ some of the best in the business who originally were doing defense and attack for the Israeli military. They’re very good at their jobs. I think that they’re also the people who are doing interesting exploits showing the research and they are presenting at conferences like Black Hat, but then also their companies and the vendors want to show off how to mitigate, how you can actually integrate this into here.
Alan Shimel: Well, they want to make money. They want customers. I think what’s interesting, and I don’t know if you’re staying for DEF CON, so it used to be the Black Hat and DEF CON were very joined at the head. If Black Hat was edgy, DEF CON was downright raunchy and now Black Hat has gone corporate and DEF CON is edgy. That’s fine, I think it’s part of the maturation of the entire security space, but wasn’t why we brought you in here to talk, Stephen. I wanted to talk a little bit. I had Jens on Techstrong TV I guess about two or three weeks ago now, a new JFrog offering. Well, it better than me. Let me ask you to talk about it.
Stephen Chin: Yeah, what Jens announced, and this was the initial offering for our new JFrog curation service. But as a longtime developer and somebody who’s been using binary repositories as a way of controlling what open source libraries are coming to your business, frankly what we’re doing is actually very simple. We’re taking a best practice in the industry, which is to audit and secure and make sure that your developers are pulling only libraries which are vetted and secure, and we’re making it easy to do.
Alan Shimel: For such a simple sounding thing, it’s a long time coming, no? I had this conversation with an interview we did earlier today. Part of me wants to think that the people who maintain these repos should have some responsibility to the users of the repos to do at least a reasonable, I’m not saying they got to go over them and beyond, but do a reasonable job to make sure that those repos are free of… Let’s call it really either old versions or very obvious malware and so forth.
Stephen Chin: Yeah. Okay. Basically let’s back up into what curation is, how it actually defends you, and then what the upstream risks are. Typical application security looks at scanning and looking for vulnerabilities in deployed apps and production and what you’re pushing into production. That’s too late. As you shift left to go to developers, to go to the folks who are building the software, ideally what you’d want is you’d want a curated, vetted, secure list of libraries which you’re building your software on so that you’re not introducing potentially malicious libraries, or software versions with known vulnerabilities, or any of that stuff into your software supply chain. Now, where are those libraries coming from? Typically, those open source libraries are coming from central repositories. They’re coming from NPM, from Maven Central, from PyPi, from Ruby Gems, et cetera, et cetera.
Alan Shimel: It could be Docker Hub as well.
Stephen Chin: Docker Hub. I think it’s a reasonable question of why can’t the upstream central repositories do a lot more of this hard work of securing the supply chain? I think that there is some discussion as well. I know that there’s ongoing discussions in the EU about putting constraints on foundations and folks who supply software libraries to have some responsibility and onus for it. Now, the challenge and risk with vulnerabilities is not all vulnerabilities are created equal. Many things which get a very high CVSS score, for enterprise applications, if you’re running it inside of a container, if you aren’t allowing user access to the system, those vulnerabilities, they might not be exploitable.
You may have already mitigated it by, for example, putting some code in which catches the exception, which blows the stack or whatever it is that how the exploit is triggered that already may be mitigated in your code. That version of the library you’re using and the known vulnerabilities against it may not be applicable to you. It’s hard to say that this software version shouldn’t be distributed just because it has a vulnerability which may not actually impact people who are using it in production. If the central repository takes it away, that’s also the system of record for what was this original library and what did it contain?
Alan Shimel: Maybe they don’t take it away, maybe they just don’t allow it to download or they download it with a cigarette pack warning or something. Right?
Stephen Chin: Yeah. I think you’ll see a lot of the central repositories are now showing vulnerability info by cross matching it against public databases. They’re trying to do a better job of taking down things which are just plain malicious.
Alan Shimel: It’s too [inaudible].
Stephen Chin: But NPMs huge. How do you monitor-
Alan Shimel: No, I get it.
Stephen Chin: Something that large. Now, I think when you look at this sort of security, what matters more is having the full audit trail in providence of who built the artifact, where it was packaged, what it contains in terms of dependencies, all of that information so that your systems can audit, can identify potential risks and then can stop it from becoming an issue. It’s a combination of what we’re doing with curation, which that’s the firewall.
Alan Shimel: Right. That’s the component firewall.
Stephen Chin: Which stops it coming in for your company. But then it’s also doing the runtime scanning of what libraries are actually using in production of being up-to-date in the latest zero days and CVs, which are coming in. Then having an end-to-end security strategy where as things move through your DevOps pipeline, you’re securing it at each step along the way.
Alan Shimel: Taking a longer view, this is actually very… It mimics what we saw in traditional vulnerability scanning back when I was doing security companies. There was a guy named Giddy Cohen, who actually came out of Israel. Giddy’s company, I forget the name of the company. It’s still around, though, Giddy, I don’t think Giddy is there anymore. But they used to generate what they call attack graphs. It would be first, “Okay, there’s a vulnerability there. Is it reachable? Is it exploitable?” Right? The fact that it was vulnerable in and of itself, wasn’t it. I think we’re starting to see that now on the left side of the equation in your pipeline.
Stephen Chin: Yeah, there’s a couple of things we’re doing specifically for that. One is contextual analysis. It will actually, from a binary perspective, decompile your codes, see if you’re calling the affected API or if you’ve somehow mitigated the vulnerability and it will tell you this vulnerability is not applicable in an automated way so that you get fewer false positives. It’s easier to mitigate. The other thing which we do, which helps quite a bit, is a JFrog severity score, which is applicable to the enterprise application use case rather than the CVSS score, which we still show you, but that’s really what-
Alan Shimel: In a vacuum.
Stephen Chin: The researchers, the researchers will find the defect proposed. It goes through a committee, there’s some scrutiny on it.
Alan Shimel: It’s variability in a vacuum. I’m sorry.
Stephen Chin: Yeah. The actual applicability of that or security exploit being targeted in the wild on a typical enterprise system. CVSS score is a very poor match for that as a criteria. What happens is security teams or DevOps teams, they get told, “Everything with a CVSS score of five and higher, four and higher has to be mitigated.” They spent a lot of time explaining why vulnerabilities, which don’t matter, are not applicable or really don’t pertain as a real security risk. Why don’t-
Alan Shimel: Don’t have to be.
Stephen Chin: Why they don’t have to be. Conversely, there is some security exploits which are getting underrated for the same reasons.
Alan Shimel: It goes both ways, but here’s… Not the rub. But here’s the nightmare. Developers and security teams can’t always agree on this. When you put these kinds of decisions in the hands of politicians, such as in both the EU and here in the States, they’re talking about rules that say, “Software must be free of all known vulnerabilities. ” They’re just chopping everyone off at the knees. You can’t be any taller than that because if you’re a politician who doesn’t know this stuff, it’s a no-brainer. Of course, I don’t want software with vulnerabilities. I think that’s what we need to be afraid of. That’s why we need… You know the old saying? The eight most feared words in the language, “I’m from the government, I’m here to help.” Those are the kinds of things we need to be cognizant of.
Stephen Chin: Yeah, I think when you look at the recent legislation requirements from NIST and other folks in the government who are doing security, the way it’s written, technically, they say it must be free of security exploits, which could be applied or could be exploited in the application. They’re putting the onus of the application creator to then explain or justify why it’s not applicable. Also, they’re putting the onus on the suppliers to know all of the software components to have a full bill of materials, to know all the components which might potentially be impacted. The government’s power is purchasing, so they can apply this to software that they purchase.
Alan Shimel: Absolutely.
Stephen Chin: But the private sector naturally follows whatever the government does as a best practice.
Alan Shimel: Military grade. Yeah. That’s obvious. That’s one issue of it. The second issue is this is not static. What’s not exploitable today may very well turn up to be exploitable tomorrow and vice versa for that matter. The problem is, it’s like when PCI, I don’t know how much you know about PCI, but when PCI was in its heyday. It was scaring the hell out of people about being PCI compliant, they had a thing. Not one PCI compliant company was ever breached. Did you know that? Because the moment they were breached meant defacto on its face that they were no longer PCI compliant. With a clear conscience, they’d get up, the PCI committee or people were governing the PCI, and say, “We’ve never had a breach of A PCI compliant company.” But what about this one? That one?
Stephen Chin: If you applied that to security, we wouldn’t have companies selling software anymore.
Alan Shimel: Exactly.
It’s a ridiculous… That’s what I’m afraid with that we need to pivot though. But before we do, let me tie the loop on curation. Available now, people can go get it at?
Stephen Chin: It is part of the JFrog platform, which is an end-to-end DevOps package management-
Alan Shimel: DevSecOps.
Stephen Chin: Security and curation helps you to lock the doors. But then X-ray, our advanced security offering, those do all the downstream scanning so that you’re making sure that everything you’re pushing to production is free of known vulnerabilities.
Alan Shimel: So curation is great. It’s not meant to be used alone, it’s meant to be part of a bigger set and you can get it from the JFrog set. All right, let’s switch over to your other hat, which is Open Source Linux Foundation Board Member Advocate. What’s happening there?
Stephen Chin: There’s a bunch of exciting stuff which got announced recently from the Rust Foundation, which you’re a member of, and also the Linux Foundation, which we sponsor multiple different sub foundations including the CNCF, the CDF and OpenSSF. On the Rust Foundation side, we’re really, really happy about their new Rust security report that they announced that talks about what they’re doing to secure the Rust ecosystem. They talked about some of the contributions we made earlier this year, in terms of finding some big vulnerabilities in the Rust HTTP libraries, working with their security research team to help to create mitigations for that. Then announcing it so that folks could upgrade and could defend themselves against that. I think that we feel very strongly that languages like Rust are the way forward because they make it much, much harder to get the buffer overflow, inadvertent type of memory exploits, which happen in languages which are not memory safe.
But that doesn’t mean that it’s safe by default, because there’s a bunch of other programming errors, not using the memory safety and different things you can do in your application code, even with Rust, where if you’re not paying attention to security, if you’re not doing testing, doing fixes, staying up in the latest libraries, making sure you’re scanning for potential vulnerabilities in different libraries, you’re including, you’re just as vulnerable as any other language. I think it’s great that the Rust Foundation is both hiring researchers and also leveraging really top industry experts like the folks at JFrog who are working with them on our security exploits or our Rust vulnerabilities.
Alan Shimel: A quick word on that, I think this is a great example of what we were just talking about. Rust was always known as one of the safest, probably most secure languages to be working in going forward. But stuff happens and we learn. What we didn’t know them we know now. That’s just the reason why you got to be constantly reviewing this stuff. You do, even no matter how good or secure you think something is, you’ve got to do a periodic review. You do find stuff, things change, we learn more.
Stephen Chin: I think the other thing which is really exciting is we’ve been a long time member of OpenSSF.
Alan Shimel: Yes, Linux Foundation.
Stephen Chin: Which is the Linux Foundation’s cross vendor effort to help secure the open source supply chain. That’s something that us and Amazon, Microsoft.
Alan Shimel: A bunch of companies.
Stephen Chin: Pretty much like all the big players in the industry are supporting, which is great. But they also launched a new effort called SSP, or Software Security Projects. This is specifically focused on supporting the security tools that security researchers, so CISO security research teams need in order to help secure the software supply chain. The big announcement is OWAS ZAP, the ZAP pack Proxy is going to be moving over to the Linux Foundation. I think that this is the sort of investment that we all need to see in security research tools so that we can actually become better at defending our ecosystem.
Alan Shimel: Let me make sure we got this right though. The Security Software Project, SSP is it a sub of the open SSF or is it directly just under the Linux Foundation as a project, like the mainframe project?
Stephen Chin: Yeah, so SSP is a top level Linux Foundation project that’s being bootstrapped. I don’t think it’s-
Alan Shimel: It’s part of-
Stephen Chin: There’s not the official charter and everything’s not out, but they’re going through the process. OpenSSF is also a top level-
Alan Shimel: That’s a foundation in its own right, for sure.
Stephen Chin: Foundation Linux Foundation. I think that it’s great to see, I mean, you can ask, “Are these efforts competing? How do they relate to each other?” But even when you look at the CNCF, they have a bunch of security projects like in-toto and other critical ones for the Cloud Native ecosystem. When you look at the CDF, Pyrsia, which JFrog supports has joined the Continuous Delivery Foundation as part of that foundation. I think that we all need to look at, regardless of your role, whether you’re a developer, you’re doing DevOps work, you’re doing platform engineering, you’re doing security, we all have a role in securing the software supply chain.
Alan Shimel: Agree.
Stephen Chin: We need to support the open source efforts going on for this, because the best defense against the attackers is having more information, more disclosures, more knowledge and cooperation.
Alan Shimel: More cooperation among vendors.
Stephen Chin: Yeah.
Alan Shimel: I agree with you a hundred percent, man. That’s good. We’re not going to be able to get to it today because almost out of time. But at some point I’d love to sit down and get your views on do we need to reorganize the Linux Foundation and make it a… There’s a lot of foundations floating out here now. For our audience out there, I bet there are more than a few people who are a little confused. I’d like to see a sort of realignment of divisions like they do in the NFL periodically or something.
Stephen Chin: Yeah, this is a longer conversation, but-
Alan Shimel: No, not today.
Stephen Chin: I think there’s a natural ebb and flow of, at the end of the day, foundations are just a vehicle for vendors and open source contributors and folks to come together and to collaborate. You have this ebb and flow of foundations being spun up and projects being spun up, but then they merge, and they coalesce, and they turn into larger aggregations, and some of them thrive and take off. The CNCF is very successful with its big tent philosophy.
Alan Shimel: Good example.
Stephen Chin: I’ll see you at CubeCon, but that’s become the mecca of tech conferences.
Alan Shimel: We’ll be there.
Stephen Chin: KubeCon EU was completely sold out.
Alan Shimel: I think they’re expecting Chicago to be so as, well. What’s interesting there is CNCF, I think has 60 something projects under the umbrella now. CDF, and our audience knows this, we do a monthly show, Lori Lorusso and I, called CD Pipelines from the CDF. What are they up to, about 10 now or something like that, projects. I recently did an interview last week with Fadi, the ED of CDF, and who was with me? Sacha Labourey from CloudBees, he’s now on the board over at CDF. Jenkins, surprisingly, right? Now, Jenkins is of the grandpa of CICD, they did a report on usage and numbers. I was blown away. We’re shiny trinket industry, what’s new and shiny?
Stephen Chin: The old players in the CD space.
Alan Shimel: They’re established.
Stephen Chin: We’re all working together. Jenkins, so not a lot of folks know this, but we support a lot of the infrastructure that Jenkins runs on for the-
Alan Shimel: When you say we, you mean JFrog?
Stephen Chin: JFrog.
Alan Shimel: I just got to make sure what hat you wear because it’s hard to see your hat on you, Stephen.
Stephen Chin: We collaborate with Gradle, which does lot of the builds for the Java ecosystem.
Alan Shimel: I know that. Sure.
Stephen Chin: Now they’re spanning across multiple different platforms and ecosystems.
Alan Shimel: Yes, they are.
Stephen Chin: Artifactory is the defacto standard for binary package management, which is the core of the JFrog platform. If you think about it, the core foundation of what we know today as best practices for application deployment and what gives you that-
Alan Shimel: Pipeline.
Stephen Chin: But what gives you that foundation to build security on, it’s what was created by CloudBees and JFrog.
Alan Shimel: The DevOps people over the last dozen years or so. That’s a hundred percent true. What’s the other project that comes out of Netflix and Google?
Stephen Chin: Spinnaker.
Alan Shimel: Spinnaker, another one, right? These are anchors in every meaning of the word. Anyway, hey man, it was great catching up with you. I know we got a little bit off security and we’re all over the place, but such is the nature of our conversation, Stephen.
Stephen Chin: Yeah, that’s something good.
Alan Shimel: I guess I will see you next, actually swampUP coming up.
Stephen Chin: Yes, yes.
Alan Shimel: Tell the people about swampUP.
Stephen Chin: Yeah. SwampUP is the mecca of DevOps conferences. It’s going to be in September in San Jose at the Signia Hotel, and it is going to be amazing. We have Bruce Schneier-
Alan Shimel: Friend of mine. Yeah, I know Bruce very well.
Stephen Chin: World famous security guru friend who’s going to be on stage. You get to chat with him and hear from him about his perspective.
Alan Shimel: Bruce always loves to chat, by the way.
Stephen Chin: We have all of the leaders.
Alan Shimel: John Willis.
Stephen Chin: John Willis.
Alan Shimel: Whose new book is out,
Stephen Chin: Tejas from Netflix. Yeah, the list just goes on. All the key movers and shakers in the DevOps industry are going to be there. We’re selling out quickly. If you want to be there, sign up now.
Alan Shimel: The place to go. Then after that, we’ll see you in Chicago in…
Stephen Chin: November.
Alan Shimel: November for Kube Con.
Stephen Chin: Yeah.
Alan Shimel: All right. Stephen Chin, a man of many hats among them, JFrog, Linux Foundation, OpenSSF, CDF, and a bunch… Rust Foundation. Here, live in Black Hat. We’re going to take a break, so stay tuned. We’ll be here in just a few minutes.