Stephen Chin, JFrog | KubeCon + CloudNativeCon Europe 2023
JFrog’s Software Artifact State of the Union exposes the packages and binaries most in use by enterprise developers today to deliver software from design to production. Key findings indicate an intense and growing interest in emerging memory-safe programming languages for securing the software supply chain; a rise in designing for the edge; plus exponential artifact size and container usage hinting at development of applications such as cryptocurrency, metaverse, and blockchain. Learn more from Stephen Chin at KubeCon.
Transcript
This is texturing TV. Hey, we're back here live in Amsterdam at kubecon. It's the floor is open here.
So it's kind of buzzing around. It's a little cold. I'm not gonna lie yesterday with that sun coming through with warm things up, but not as much sun today.
Hey, but we do have a good friend here with us. We've got Stephen chin Steven is what is your title? He's just I I know you're a VP of something.
I run the devrel team also the events organization and I I sit on all of our foundation bodies. So like the cloud native compute Foundation. Yes.
I'm the chair of the CD Foundation governing board and also recently. We've been making big investments in Rust so yes, I saw that actually there was a well there was a dinner last night that the rest Foundation I think Mike resort was there for our team. I'd love to talk to you about restaurants because I think that's something our audience.
Yeah, but conversation for another day today, we're gonna talk about security a little bit if it's okay. Yeah, and no, I think one of the things we've been talking about and I feel strongly about is Um, a lot of companies are making investments in security. They have multiple security tools dozens.
A lot of our customers have 20 or more different security tools, which they're they're using they're scanning. They're trying to figure out what their vulnerability is their attack surface to try to remediate issues and I think as a as an industry, we're doing security wrong. So if someone who's been in the security industry for 25 years, I will tell you we're doing it better now that we used to be really wrong.
I think. I think what you're describing. Has its number several different reasons number one?
It's the way security organizations have been buying Security Solutions in 25 years. Has been just piling. In some cases one piece of crap on another and you know what you get at the end of really large pile crap.
Number two. We're always searching for the next Magic Bullet like oh if I buy the jayfrog product now. I have not gonna have to use these other 12 products that I bought but no one product is a Panacea.
And so we then we we wind up is just a mishmash. Exactly and it's it's not that having more results are having more databases you're looking for that doesn't improve the quality not of the results, which you really need is you need to have the the right scores for your domain for the sort of applications you're building and then automated tools which are going to do the the applicability or the contextual analysis of are these TVs really relevant for you? And we just we just published a report on some of the top CVS from our security research team, but there were some really noteworthy ones which in nvd got very high severities.
But for your average Enterprise kubernetes deployment Cloud deployment are are very very hard to to exploit. One of them was in the end curses Library. But you had to have you know and curses running.
It had to be outputting it to a file you had to have access to the file you have local access to the server. For different contexts, the the ability to do a Dos on a local account would be a big issue. But for you know Cloud native topology is how we're deploying how we're running applications.
It's not a common scenery be very hard for an attacker to exploit that so that's one which was a high severity and we we recommended for like our customers and for the sort of folks who are using our software. It's it's really a low severity but there is other examples Where our security research team thinks it's a much more severe issue than what's published in nvd. Yep one example.
This is is Nick Gamel. Yeah. So it's the most widely used yaml parser for Java yaml files are used in a lot of Enterprise applications.
It's just a very common technology and the exploit is is very easy to trigger. You just need to give a specially constructed yaml file, which will do a has a recursive structure which does a stack buffer overflow. And then and then you you do a Dos like it just takes down the server.
So easy to exploit there's publish things that everybody's using it but it received a moderate and you for our use case and most of you know Enterprise customers. That's a severe issue. Like that's sometimes people can actually exploit in the wild.
So look I was around. when miter and nist came up with the whole cve system and that and there was a ton of pushback on you can't can't take a vulnerability out of context. And give it a criticality score.
Yeah, you can't you just because context is everything. And there have been you know, more than several Security Solutions over the last 20 years. That tried to bring some.
context to grow vulnerability scores because I think we realize It's wrong. Now. Unfortunately the powers that be in the security world.
I think we all realize it. It's not Optimum. Let's look I'm not gonna say it's wrong.
I'm gonna say it's not Optimum. We've all realized it's not Optimum and we've tried to you know, don't tell the emperor. They have no clothes on but we we massage it by coming up with solutions that try to provide context.
Yeah. So I think one of the things we've we've done is we've married our security research team, which is very strong with our products. And so for example for that snake yaml configuration CV it's it's a really easy fix.
You just you just have to wrap it in a try catch and catch the yeah stack Overflow exception like you've essentially prevented it. And what our scanner will do is it'll actually check your application. It'll see if you have the right exception wrapping around it to see if you've remediated the vulnerability and even if you're using an older version of snake yam, which has the vulnerability.
Or the newer versions you can actually turn on the recursive processing and okay, you're you're still vulnerable in the latest versions if you have the right parameter set, so it'll check the parameters. It'll check your code and I'll tell you for for your application. For your contacts is this vulnerability even applicable for you?
And that's that's something you know, normally you'd get it as a lit in a list of hundreds of CVS. You'd have to go through each one. You'd have to give justification why it's applicable or not applicable and that's a lot of effort which should be automated like we should be automating this knowledge about how to remediate CVS not having it be a manual process.
So again, I had a little experience with this the problem. I'll give you a real world example. I meant City City Bank back then 2008 2007.
They had three Global cios at the time a meeting with one of them in New York City. And we our I was still secure company. I co-founded and we Had the ability to push.
Patches right to remediate yeah, sometimes you patch it. Sometimes you just put in a firewall rule or a routing rule or something a rounding table and you know you could remediate Citibank I tried to sell it to City. It was to be a multimillion dollar deal big deal.
They called me and and the CIO told me we will never do that. Why well because it takes us 60 to 90 days to test. a remediation before we will put it into our into our production.
Because we're Mission critical and we're sitting and I'm not banging City. I'm just you know, that was the mindset that has the mindset changed now Steven where people are willing to say yeah, I'm gonna remediate it. Damn damn Torpedoes Full Speed Ahead because sometimes in the remediation you break something else.
Yeah. I know. I think this is a interesting point and So basically if you look at like the release process, right you have your release pipelines, you're pushing things to production you make sure that you have some way to fall back to previous versions or feature Flags to turn things on and off and I think we've come a long way in terms of doing safe continuous updates and the biggest factor which has been pushing this acceleration is security vulnerabilities.
Yeah, so you have to be ready for the next log for today or log for Shell right? Like when when a big security vulnerability hits and you have attackers which are actively trying to exploit it trying to find vulnerable systems 60 to 90 days is not fast absolutely. But so there's track it to 30 days.
Okay, but that but this I think you know, this is a problem. Between like let's call them unicorns and horses, right and Gene Kim terminology, which is companies that maybe are fully Cloud native fully, you know embrace devops. And and can can do a rollback rather quickly.
I'm more likely to do that. I think the bulk of organization still though are like test first deploy after. And and so, you know when you're City and you're rolling it out or I'll give you another for instance.
I dealt with a very large. Government, one of the largest private networks in the world from DOD 400,000 notes. It's not an easy thing.
You want to push to 400,000 and then say oops I got a roll it back and unroll 400,000 notes. That's a problem. Yeah.
No, I think it's it's a it's a challenge but this is something which really security is the major driver for acceleration of updates and it has to be in large server side deployments. It's it's challenging but you can do nice things with kubernetes and load balancing. Yeah, like updating parts of your cluster as long as it's not like a breaking change in your apis.
And I think consumers are getting a lot more used to this as well because they have continuous updates on we're mobile phone, right? We're nice to that now. It's like you're not surprised when you end up on a slightly different version of a web application because they're like updating it in stages.
Absolutely. I I you know, So I think there's some intelligent ways to go about this. Number one.
Is there a way I could sort of isolate a vulnerability so it's not exploitable until I could fully remediate. So in other words a partial remediation, you know quarantine if you will, it's something we did with our neck product quarantine it until I could remediate it is one way of looking at it. The second thing is you mentioned apis.
So this to me is the New Frontier and vulnerability right even though us now it's coming out with their you know, the API. Vulnerabilities and stuff because so much of of today's communication takes place over apis. It's a whole new class of vulnerabilities sort of here.
Yeah, I think on the on the first one. It depends on the vulnerability, but there is a lot of cases like what the log for Shell exploit you can put in a flag to turn off the jnlp support that would make the vulnerability unexploitable. Even if you are on a older version of log4j right was a good way of remediating that without the risk of upgrading because when you upgrade an entire component, you have to retest everything and that's exactly what I'm getting at your risk, but let's be clear that's not a permanent solution correctly exactly.
But it until you upgrade there's often a good remediation strategy that's lower risk than doing a full component swap. Yep. And I think that sort of like knowledge about the exploit how you remediated how you look at it?
That's really what you need a strong vulnerability team to absolutely all of the context give you steps for remediating give you all of that contextual information. To interject that this is gonna be a great conversation for next week when we're live at RSA exactly and we'll be having these conversations. Apiso.
Is this something Jay frog API vulnerabilities? There's something J frog is looking at yet or will be looking at what do you think? I mean, I think it it's a big vulnerability and risk for organizations.
It requires like some sort of testing or fuzzing to figure out API vulnerabilities for companies. We're kind of expanding out our security offerings to give like a much wider set of source binary runtime vulnerability analysis. And I I think that this the whole gamut of things you need to cover for security is quite wide now like attackers are finding different ways into our corporate environment.
Well, this is why we're seeing these, you know attack surface management is becoming such a it's not a buzzword but a real important aspect of this because it you can't defend what you don't know, you know, and a lot of organizations struggle a lot of organizations struggle with just understanding what their assets are what whether they have out there. What what is You know, what is what is what does it look like to the hackers? I view as we used to call it, right?
It's interesting times. but I don't want to end on a down note. I I will tell you if someone who's been in the vulnerability space since 2003.
We are so much better now that we were then because back then it was was a real crap show. I got to be honest with you and you know progress the days along the years go quick when it comes yesterday. I I be able to dramatic saying we're all doing it wrong.
I thought like the the approaches are getting more modern. Yes, the attackers are all so getting better at exploiting. Well, that's the problem too is you know, this is a constant cat Mouse game and no matter how smart we get his cats.
We got tough mice right and It is what it is one of the quick topic. I'm going to throw in and I don't mean to throw you for a curve. How is AI going to help us with this?
That's that's a good question. So I think one of the things where like a lot of the vulnerabilities are coming from is from fuzzers from different Machine Technologies, which are helping us search for vulnerabilities and open source code bases and and different components and the advantage is that if it's a if we can develop algorithms. To automatically detect vulnerabilities.
Then that makes it easier for research teams to find vulnerabilities before it's discovered by militias attack the next zero day before it's minus one day and I think the the other big part of this is adopting Technologies, which make it easier to build applications which are less prone to security vulnerabilities so memory safe languages like rust are a good way to protect the applications you're writing or to make sure that you have fewer potential risks because it as long as you're not using unsafe libraries, then it automatically protects you against buffer overflows and standard for the guided variety stuff. Exactly. And you know you as long as you using safe libraries famous last words, right because that is the underpinning of all of this right that the libraries the components exactly that we're building stuff on.
You know, we're we're trusting them and that that'll be for another day. We could discuss that. Okay, Stephen.
Anyway, hey, we are live here at kubecon Stephen chin from Jay frog here with us. Are you speaking with us at RSA next week or some? I know I have gal martyr on a panel.
I'm doing about yeah, I might be I think but I think we have one. We'll continue the conversation on broadcast alley there sounds good. Stay tuned about a week from now for now that we're gonna take a break.
We are live here at cubecon. We're gonna be back with our next guest in just a moment.





