← Software Engineering Daily
Software Engineering Daily
MLOps at JFrog with Bill Manning
00:50:24
JFrog is a DevOps platform that specializes in managing software packages and automating software delivery. One of its best known services is the JFrog Artifactory which is a universal artifact repository. JFrog is also focused on rapidly emerging need...
Loading summary
Transcript55 lines
- [00:01]
Shawn Falconer
JFrog is a DevOps platform that specializes in managing software packages and automating software delivery. One of its best known services is the JFrog Artifactory, which is a universal artifact repository. JFrog is also focused on rapidly emerging needs in the MLOps space. Bill Manning is a senior solution architect at JFrog. He joins the podcast to talk about his background in startups and venture capital and his current work in ML at JFrog. This episode is hosted by Shawn Falconer. Check the show notes for more information on Shawn's work and where to find him.
- [00:45]
Bill Manning
Bill, welcome to the show.
- [00:47]
Well, thank you so much for having me, Sean. I'm really looking forward to this today.
- [00:50]
Yeah, absolutely. Thanks for being here. So I'm excited to talk more about JFrog and DevSecOps and some of your areas of expertise. But first of all I wanted to, you know, dive in a little bit of your background. Like, you know, who are you, what do you do? Explain your role at JFrog.
- [01:05]
Yeah, absolutely. So I've been with JFrog coming into almost eight years now. Prior to JFrog, I've been doing this for a long time. Started my career around 97. Yes, I'm that old and that's what I do. But like I've had a very successful run. I've had three acquisitions. One of the things I've done since I was began my career was always pick different technologies every time. First company I had was a first web based CRM platform. A lot of the people that were there went on to form things like Marketo and Sugar, CRM and Salesforce. Next company I did was email encryption and security and we sold that to Cisco in 2006. Third company was IoT before IoT was even a thing. It was called for home. It was the connected device company. We sold that to Motorola and Google in 2010. I was a venture capitalist for a bit. I was with Vodafone Ventures. I was senior media partner. Did another company called XTV about make media consumption to the public in Australia. Did some other work around after that with some startups. I'm also a mentor and then I joined JFrog a little over eight years ago when they were, you know, midway into the company and I had friends here and they said we'd love for you to come in and give your input. And since then I've been a solution engineer, solution architect, manage teams here. I do every little everything from a little bit of marketing to sales to you name it. Currently right now I'm transitioning over actually into machine learning. And so our JFROGML platform, which we just launched this year with the acquisition of Quack, I have now joined that team on a go to market strategy and on top of that also to education and things around that. So that's me.
- [02:31]
That's awesome. Yeah, I mean it sounds like you have a whole breadth of experience so you can kind of be the ultimate gap filler regardless of, you know, what the problem area is. You can, you know, jump in there and add something to it.
- [02:41]
Jack of all trades in a way. Like I learned in my startup years, you know, how to do everything from legal to marketing, you name it. Because I had to. No choice, you know, I had to do it.
- [02:51]
Yeah, I mean I had a similar, you know, I founded a company and you know, and I was the CTO of that company and had mostly experience in engineering before that. And really the way I got my business degree and my, you know, marketing diploma was because there was no else to do those things and you're just like forced to do it. And I think it's taken me on a career path that I probably never would have done if I hadn't been a founder. As part of that experience, you got.
- [03:14]
The practical MBA as I call it. Right. You got the hands on mba. The things that they teach in the MBA school, you learn the hard way.
- [03:22]
I made a lot of stupid mistakes.
- [03:24]
Oh yeah. I'll be the first to admit it too. And I'll be like, that was dumb.
- [03:29]
Yeah. So you had quite the run career in terms of picking the right kind of companies to be part of or companies that have had successful exits. Like, what is your strategy there? Like, how have you been able to pick these companies?
- [03:41]
I'm a very weird being in a lot of ways. A lot of friends say that about me. People have known me in the industry. One guy from a certain venture capital firm, I won't say who he is, but he calls me as lucky rabbit's foot. I seem to be able to sniff out technologies in advance and sometimes I actually, I've had some of the technologies that I've worked with or you know, with companies we've started or big things I've done or we might have been slightly ahead of the curve. I have a tendency to be able to sniff things out and I don't know what it is. There's no real strategy. It's a feeling more than anything. And it also stems from just my inherent, you know, the reason why I got into this industry in the first place is the evolution, the change. It's not stagnant, it's always flowing. And that was a huge kick for me, was like, do I want to be in, like, here I am, 52 now, but, like, when I was in my early 20s, I was like, do I want to be the person that's doing the same job and gets a pension at the end of 50 years, or do I want to be on the bleeding edge of stuff all the time and always be learning? The thing is, is I like the fact that I'm in an industry where I have to constantly keep my skills honed. I constantly have to be learning what's out there. You know, if you don't do that, you're not. You're going to survive, especially in this industry. I mean, like I said at my age, you know, we're in an industry of ageism. And the thing is, is, you know, I hate to say it that way, but it's true. But, you know, that's the thing is we have to stay relevant, is by staying relevant, you know, staying up with the trends, learning the details, not honing on skills that I learned a long time ago as being bedrock and solid, but always evolving and changing.
- [05:05]
Yeah, I've certainly worked with people like on, especially on the engineering side in the past that have had, you know, they have sort of their toolkit and they don't necessarily want to expand that toolkit. You know, they want to go and they apply that toolkit and they can do it very effectively. But that's, you know, kind of what works for them. I think I'm more also aligned with you, where I've always been driven by sort of the educating and pushing myself to figure out. I want to work on the edge of technology, essentially. And that's why I spent a long time, too long in school trying to educate myself and really work on that. On the edge of technology.
- [05:37]
Come on, let's think about it, right? I mean, you know, this, you know, the thing is, is when you read about something, you start learning something and then you start applying the practical portions of it and you get that first light. We used to always say in my first, you know, every startup I've done, like, what's the first light where you get the product to be? Or is that first moment where you all can sit around and look at each other and say, damn, we did it. You know what I mean? Like, this is the start. We know this is something, and I still love that. Like I said, right now I'm working on A couple of things outside of JFrog to kind of keep my skills up. And when every time I have one of those little epiphanies, and actually one of the companies that I've had was Epiphany, but one of the epiphanies is like when he gets to that moment, you go, okay, yeah, you know what? This is practical. I get it. What's next? And then in my head, whenever I've done this in the past, my floodgates open on what's possible and also too, what are the restrictions, what are the constraints I'm within and how do I break down those constraints and barriers?
- [06:27]
Yeah. So what's kept you at JFrog for eight years now?
- [06:31]
Number one, the people. I'm going to be honest, I love the technology, I love the platform. I get to work with some of the biggest tech companies in the world. That's one part of it. But the thing is, is I love the people I work with. You know, like every other company, you, you have to be in a, you know, be able to work with these people, you know, with people you're around.
- [06:47]
Right.
- [06:48]
You need to be able to get along. And we have very interesting hiring policies here. You know, are you a frog or not a frog? Right? And I thought in the beginning I was like, oh, that's cute, you know what I mean? But now I've lear time that that's actually a real thing. We have quality on who we bring into the company. And the thing is, is that, you know, I'll tell you some of the hardest situations we've had here. I've had some of the most delightful and fun discussions because, you know, in some cases when things get tough, humor is the best way to alleviate some of that strain and be able to have people that are in the same similar mindset where you can have that is exceptional. And so for me, having people of the same mindset around me has been one of the major things that has kept me here. Secondly, like I said, I get to work with some of the largest companies in the world and always be on the edge of creating something that will do something. And the thing is too, is I always make the joke whenever I talk to, say, customers or prospective customers, especially if I'm a consumer of their products. I want to be able to say, hey, you know what, I'm here to help you make yourself better, compliant, safer, because I'm your customer, right? I want to ensure that my own personal data, my own personal safety is a top notch. And this gives me A chance to have some sort of influence into that. And so it's a lot of different things. And also J. Frog has afforded me the ability to be out there. Right? The big joke is sometimes people say I'm one of the faces of J. Frog. I do a lot of our public speaking and webinars and things like that. And I enjoy that. For a person who gets stage fright, I enjoy it. And the thing is, so there's a lot of different aspects, but like I said, it also encourages and nurtures employees here to take those steps and keep going. And I also love being able to mentor others like I was mentored when I was younger and bring my perspective. And there's a lot of people here that I think that I love having those conversations. I love the diversity. I love every little bit of it. And that's one of the things that keeps me here, to be honest. Actually, this is the longest I've ever been at a company. I've been one of those ones that's constantly evolving, going. But this company constantly evolves and goes. And so it falls in line with my mantra and it gives me the ability to also excel and exceed with the product and like I said, work with large companies and work with companies that are making a difference. I always make the joke that, you know, people ask me, I'm like, yeah, from Chick Fil A to SpaceX, you know, like, we have this whole large swath of things that we do and that's exciting.
- [09:07]
Yeah, that's awesome. You know, John Maxwell I think said, you know, people quit people, not companies, I think is a quote. And it's true. Like, I think very few people are going to stay at a company that is, you know, up and to the right if they hate their day to day and they can't stand their co workers. Like, it's just going to be a miserable. Maybe some people are willing to do that, but it's going to be a miserable existence. And the great thing about working in technology, especially on the technical side, you have a lot of options, so you don't have to kind of put up with that stuff if you don't want to. And I could tell, you know, you seem very passionate about this. I can understand why they have you out there as the face of the company from time to time. Where was JFrog in terms of like their size and development eight years ago when you joined versus where it is today?
- [09:51]
Oh, absolutely. So when I joined the company years ago, I mean, I was employee, what, number one, 23. And now we're up to almost 2,000 employees. You know, we were like 35 million in revenue that year when we announced it. And you know, and since then, you know, you can see where we're at now, you know, heading towards massive revenue and scale. When I joined, we were, you know, just shy of, I think about 2000 customers utilizing our platform, which was exciting. And now we're almost at 8,000. You know, the thing is, is that over time, watching this grow and expand and have different locations around the world, it's fun to be in the roller coaster as it's going. And in this case, the roller coaster doesn't have an end, it keeps going. But you know, it's got thrills and chills and ups and downs. But the thing is though, is that you're there constantly and watching J Frog grow and being there in the front seat with some amazing people that have gone along for the ride with you and having that shared trench story, you know, you're in the trench together, you know, times are tough, times are good. You know, for me it's been exciting watching the growth. And the thing is, we've adapted and we've always been kind of at the bleeding edge of what's next in terms of that. And so we're able to meet the market where it meets. You know, in some cases we might be a little ahead of the curve, but we're laying the groundwork. Right. And that's the thing is that like now, like even for me, jumping into, you know, this whole idea of JFrogML and ML Ops and it's exciting, you know, every company is going to have AI eventually integrated at some point or some sort of machine learning into their application that's already starting, it's been starting for a while, but be able to actually have. And I look at where that is compared to where DevOps was years ago, whereas this massive playing field of all different technologies. And with JFrog, one of the things that also attracted me was the universality that we've actually embedded into our messaging, which is like I always equate it to. We're the most perfect conveyor belt, right? Raw materials on one side, that's the raw code, the third party transit dependencies and that and some sort of manufactured product that far end. And in between there we provide that layer of consistency. And the thing is you can have all these different tool sets. And the thing is, is that I always had this map that I used to always show and be like, here's the terrifying realm of DevOps right? Every single tool in every single category, from ERP to like, CICD to security. And then platform engineering came in, right? Was like, okay, let's start wrangling this down into some sort of consolidated platform. And it's the same thing going on right now with ML. You look at all the different tool sets, all the different things for tuning and rag and all these things, and we're trying to address that same level of market. So for me, watching the company evolve and say, hey, you know what? We want to be that layer. We want to be that base foundation, the pillar of technology that you build your software on and whatever you choose, because every software company is different. That's exciting too, by the way, is the fact that this company has evolved with that and preached about the idea of, we're going to help make it more efficient, more effective, makes more secure. We're going to be able to deliver your software better. You're going to be able to go ahead and update those devices in the IoT realm. Now we're saying, okay, you know what, we're going to bring compliance, we're going to bring speed and accuracy and efficiency now to ML and ML Ops, you know, because the thing is, let's face the hard facts, 85% of, you know, ML technologies out there that are developing, 85% of those never make it to production. Right. As you're doing this, and how do you increase the fact that that should be lower, Right? It should be half that or even less than that. And you should be able to say, let's build something, let's evolve it. And like I said, for me, J. Frog has been an extension of that, of that natural trend of the actual industry. And our ability to be that consistent base layer that allows them to do what they need to do as a company and ensure that they have a consistent set of tools, accuracy and efficiency. And I'm fortunate enough to work with people that want to provide that to them.
- [13:43]
Yeah. I think, you know, to your point, there's so much new tooling essentially going on in the ML space right now. Like I was looking at, even just with agents, like the agent market landscape. A chart the other day, I think it was maybe from Menlo Ventures or one of the VC firms. There was easily 200 logos on this thing. And agents is like the new, new thing in general. If you expand that to the entire plethora of stack, it's like thousands. I work in the space and it's hard for me to even stay on top of it, let alone Somebody who's just like thinking about, oh, maybe we should kick off an AI project, where to even begin.
- [14:18]
And even now, right, even those are starting to segment, right? So even those layers, that landscape are starting to segment. And that's the thing, is that initially when people have this mass, there's always a way, right? There's always this massive umbrella of what something is. And then inside of that umbrella then things start to segment and factions start to come about and like I said, agents in my opinion is the new battlefield. When you look at it, right, everybody's vying for the perfect thing. And the thing is, is that when you look at it, it's like you said, it's now whenever technology, this is the way I always look at it, right? Is that when there's a segment of technology that gets more involved, people see that this is actually a value add. They want to get into this space, ideas start happening. It's not a bad thing, right? I mean this happened with the dot com bubble, right? It was like, you know, initial thing that happened where people were like, hey, you know what, this is new, this is exciting. Retail, commerce, education, information. And then it got into these segmented markets of little bit players all over the place. Then it went into the next part, like mobile, same thing. All this now ML is the same way. It's like here started off with that small consolidation of things, but then people go, I got an idea. And then the ideas start to spread and then you're going to start to see is that 200 logos probably shrink down to 15 or 20 logos and then eventually work its way down to like five or six major players, right? So it's going to shake out. There'll be mergers, acquisitions, people will drop off. You know, some tools will come across as strong, but they're inferior. You know, I mean there's that natural shake off and that's what the other part, like I said, one of the other things I love about this industry is that if you want to look at natural selection and natural ability of like, you know, our industry is a living industry and I love that the fact that it does change, it does evolve, you don't really see that with CPA work.
- [15:59]
Yeah. And I think I've been in industry long enough and you have as well. Where we've seen multiple cycles of these essentially whenever there's a new sort of shift, there is like this massive expansion essentially of players. Even you go back to social. And people who aren't around for this might not remember it, but there was endless Essentially takes on social Networks. Facebook overtook MySpace and sort of leading the charge there. But there was a lot of competitive players that had their own takes on that. And now we've really consolidated the market to, you know, a handful of players.
- [16:33]
I was like, do you remember Friendster? Yeah, exactly.
- [16:35]
Friendster couldn't scale. Basically their MySQL database fell over and they didn't have the tech talent to scale it and they basically died.
- [16:43]
Right. And that's the thing is actually if you look back at it, I was talking to a friend about this recently. It's so funny you brought this kind of stuff up because like I was talking to a friend about this. You know, we said actually if you looked at the design and everything that was around Friendster, it was actually a superior platform in terms of usability and design. But like you said, the back end of it couldn't support the heavy weight in which they enacted. Right. They had a bunch of brilliant front end, a bunch of brilliant UX and UI and you know, interoperability people, but on the other side of it, they couldn't compete. And the thing is, by the way, remember that was early, there was no real cloud scale, there was no real kubernetes, there was no real way to provide an infrastructure without physical service. I mean, I make the joke of like trying to explain to younger engineers, I'm like, you don't understand. I go, I had this one startup where we needed servers and I literally went to some really sketchy location in Fremont to some warehouse where some guy sold me 10 servers and I had to scrape the dog goj stickers off the servers and wipe them out and bring them back to my server location because that's all we could afford. And now it's like I can go in and be like, I can just auto scale anything I want. I mean, it's amazing. Once you know, I've always been a big fan of adoption of things like cloud native and all that. And like I said, one of the things I really enjoyed about coming here at JFrog was, you know, we're governance board members of the Cloud Native foundation, helping define that roadmap for all these companies that have that successful scale. Not to fall into the Friendster trap of, you know, tipping over at that, you know, 1 million and one user. Right. You know, that plus one, that just killed it all. But on the other side of it too is, you know, to work with the guy. Like we have this guy, his name is Remus. Remus is one of the co creators of Helm, he works here. Amazing, right? You know, it's like royalty, in my opinion. Like, other people are like, oh, that's cool. I'm like, that's super cool. Like, I got to see the guy who's like, what was your inception? What were you thinking when this was coming about how did this orchestration. I had so many questions. I was like a fanboy. Yeah.
- [18:39]
That's awesome.
- [18:42]
Shawn Falconer
This episode of Software Engineering Daily is brought to you by Jellyfish, the software engineering intelligence platform powered by a patented allocations model and boasting the industry's largest customer data set. You know, one of the biggest shifts in the past year or so is the adoption of Gen AI coding tools like GitHub, Copilot, and engineering leaders are trying to figure out if their teams are actually using it, how much they're using it, and how it's affecting the business. Are they shipping more? Is more roadmap work being done? How do you know beyond anecdotes and surveys? That's why Jellyfish introduced the copilot dashboard in 2024 in partnership with GitHub. And since then, they've analyzed data from more than 4,200 developers at more than 200 companies. Want to know an interesting finding? Developers are shipping 20.9% more with Copilot. The folks at Jellyfish have a ton more insights, and you can get started seeing your own team's data so you can plan and manage better. Learn more at Jellyfish co Copilot today.
- [19:35]
Bill Manning
Yeah, I mean, I think that's one of the great things about working for some of these, you know, larger tech companies in the Bay Area. It doesn't have to be in the Bay Area, but you do send a run into some of these people who have invented technology that's, like, widely adopted as an industry standard, and they're just there as an employee and you can, like, talk to them and pick their brain. So I want to transition a little bit to get into some stuff on DevSecOps. So just to start, for those that are maybe less familiar with the space, how do you define DevSecOps and where does it kind of fit into a modern software lifecycle?
- [20:07]
Oh, absolutely. It's essential, in my opinion. Right. The thing is, if you're not adopting this ability of constant. Here's the thing is, we've always talked about, whenever I discuss DevSecOps and I give a lot of talks on this over time, I always start off with just the speed of builds. Right. Like when I started in the industry, we did quarterly Builds, you know, we did quarter releases. I mean, you know, we did builds and we did testing but we only released our software, you know, once a quarter, you know, and it was a big announcement. Hey, we spent, we spent, you know, 90 days working on this piece, you know, this upgrade to what we're doing. And yeah, you know what, we build it occasionally, you know, we test it and things like that. And then of course, you know, everything started to progress. You know, build and cycles got faster as automation became more available. And then of course, you know, in 2006 when we started getting into the whole idea of DevOps, right, you build it, you run it and you know, tools like Docker and Orchestration and all that, once again it was a wild west show. You know, you looked at all the tools that are out there to do something. But the thing was, is that there was this essential idea of DevSecOps, you know, being able to have faster release cycles, being able to have security enabled into it. Right. Originally was just DevOps, you know, the security came and said, you know what? We should really do something to make sure that things are safe, secure and compliant. And the thing is, is that having these iterative cycles, having the ability to create things that allow you to build more rapidly, deploy more rapidly is essential, right? I don't see organizations living without it. It's funny is in some cases you'll see technology, well, not technologies but more like trends like DevOps or others ebb and flow and change or disappear and they evolve into the next thing. Look at Agile, right? I mean Agile came about, now people are like is Agile dead? You know, it's all these things. But DevOps and DevSecOps is essential for speed, accuracy and go to market and having the security behind it ensures your ability to perform for your customers non dependent of silo of industry that you're in. But by providing not only the best software but the most secure and compliant software which is, you know, we know as you know this, you look at the trends in the numbers, you know, like the number of increased in supply chain attacks that have happened that compromise people's software. We always go back to Solar winds is still, you know, it's a use case that will be studied for decades, right? You know, and it was, that was a fourth level transitive dependency in the cycle, you know, I mean it was deep, deep, deep into the recesses of this actual application and it caused $100 billion worth of whatever of problems around the world. But the thing is, is that companies that need to adopt this because it allows them to automate more, do more, make sure the things that they're doing are correct and they're compliant and safe and secure. Ensuring the stability, ensuring security, ensuring resiliency. You know, all the words that you hear when people talk about DevSecOps are true. You know, the thing is that you need to adopt them in a way that works best for your company and at the same time adheres to some sort of level of standards that can also be applied. That when you bring people in, you're not bringing them into some jarring sort of thing. You're bringing them into something that's similar or something that falls in line, at least with minimal deviation. What the definition of a DevSec Ops is.
- [23:17]
Can you have DevOps today without security? Are these really two independent things or should it just be one concept?
- [23:25]
No, they should be the same thing. Here's the thing is, I see this a lot. There's a lot of companies that are like, we'll talk security with them and they'll be like, well, we need to bring the security team in. And some of the questions I always have when I emailing the security team is like, how much delay, how much hindrance does it put on your organization by having a separate security team? The thing is, is that here's an example everybody talks about Shift left. Where do you put the tooling? Where it matters most. And where it matters most actually is at the developer level, right? This is your entry level now. You're not going to have a security person sitting over their shoulder every time somebody codes. You know, this isn't a bullpen, right? Or like one of those, like margin call bullpens. You know, everybody's sitting around in a cube working and there's a security guy behind them going, you know, you shouldn't do that. Oh, you know what, that's actually a incorrect algorithm you're doing there. Oh, you can be susceptible. You might do a SQL injection, you know, nobody doing that over your shoulder. So being able to have DevSecOps as part of it, security integrated in at every phase. Here's the thing, people, you know, it's not a point solution. Security should never be a point solution. It should be an iterative solution that goes through the entire SDLC from the developer level. Even we have here, we have a product called curation, right? Which is like a firewall for your organization to intercept requests. And if those requests come in, these are rules and definitions by companies that say, this is a compliance issue, this is a longevity issue. Like is it operationally risk averse? Are there malicious packages? But it should be all the way down to runtime. And the thing is that every segment along the way is susceptible in one form or another to some sort of security attack. So when people say is security separate from DevOps? I say no, because if it is a single point of failure, then you're failing. Because the thing is that there's a lot more space in that spectrum of what sdlc software development life cycle. And that should be attributed to every segment of the SDLC from shift left as part of the developer experience down to even code, right? Being able to actually go through and say in git. We had a big announcement with GitHub this year around things like auto fix, like how do you auto fix potential security threats and issue? We worked with them on that copilot integration. How do I query and find out before I even do my job if something I want to use to build my software, one of these libraries, that's essential. You know, 85% of what I do as a developer is someone I don't know, right? These third party transit dependencies, is that going to affect me? Part of the, you know, CI process, It should be part of that too, right? Constantly iterating through and as you build it should be doing security checks, looking for things like secret detection. Are my applications configured correctly? Right. Did I forget to enable TLS on a connection that I'm doing to the service? It should be part of the QA process. Even. Even as QA is qaing it, they should also be successfully testing it too. And even when it gets to production, you should give one Little Chef's kiss of security before you deploy it. And then once it's actually been deployed into say, something like a Kubernetes center node, you should be constantly monitoring that too. You know, the thing is, we're CNA, right? So at JFrog, we're CNA, which I adore. I think it's one of the coolest things we do. And we have this massive research team. I love going through such a nerd thing. I love going through their research site and seeing what they've discovered. And you'd be shockingly surprised how much security has now become a normalcy, right? Which it should, you know, it should have always been there. It should never have been those guys in the black glasses with the black hats and the, you know, the shirts that hang out in a room and come out of nowhere and say, you need to fix that because your code is bad. And the thing is, is that there's not enough humans, usually it's like 100 developers to like one security person. You know, it's crazy ratio. So the thing is, security should be part of it. It should be automated, it should be behind the scenes. Plus it allows the security people to focus on what's important as opposed to a bunch of just minutiae that's out there. Like they get inundated by this stuff. Like they're flooded by CVEs constantly. How do you make sure that they're focusing on the right ones? How do you focus on if something is contextually relevant to the issue that's actually being brought up by, say, a vulnerability? How do you know you're being affected by it?
- [27:36]
Yeah, I think one of the other challenges as well, when you have security, I think this goes for privacy as well as these like sort of separate teams that are like satellite it in at the end of like, you know, a launch to make sure that they, you know, bless the thing. It becomes somewhat of a antagonistic relationship as well, where they can be seen as sort of the office of the node because they're coming in at the very last point after people have invested all this time to say, like, no, you need to go back and like redo these types of things. But just to play sort of devil's advocate with this, like does, you know, moving releases to DevOps to the engineering team, to those that are building. We're also moving, you know, some parts of security there. Like, are we overloading essentially the engineering teams with too much responsibility by also giving them sort of security to think about?
- [28:20]
You know what? I'm glad you brought that up. Right. That's actually, you know, that's the thing that we, most organizations, most people I've talked with over time in this industry that friends of mine and other colleagues and, you know, I've been to so many conferences and we've had this debate, you know, how much is too much. And my opinion, and this is very controversial, but my opinion is it's never too much, but it needs to be done intelligently. Okay, so it's not just, is there an issue? This is the nuance. Because the thing is to say I'm a developer now, Security, you're telling me now I'm a security engineer, besides being a software engineer. So not only do I have to sit there and come up with creative ideas and aspects behind the features and things I'm trying to create, but now you want me to be a security guy? Well, how do you do it in a way that's not intrusive? How do you do it in a way that it feels almost gamified in a way, but also too, as a way to help the coder actually become a better coder? And that's the thing. It's a fine, nuanced line you have to ride. And I believe it's every developer's responsibility to do this. I mean, even in the days we didn't have things like sast, right? That lets me know that you're a bad coder, you did something terrible, right? You shouldn't have done it that way. You know, it would take usually some sort of pen testing. It would take some sort of automated testing, maybe down the road, or maybe a physical test. I mean, I remember the days when we didn't have the automation. We literally had to go through and record the clicks right on, say, the website you were doing, and then it would do the injections and testing. Like that was a very manual process. By giving the developer the ability to look at their IDE with the world that they live in, give them all the potential tools that they need to do their job in the world. Their house, right? I mean, your IDE is your house. You're in your house, you have different rooms in your house, you have your source code, you have the code you're working on, you have the dependency libraries that you're monitoring, you have the, you know, you have all these things. But what if you were able to add that layer of protection to that to highlight for you, take the ambiguity out of it. And that's the beauty of being able to use tools like Copilot, right? I have a. You know, with Copilot, the stuff we're doing, we did with GitHub. The best part about this is, is as a developer, I can go in and say, show me a better way, or maybe bring up and show me some of the code. And then what they came to for at JFrog was, well, what kind of libraries can I use? What are the safe and compliant libraries? Why don't I query in advance? Why don't I go find these things in advance? So that will reduce that actual cognitive load I need to do in the security realm. And that's the thing is, so when it comes to it, I think that there's never enough, but it has to be done in a way that it's not like suddenly, like, I love the fact. Would you call it the Ministry of no or the Department of no.
- [31:02]
Yeah, Department of no.
- [31:03]
I'm going to go with the Ministry of no, though I like that because that sounds like a very. It sounds very. But the idea is very. Like I said, you know, when we get back to the idea of like, you can't have a security person hovering over your shoulder, whispering in your ear, like creepily saying you shouldn't do that, you know, like that could be bad, right? This is one of those ones that, you know, I've shown developers, like I said, that's my background. You know, I started off as a coder and, you know, work, you know, done everything. And like I said, if I wish I had half the tools, I always go to my ide, I bring up VS code, which has always been my one of choice, you know, after the acquisition, you know, because it was before anyway. But I go in and I say, look, I can still do my job, but at the same time I now have a bunch of rich information that allows me to do it, number one, better. Right? Takes a lot of the time that would take me to write certain algorithmic functions and stuff and do it for me. So I'm not just, you know, missing a parenthesis or, you know, whatever. And then on the other side of this, making sure that the things I need to do my job properly, 85 to 90% of the things I consume are safe, secure and compliant. And it puts you on a Simulus. It's 100 times more expensive to find a security issue or security object or some sort of potential threat, nefarious component, whatever, in production than it is at the developer.
- [32:19]
So given that we have the growth of interest in DevSecOps and also no shortage of security tools in market and more secure ways of developing software, the problems or challenges that companies face with security incidents, data breaches, are not only not going away, they're actually getting worse. So like, why do you think that there's still this problem despite sort of better tools and practices in place?
- [32:46]
So it's interesting because one of the things that we addressed here, and this is actually when we were working on it a couple of years ago, my eyes ablazed when I heard what we were going to do and I looked at it because one of the problems is the deluge, right? Yes. This is a systemic problem. It's been a problem for decades, by the way. Right. This is not new, it's just become more prevalent. And I think the thing is that I don't think we had the tools to see at the time the level of a potential exposure that companies were having. And I think that's the reason why the numbers are so high in a lot of cases. I just think we're more aware, right? We're now more aware. You know, the problems have happened, the knee jerk reactions are out of the way. Now we're, now we're on standards, right. You know, when you look at things like I said, like solar winds or log 4J. Right? Log 4J. I mean, let's go back and look at that for a minute, right? I mean, that was the, you know, it's the darling of that library, you know, everybody knows log 4J. And then suddenly it became the most toxic mess on the planet, you know, and the thing is, the software bill of material standard came from that and solar winds, right? That was like, you know, the government's reaction was like, you know, we got to do something about this. I was about to say something, I'm like, I curse like a trucker sometimes. But, you know, this is the thing that, you know, we need to react around it. And when we look at this, it's not that it's increased suddenly. I just think we're more aware of it. We have data to back that. And the thing is, is that for us, what made me excited was, is that this constant deluge that developers are like, you know, we started talking to customers and we started looking at reports or like CVEs, aren't that too important in a way because there's so many. It wasn't that they're not important, it's just that how do you constantly, you know, you have an avalanche coming at you of cve, how do you pick the ones that you want to address? And what we did is we created this thing called contextual analysis. And with contextual analysis, we actually look at the actual threat parameters of say, an issue and we say, are those parameters, are those conditions being met that would cause the potential nefarious exploit? Right? And this cuts down the amount of actual CVEs or the amount of potential threats and security issues that our companies we work with have to go after. You know, I showed one customer, they gave us a Docker image and I ran through our thing and I came back with like 458 CVEs, like something ridiculous. And we're like, how long is it going to take you to go through that? And just to find out if you're being affected, not even what level you're being affected, but are you being affected? And they go, probably not. We'll probably go for the, you know, the critical ones. And The CVS score 9.7 and above. And I said, what if I could tell you that 92% of these are not affecting you with certainty. Those conditions for that exploit are not being met. Now you have a small segment of security threats that you can address that's manageable and effective. Now, like I said, that's the reason why I said, even if there's an increase in security vulnerability attacks doesn't mean you're being affected by it. Because in most cases it's a singular condition, right? It's a condition that gets met. What's a parameter, a variable, something that's passed into it, whatever, you know, that causes the exploit or is a chain to exploit what? It doesn't matter. But the thing is is that yeah, there's a sheer scary number out there that's terrifying. 240 something percent increase, like year over year. It's something stupid like we go, that's terrible. But you're like, well you know what though, just because there's an exploit doesn't mean you're being affected by it. It's not going to affect you directly. That's the thing is like when I look at this, I said, yeah, you know what, yeah, it's terrifying. Those numbers are terrifying. But here's the thing too, by the way, just quickly is it's not only are you being affected by it, but if you are being affected by it, how long have you been affected by it? Also too, what other products in your product line might be affected by this? How do you have an audit trail? How do you have accountability behind those components and pieces you use to effectively protect your company or ensure that you have been protecting or to mitigate a disaster that might be PR coming out when somebody finds out that you're being affected by this. And X number of millions of user data has just been been exposed. Right. These are terrifying threats that companies think about all the time. And like I said, just because there's a sheer number of increased supply checks in the supply chain doesn't mean it's affecting you, but you should be prepared for it.
- [37:06]
Yeah. So I know that JFrog works with some of the largest banks in the US like when we think about like DevSecOps and regulated environments, I guess. What tooling does JFrog provide those companies that help solve some of these problems that we're talking about?
- [37:23]
Oh absolutely. And that's actually some of the things we were just talking about. Right? We actually provide various different levels and our banks that utilize our platform use Large swaths of what we do. You know, our security protocol, JFROG security is actually segmented into four different products. We have our standard JFROG X ray, which is different by the way, compared to any other security tool. Most security tools are action based. You need to do something to get some sort of results back to enact some sort of action plan to fix that with art, with our X Ray product. Because of the way Artifactory is symbiotically linked to Artifactory and X Ray, it's constantly scanning, it's constantly evaluating. And it's also, by the way, remember, it's not just one security facet that it should be affected by, right? It's not just CVEs or CVSS, right? There's malicious packaging. On top of that there's licensing and compliance. You know, read those licenses, right? You'd be surprised at how many crappy licenses there are out there. Right? We, you know, that are, are just made up licenses that say you use us and all your code belongs to us. Small print, right? And then the other, top of that is also two things like operational risk. How old or outdated or abandoned are the libraries you're using? Over 80% of the libraries that are out there in Library World, you know, depending on like, you know, the Python, npm, whatever, are old, abandoned or outdated. I mean, that affects you too. If you have an issue with a library that you're utilizing that has been updated since 2011, good possibility that you're gonna have to go hire a company that will rebuild it for you with the fix in place. There's a couple of companies out there that do that or you're just gonna have to deal with it because it's never gonna get fixed. So you can write rules on that too. Now we also have advanced security and advanced security allows us to go through and filter through the actual CVEs that are affected companies, right? Are you being affected by this potentially nefarious moment also too, you know, are you doing anything in terms of secrets? Are you exposing? I'll give you an idea. I downloaded the Docker image, I ran from Docker Hub, pulled it down, I ran through our security product and found out I had access to this developer's AWS keys, you know, his GitHub, everything. I had access, I contacted the guy and he's like, that's impossible, it's clean. I go, did you check your root history? And you go into the image and you type in history and had everything, everything. And I. And he's like, oh my God. On top of that we also tell you are there services or applications that could potentially be potentially threatening in say an image that you're doing? We also do infrastructure as code analysis. I messed up once I was learning Terraform. I did all this stuff, I made my first, I was patting myself on the back and none of the ACLs, none of the security actions I put in were there. And when I ran it through, I looked ahead. Authorization equals none. Totally rookie mistake. But our product found that and it let me know. I was like, oh, I'm not crazy. But we also go to the front line defense on this for them, right? We have curation, which is like a firewall because X ray and our advanced security is once those binaries, once those libraries, once those nefarious potentially various components are inside your environment already, potentially zero days, right. Our curation product acts as a firewall. It intercepts the requests for that. It says I want to bring this library in, but what I'm going to do is I'm going to do a dry run to see you know, what things are coming in and stop it before it begins. And then we have companies now that are using we released this year runtime. So in other words, now we could trace that security issue from before it comes in while it's in giving the developer everything needed in the IDE with SAST and all that. All the way down to. Is this thing in my runtime environment right now and how much of a potential threat is it? This is the stuff that we're bringing to banks. And the thing is that by having a single holistic security solution allows it so that you're not trying to correlate data after the fact. Right. This is correlated data in the same platform allowing you to have that consistency. Like people ask me, if I were to delineate everything we do in JFrog down to one word, I would always say consistency. We provide a level of consistency to organizations so they can reduce the tooling, which means that they don't have tools for all, which also means that there's security gaps and holes. The more tools you have, to be honest, the more holes you have. Because those are interoperable, Right? They don't work together. They don't, they're non interoperable actually with each other. So you have to do manual correlation. And anytime. I'm sorry to say this, but we get humans involved, you know, unless it's an innovative kind of thing, we're actually one of the linchpins in something falling apart.
- [41:56]
Yeah. So you Mentioned the, the guy who accidentally had a bunch of credentials, you know, in image history. And I think that's like one of those things where you read about like some data breach that was due to weak credentials or something like that. And you're like, oh my God, like, how could these people be so, like, dumb? But like, it's such an easy mistake to make as people. And you know, like you said, like, you know, a lot of times people are the linchpin in this. Like, I guess like on the, in terms of security issues that relate to like social engineering or a person being the falter point. Like, are there things that JFrog or a DevSecOps like practices help prevent things like that?
- [42:33]
Well, it's funny as you say that, right? You know, I had a chance to meet like Kevin Mitnick when he was live, right? I actually, I have one of his. I have one of my prized possessions in my home on my shelf is. I have one. I even have it on a little stand. I have one of his lockpick business cards. I don't know if you ever saw those. Because Kevin Nick was the quintessential social engineering hacker, right? I mean, that's how. I mean, he started with the bus system of LA when he was what, 11, you know, and then worked his way up. And, you know, the whole idea is most of his hacks were done over the phone. That's a harder thing. Like, we don't prevent that, right? I mean, you know, let's be honest. You know, we're the code side. We're the, we're the ones and zeros, the binary side organizations. When it comes to the social engineering aspect, you know, that comes down to you, you know, you know, we've all taken those courses, you know, are you compliant? You know, Sally sent you an email and sent you a request to say, hey, I need your Social Security number, your mom's, you know, maiden name and your first dog, right? You know, it's like, oh, I'll answer that. You know, those kind of things are, you know, somebody calls and like, I suppose. All right, I was watching. I decided for some reason to start watching hackers when I was walking, was working out this morning, you know, and, you know, he's like, oh, yeah, he's like, he's like, look at the little box next to the computer. He's like, in my BLT drive crashed and you know, made wl on this. And I'm like, I'm laughing so hard watching. Just, you know, 1995, right? But the Thing is like, when it comes to social engineering, that's more of education, that's more of like concise guidelines, putting in, you know, processes and things like that. We do it from the automated side. We're the robotic side of this, of a house, right? We're the automated thing. We're the people who give you the notifications that you're doing something terrible and you should fix it.
- [44:11]
Hackers and Kevin Mitnick. We're going back in time, really taking me back to my early days on the Internet.
- [44:19]
By the way, I still have a Free Kevin sticker in my office at home, so.
- [44:23]
Awesome. Well, relearning, you were talking about how one of the things that separates or differentiates JFrog is sort of this more like proactive approach versus reactive. And now you're making investments into ML as many, many companies are like, how does that potentially help with proactive? Like, you know, we're entering this area era of like agentic AI and agentic systems. Like suddenly could we actually have some of these security tools that are actually not only monitoring and alerting, but going and fixing the problems.
- [44:53]
I'm glad you said that because actually this is one of the things that we're doing with the, you know, we just introduced, you know, it was actually an acquisition like we talked about before. It was a company called Quack, and now it's our JFROGML product. We also just released our FrogML, which is an SDK to help around this. But the thing is, is that what we've done is, is we've taken our knowledge of, say, you know, DevSecOps, our ability to do this, and MLOps were like, no, this is just an extension of DevSecOps. It really is. When you draw the cross parallels between standard software development engineering and ML engineering, there are, you know, yes, they're different, right, but there's still similarities, right? You're still using Python or R to do, you know, your data analysis, your EDA and all that kind of stuff. You're pulling in data sources that are out there, right? Hugging face. Look at hugging face. Millions of repositories, you know, a repository of millions of LLMs and things like that. We proxy those in our company already. We did this before even the acquisition. And we use our security product to scan for things like malicious packaging and licensing and things like that, making sure that you're not bringing in data sets, that you're learning to train your potential models with something nefarious, something malicious, something that could be, that could cause a skew a biase, a hallucination in data, but also too remember, things are built on Docker, they're actually deployed. I mean, whether you're working with a GPU or you're working with, you know, a standard CPU and then being able to go down and have some sort level of accountability. I mean, we talked about SBOM a little bit over there before, right? You know, the reaction was software bill of materials. Now there's mlbom, right? The idea of like, what did I use to train this model? Right. There's gonna be accountability behind that too. And now I think the industry is now taking it more seriously. And so for us, you know, we're providing tool sets that are proactive. You know, we're building out proactive modeling security. In this case, we just released our machine learning repository so that people can customize, build, tune and have a place where they can version models as opposed to shoving three things into an S3 bucket, which makes no sense. We're going back to the days where we stored third party transitive dependencies before products like Artifactory came out. Right. And the idea is simple. Now we need to take those approaches. You know, ML is in a wild west phase like DevOps was in the early days. Look at the number of tool sets. You know, you talked about that just Google the just will be like ML tool sets or ML things. And you get those maps like we used to have. Remember the maps, you look at DevOps and it's like, here's all the quadrants of crazy crap and there's logos you can't read because they're like the size of a dot, right? You know, these kind of things. And then on top of that they have, you know, the size of a dot. And you know, now we have the same thing with ML.
- [47:41]
Yeah, absolutely. And also like, you know, I think as much as some of these technologies can bring to automating and help us even, you know, automatically fix some security issues, we're also introducing potentially a lot of, you know, security vulnerabilities, especially ads like it is the Wild West. We have so many, you know, new tool stacks. They're going to all have these dependencies could open up a lot of potential supply chain attack scenarios as well as just like tools that are going to the market and security is not job one that they're necessarily thinking about. They're just like, hey, I need to get something out there in order to meet demand and stay on top of sort of the hype cycle.
- [48:19]
Yeah, absolutely. And the thing is, now we're going to go to the next phase of this. Right. Which is accountability. And now with the accountability side, people are going to start demanding more. And I'm going to say, when I say more, I'm going to say more information on what comprises the things that we utilize and interact with with, you know, look at some of the things that are going on, Even like at OpenAI, right. With like, you know, chat GPT4 and now 5. Right. You know, like the iteration of the models. I know that we've already gone past, you know that I think. I don't think they have told us everything on Sentience yet. But, you know, the thing is, is that, yeah, not only is it, you know, preemptive and not only is it iterative through the process, but I think we're heading into the accountability phase, which is, you know, we want to know how the soup's made. People are going to want to know from a legal perspective, you know, what kind of challenging data has been attributed to the marvel in which I'm interacting with.
- [49:13]
Right.
- [49:13]
It's like there's still a lot of things that I think is shaking out. It did the same thing with DevOps, right. And then DevSecOps, and then we started getting into ML and ML Ops and, you know, what's the next phase? I'm excited. I don't know. I've got some ideas, but I like the idea that I don't know, and I hate to say it, though, something is going to have to happen to catalyst that next step. It always does.
- [49:39]
Well, Bill, I want to thank you so much for being here. This was really fascinating. I love your passion. It's really energizing.
- [49:45]
Thank you for having me. I really appreciate it. You know, like I said, we've all been through a lot in our careers, right. And the thing is, is that I love the ambiguity. I love the future, I love the uncertainty. I love a little bit of that chaos engineering that, you know, that our life is. So, yes, I am glad to be here and I appreciate it and this has been a really fun talk. You have some really good, good questioning and I. And I appreciate it.
- [50:07]
All right, well, thank you so much. Cheers.
- [50:09]
Cheers. Have a great day.