Programming Throwdown - 158: Software Supply Chain with Bill Manning

Episode Date: May 22, 2023

In today’s episode, Jason and Patrick dive deeply with JFrog’s Senior Solutions Engineer, Bill Manning. With the conversation tackling the depth and complexity of software supply chains, vulnerabilities and more, Bill deftly offers grounded advice to listeners old and new. 00:00:26 Introductions00:00:40 Bill’s plethora of job titles00:09:33 The excitement of learning a language00:15:08 Mechanical keyboards00:21:17 Bill’s advice on adapting00:27:55 What a supply chain is00:34:28 Castle analogies00:40:55 Unpacking legalities00:52:11 Log4J00:54:41 What JFrog does01:01:16 What can go wrong01:08:08 Getting started in this space01:14:15 Careers in JFrog01:20:23 FarewellsResources mentioned in this episode:Join the Programming Throwdown Patreon community today: https://www.patreon.com/programmingthrowdown?ty=h Subscribe to the podcast on Youtube: https://www.youtube.com/@programmingthrowdown4793Links:Bill Manning:Website: https://about.me/billmanningLinkedin: https://www.linkedin.com/in/williammanning/Twitter: https://twitter.com/williammanningJFrog:Website: https://jfrog.com/Careers: https://join.jfrog.com/Artifactory: https://jfrog.com/artifactory/Linkedin: https://www.linkedin.com/company/jfrog-ltd/Others:Liquid Software: https://liquidsoftware.com/SolarWinds hack incident: https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/Transitive dependencies: https://en.wikipedia.org/wiki/Transitive_dependencyMore Throwdown? Check out this prior episode:153: ChatGPT: https://www.programmingthrowdown.com/2023/03/153-chatgpt.htmlIf you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM | Youtube Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon  ★ Support this podcast on Patreon ★

Welcome to another episode of Programming Throwdown. I have a great guest here today. We have Bill Manning. Take it away, Patrick. Welcome to another episode of Programming Throwdown. I have a great guest here today. We have Bill Manning. Bill Manning is a senior solutions engineer for JFrog. Any title he wants. And that's the one we did. Welcome to the show, Bill. Hey, guys. Thank you so much. Yeah, I mean, it's weird. It depends on the day. You know, there's the solution engineering manager one day solution engineering solution architect that guy you see who does youtube and videos on and does talks on that's that's the title that's the one to go with right there you know what it fits really well on a business card oh you know i am all about the business card not quite patrick bateman material like american psycho but you know what i mean you know if we're looking for a little

bit of the you know make sure that raised lettering, we're all good. I one time did get business cards and then they promptly sat on my desk and I think I handed out five of them ever. They make great paperweights. Those boxes have a nice heft to them. If you still have paper on your desk, you do that.

You just put them there and then you stare at them and you pull them out as nostalgia value and you're like, I should really throw this out. And then you're like, I'll take at least a card and you put that there and then you stare at them and you pull them out as nostalgia value and you're like i should really throw this out and then you're like i'll take at least a card and you put that away and then you shuck the rest right just to prove you had a title at some point that's right that's right i think i still have a stack of them in my garage from my previous company or whatever just like i don't want to throw these out they were cool i think i have them all messed up somewhere in like some like random location i'll pull them out something i go wow that was weird you know it's like yeah it's like the basketball cards i have that my mom brought you know when i became an

adult my kids found them and they're like who are all these random basketball players and i'm like i also don't know because like there's some b-string players from like you know when i was a kid that never amounted to anything but it's who's you know you just get randomly distributed cards in the card pack like these are the people you got these are the comments or you can be like me though i used to have at one point when i was a kid i collected the entire star wars top series like for both star wars return of the jedi empire strikes back i had them all together and and they were doing a house cleaning and my brother threw out the entire thing and oh yeah all of it my millennium falcon i still let them i won't let them let them down to this day by the way man it's just it's it's still right here right yeah i

was like do you go on ebay and cry or are you okay i avoid that man because that would just be like me sobbing a lot all right well we normally start off here but before we jump into the the sort of topic of the day, we normally kind of start out just talking to our guests and finding out how you got in tech. And sometimes that's like the first program you wrote. If you have like a memory of like the first computer you got, like whatever, you know, is there like an experience that was just sort of like, yeah, yeah, that was something I sort of remember as early in my journey. Oh, well, yeah. Let's start off with just talking about, you know, I am definitely significantly older, right?

So, I mean, just give an idea, you know, my first computer that I had access to when I was six years old was an Apple II. And that would have been in 1978, early 1979. My mother was a math teacher in New York. And when they, Apple was giving computers because they wanted to show what it can do to schools, even then. And my mother being a math teacher, they were like compute computers, they must go hand in hand with mathematics. And so I came home with a bot with boxes and, you know, all the manuals and stuff. And it kind of sat in our living room. And I was like, what's this and i had always been a sci-fi nerd i mean you know this is like just the way things were and even back then you know space 1999 was like a big thing for me star wars of course

battlestar galactica you know all these things and i was like computer you know and uh so i took it so i took it out read the manuals put it together busted out the the book that said basic and then just started getting into it then i I went to the Commodore 64. It's funny, actually, is I'm not traditionally trained in terms of computer science or anything like that. Actually, I went to school for philosophy and theology, business, you know, those kind of things. I'd always done it for fun.

And then I moved to California from the East Coast. I grew up in New York. I was born in Long Island and I moved to New Hampshire and New England and then moved to California when I was 24, 25 years ago. Well, over 25 years ago now. And yeah, I just I got into it. You know, I didn't know anybody, moved to Silicon Valley, got caught up in the dot com boom, you know, done various tasks over time. But I've always just I've always loved it. To me, it just seemed there was something inherently that my brain just got. You know, I mean, like I can pick up languages very easily.

I can, I've actually started companies based on my approach. So like what I wanted to learn MPM, I wanted to learn node, right? I started playing with it and started the company called XTV, you know, got investment and all that, but it all started because I wanted, I was curious. I liked the idea of server side and client side JavaScript, right? To me, I was fascinated, but just by the concepts, you know, this would have been, you know, and I was just like, okay, great. So I dove into it, learned it and then decided I was like, hey, you know what, I think I found a good application to

use this for. And it was fun. You know what I mean? So like my entire career has been a journey of also to making sure that every company I've either started or every company that I've worked in with friends, usually, I've always done startups, is something completely different every time. I never picked the same technology twice. That's always been my rule. I got into this industry for a reason. So my first company was Web-based CRM. We were the first Web-based CRM. A lot of the people went on to found Marketo, Sugar CRM, helped build Salesforce and all that.

I went from there, did email encryption and security in my next company. And we sold that one. And that was great. Next one was IoT before IoT. It was actually called the Connected Home. I actually have a bunch of awards behind me over here. We actually created a platform for IoT back in 2006 and 2007. Once the ES awards for, you know, basically we wrote a protocol layer that allowed us to like bridge

all the various IoT technologies like Z-Wave, Zigbee and all those into a common language called FCML. Actually, it's funny as FCML is called a few, we call it the fluid communication meta language. Really overly complicated name for what it did, but it was a translation layer. Yeah, you know, I mean, like I said,

and then did media for a while. I did some work as a VC with Lord of Adventures. That was fun. Mentorships. And I've done a lot of things over time. And my latest one, of course, is I joined over six years ago, I joined JFrog. And now I'm helping build tools and work with companies for better, more efficient software development and also safer software development. And to me, that's really important. And actually, I really fell in love with the concepts of being able to do this, right? Because I get to work with people, I get to help make things safer, more efficient. And to me, that's really awesome.

Like, you know, take my wealth, you know, all my years and decades of experience and be able to shape it into something. It feels weird saying that, man. Yeah. Yeah. I'm, I'm, uh, I'm not there, but I'm almost there as far as, uh, saying those same things and being like, get off my lawn. Okay. Go back just a little bit. Uh, okay. A lot. Uh, you sort of started out there. I wanted to kind of, so you said you went to school for, well, first of all, that's kind of interesting, philosophy and theology. And then you ended up moving to Silicon Valley. Okay, I think I missed something there. What, how did you decide to have, you know, go to school for that and take the move out to Silicon Valley?

Was there, was there something there? Well, it's funny, is it because I've always, you know, even when I was doing that, I always still was still doing it right behind the scenes to me it wasn't like i never you know it's funny i don't think i ever really looked at it as a career is more of just a thing i did right you know i mean like since i was a kid and stuff you know like whether it was you know playing games writing my own games you know back on my commoner 64, when I had that, right. And then that worked up into my first PC, my first, you know, i386. And, you know, like, oh, my God, you know, this is this whole new world out there for me. And, you know, teaching myself way back, you know, when long ago, you know, like, all right, well, you know, I first Linux, you know, sets of Linux, I started working,

looking at 1994, 95, compiling my own kernel, you know, I mean, to me, it was just like, all this nerd stuff i did for me personally and i never looked at it that way it was just what i did you know at the same time it's like while i was doing that like i said i was going like even like when i was in college that's what i was going to college for but like i was playing in like a hardcore metal band also and then you know like you know hardcore metal band you know jamming doing that and then playing dnd and and computer games and programming. You know, it was kind of like I was all over the place.

And my best friend moved to Silicon Valley, and I'd been here before, you know, Northern California, and I fell in love with it. So I said, you know what? What do I got to lose? I'll go out and thought my way into the industry. And like, just, I just started, I started teaching myself more and more when I realized how much I really, really inherently, it wasn't even like I was doing it to get a job. I was like, wow. I'm like, I really realized that this is me. This is, this, this, this is where I'm happiest. Like I'm like, I'm really happy in a shell and happy. You know, so it's funny as I work with people all the time and I have to manage people and all these things,

but there's still some times where I'm happiest, where I've got my headphones on, I've got my keyboard, I've got my shell, and I've got my ID, right? And I'm creating something. I still get excited when I'm learning a new language. I started teaching myself Rust a couple months ago, because I wanted to learn it, right? It's the fastest growing language. It has all the things in my brain that go, this is awesome, right? I mean, it's got the heaps kind of stuff and memory, you know, cleanup that you would get with Java, but it's got the speed and efficiency of C and C++. It's highly portable, right? You don't need a runtime. Like to me, I was like, oh my, where have you been

all my life? You know what I mean? Those kinds of things. And so like, I still like, when I first got my first set of things working, I was like, this is cool. You know, like, I still like when I first got my first set of things working, I was like, this is cool. You know, like, I'm like, Ooh, I'm generating HTML. But at the same time, I'm able to go ahead and manipulate the chip on my Raspberry Pi, you know, to start flicking LEDs at the same time with the same language. I'm like, this is insane. I'm like, it's got this bridge to the mic, you know, to the microprocessor. But at the same time, it can create a visual element all within the same object type. I'm like, how is that even possible? You know what I mean?

So you mentioned something there and then I'll sort of take it forward. But you mentioned going and visiting Northern California and, you know, kind of falling in love with it. I actually think this is something that people don't talk very much. Everyone sort of knows Silicon Valley as the sort of like semantic label for the group of tech companies and people that work there. But I think it's somewhat underrepresented just how beautiful the area is.

Even with so many people living there, having spent time and living there, it really is a very beautiful, like natural beauty, access to parks and hiking, just like the amount of things to do. It's crazy. Think of any other place where you could technically, technically you could do this.

And I actually know some people who have done this. I know what story you're going to say. Okay. Go up. Spend overnight in Lake Tahoe. Wake up in the morning. Go for a quick couple of skis in Lake Tahoe. Get in your car.

Drive down. Stop along the way. Play nine holes of golf. Get back in the car. And then go out to the ocean. Take a dip in the freezing cold California, Northern California ocean. Thank you for calling that out. Yes. But go for a swim and then hang out and have a bonfire on the beach, right? In one day. One day. Yeah. It is a beautiful area.

Oh yeah. I mean, I'm a cyclist. That's my outlet. Like, I love cycling. And to be honest, this is one of the greatest places, bar none, to cycle. I mean, we have thousands of miles of trails, tons of hills. And when I say hills, they're basically, compared to East Coast, they're mountains, right? Because they're like 3,500 feet and higher, you know, and all these. And yeah, like you said, I mean, I'm 25 minutes from the beach in Santa Cruz or, you know, and it's great. I mean, that's the reason why I loved it here is the weather is temperate. Yes, don't get me wrong. Housing prices are insane. Everybody's like, what about the earthquakes? And I'm like, okay. And especially my best friends, I'm like, we don't have earthquake season where you have tornado season, you know what I mean? Like, or hurricane season. I'm sorry, dude. I mean, you're in Florida. My parents are there too. It's like, you guys have tornado season you know i mean like or hurricane season i'm sorry dude i mean you're in florida my parents are there too it's like you guys have a season ours is just random luck in there we're gonna roll the dice and you know it might happen might not you know you know people are like oh you guys got a 4.1 or 3.6 and i'm like we did yeah you believe it

you lived here you're like people like did you get rattled? And we're like, I'm like, I just thought somebody was dropping something off. A semi-truck was driving by. Yeah. And then you mentioned being happy sitting there typing on your keyboard. So I got to know how clicky is your keyboard. Are you a keyboard enthusiast? Oh, yes, I am. And this is my Keychron K1.

I think it's fantastic. It's a super low profile. He's showing us, for those of you who can't see. Oh, they can't see. The underlit beauty of his keyboard. That might be the brightest keyboard I've ever seen in my entire life. Extremely bright. I actually turned it on just for you, just to kind of show you. I usually keep it off, but the fact is, and yes, it is using, actually in this case, this one is the blue. The blue switches. I usually go it off, but the fact is, and yes, it is using, actually in this case, this one is the blue. Blue, okay.

The blue switches. I usually go with the brown, especially in my office because- Yeah, blue is not nice for your office, you patriots, yes? No, no. I mean, when it sounds like you're just grabbing a bag full of ice and constantly shaking it next to you and the people. So if we hear the sound of hail on your roof, that's just you typing momentarily during the podcast. That's it right there. But no, I love this because it's super low profile. And the feedback on it is fantastic. Yeah, I mean, I thought that there was an earthquake, but it was actually just Bill fixing bugs in NPM. Oh, there you go. Exactly. People like what's

that? It sounds like hail. Like, what's that noise? You know, it's funny, though, one of the best most satisfying keyboards is actually I should almost grab it and hold it up to the mic just so you can hear it because the computer is over 40 years old. It's actually an Apple IIc. Oh, okay. That I have. And the keyboard to sound on that thing is spectacular. I am not going to lie. It is the clickiest, clackackiest most positive feeling keyboard ever and

i like i said i have a they can't see it but like i have a i have a couple i have a bunch of those computers behind me i've got like my mac se my apple 2 apple 2c everything um yeah i like that stuff yeah i thought you were gonna talk about the yeah model m which is the like i mean where people pay obscene like they find it in the thrift store and they like video themselves and put it on the internet look what i found and they restore it yeah i actually have one of those in my garage it's actually in my garage i've got a lot of those but yes i used to have one of those and i had the adapter for the ps for the uh the interface ps2 to usb adapter because in those days i like I said, that feel was amazing. The buckling spring mechanism.

People will wax poetic about the mechanism by which their keyboard types. This one feels pretty good too, though, I will say. I will say the Keychron, out of all the ones I've used, I'm a huge fan of Keychron. I think that they're really solid, especially it's got a metal chassis and it's got a metal frame. So, I mean, it just has weight to it. So when it's there, you're just jamming away on it.

It feels great. Like I don't get tired on it at all. Just wait until you find out about all the people like soldering magnet wire to like flexible PCBs and 3D printing sculpted per parametric per finger length. Bespoke? Just wait. It's like a bespoke soup. It's like bespoke keyboard. But this one's different because it's...

Well, do you know how many hours a day you spend typing? Like it justifies that. It's the same thing like your bed. Do you know how many hours you spend in your bed? I can justify any amount to you based on this. By the way, at JFrog, we actually have a Slack channel dedicated to keyboards. Oh.

Seriously. We have one dedicated to pets, one dedicated to keyboards, and one dedicated to Legos. Of course, Legos. Okay, yes. Fair enough. All right, so you took us on the journey. One other comment I had, just because it's something that people write into us about and I think has been interesting is it feels like it's ebbed versus flowed a little, I guess, in recent years, just to do to let's call it macroeconomic trends. But you mentioned sort of just wanting to grind it out, showing up that that wasn't your background,

but it was what you were passionate about. And you sort of like worked it. I didn't hear you say, and please correct me if I'm wrong. Oh, you went back to school, you got a different degree, and you sort of got the pedigree, you sort of round up. And this is a debate that, you know, people write in and ask for our advice, is it better to go out, let's just use your term, sort of grind it out and sort of try to get programming jobs and build your way up or to stop what you're doing and go get the credentialing to make it in? Do you have any thoughts there? Just curious, because that's a sort of unique background that you presented. That's a very, you know, it's funny is that's a very interesting question, right? Because there is value in both, right? And it's hilarious,

because I mean, in one of my jobs, I remember I worked with almost everybody I worked with, probably some of the best engineers I've ever worked with, and was one of my first startups. The thing is, is that, and there was a bunch of them that graduated from like Stanford and Cal and all, you know, from like Berkeley and all those absolutely brilliant. And I remember a moment for me that was hilarious was, you know, being self-taught and, and like getting the books and just diving in and grinding it out is that having both is actually pretty awesome, especially in terms of developing software. You have the more traditional collegiate approach, right? Which is like, you know, where they excelled and I learned tremendous amount from them. But at the same time, I think my unorthodox approach also voted well,

like, because I attacked the issues slightly different. And I think the combination of both is pretty essential. Yes. Did I take, if I'm looking back, do I wish I realized that this was my thing? Or, you know, and I always kind of knew it, but I just never thought I would actually consider that as a career, especially, you know, you gotta remember I'm over 50, right? And, you know, I saw, you know, this was like back, you know, when I started going to school was the late 80s, early 90s. And during that time period, that professional ability wasn't really out there per se. It was, but, and this is the funnier part,

is that now it's, you know, I think the dot-com boom really pushed it into, in some cases, programming as like a rockstar persona in some respects, right? Suddenly, you know, the guys who were doing this stuff suddenly were actually becoming, you know, famous. They were becoming visually out there. Like it was a very different thing.

And don't get me wrong. It's like I'm reading right now, like the book I'm reading right now, I was being meaning to read for a while. And I finally started reading was like Bill by Tony Fadell, right? If you haven't had a chance to read it, it's a phenomenal book, right? It's his history at Apple and before that, you know, during the general magic era, because back in that time period in the early 90s, they developed the real first like mixture of PDA, cell phone, you know, basically a communication device in your hand. I mean, everything in that device actually was the precursor of all the people from there. You know, Hertzgag and all those guys came from, you know, from that and created, you know, the iPad, the iPhone and, you you know, the iPod and all that, like that group really set the trend. But like, the thing was, is that even they weren't recognized until the early 2000s. So like I said, going back, I wish understanding my aptitude,

understanding my own personal strengths in that respect, that I wish I had maybe approached it that way. But at the same time, I'm actually very fortunate in my brain that I didn't, right? And in some cases, because I did kind of grind it out. And by the way, you want to know the main reason why I got into the industry?

The biggest one for me? Real quick, if I just interject. So we did talk about Tony Fadell's book, Build, on episode 153. So folks out there, if you're listening, and you want to buy the book, please, please, please go to our show notes for episode 153. And click the link that helps out the show. There you go. Fantastic. So I'm gonna go check out episode 153. After this, actually, because like I said, I'm really fascinated by it. But

you know, the thing was, is that and this is for every student or every person that's ever, you know, looking to do this, or if they've already have, you know, looking to change careers or whatever. The main reason why I got into this was not for like, because I mean, yes, I like I have the aptitude for but the fact is, I'm always learning. Right? I'm not stagnant. And by the way, this is not a thing perpetually that happens for everyone. I know people my age in the industry that kind of fizzled out, right? They stayed with one thing and then they've had tough times in their career where things have had recessions, like what's going on now and starting in this, even if they're going to school or they're grinding it out, whatever, you know, is the fact is adapt, right? Constantly learn. You're in this for a reason. It's exciting, right? You're in an ever-changing organism that's in it, right? You know, it's always evolving. It's always changing. It's not stagnant. It's, you know what I mean? And to me, I would die, seriously, if I was like in a nine to five grind job where I'm, you know, looking for TPS reports and stamping crap, right? I would lose my mind. You know, the fact is, is that when a new technology comes out, my first reaction is, ooh, shiny. You know, I want to go check it out. Like I said, like Rust, you know what I mean? I was like, if I'm going to work with my customers properly, I need to understand the nuances, right?

I need to understand. And to me, actually, that's the exciting part, right, is when you are going through it and you are starting in, you get that first light, the hello world. You know what I mean? Even that first one, you're like, okay, fine. I got a hello world. That's great. That's not the one that always excites me because that's just like, okay, that means my environment's prepped and now I'm ready to learn, right? And then when I go in and I start doing things like, ooh, I'm going to make a multi-class

array where I can go in and blah, blah, blah. And I start doing something and I produce an output and I go, that was not what I expected. And I probably did it wrong. I probably should go in and check it out, right? Because it's never going to be right the first time. But that's even more exciting when you realize that, wow, I screwed up. Actually, to be honest, that's my favorite part is because if I did do it right the first time, I feel like I don't understand the nuances enough. And if I do screw

it up, that means now I got to learn how to fix it. And to me, and here's the thing is, and I've talked to other, you know, engineers and stuff, and CS is great for learning theories and abstract thoughts and being able to go ahead and build up formulated models with algorithms, blah, blah, blah. One thing that, and my buddy's son right now is at one of the programs at Berkeley, right, so he's going for college. And I said, I go, well, you know what, debugging. Like, one of the things is, is that early in my career, and here we go, and actually not even before my career, remember I said I played video games, like, when I was a kid on my Commodore 64. Now, here we go. And actually, not even before my career. Remember I said I played video games like when I was a kid on my Commodore 64. Now, here we go, guys. Now, this is going to sound old, antiquated, and crazy.

But back in the early 80s when I had my Commodore 64, you know, I had my little CRT monitor, right? It was a TV. They had to put it on Channel 3 and, you know, adjust it so that you could play. People have no idea what you're talking about right exactly right you had to put it on channel 3 because it had like it actually had that sound and then you plug i had i had a hard disk that weighed like 40 pounds uh you know i actually had the floppy drive and the floppy drive would give this really satisfying when you actually would go in and actually use it but if i wanted to play some of the games i would go

and i would save my money by the way this sounds really ridiculous when i say this to people who don't understand save my money to go buy a box of floppy disks bring them home by the way and use a hole puncher to make them double-sided so that i can make them actually so i can use both sides because they were actually were double-sided it's just you only people use one but if you hole punch the other side you could put it in and use the other side. But at the same time, if you want to play some of these games, you would actually get a magazine. And you'd come home with the magazine, and there would be like 15 pages of code that you had to manually type in to play this game. And it would take a long time. But I will say, I think because I had to go in and type it every, all that code in, 15 to 20 pages, we'll say, of little, you know, we're talking like 10 font, right?

Like micro font. And then having it run and then having to go back and debug it. Really, you know, I have like this thing where I can look at a log in any system that's been built. When we build systems and stuff, and say I'm working on a feature and I've got to watch the log. I think because of that, I've got pattern recognition that I can look and watch logs go by and be like, stop. And people are like, what did you see? I'm like, stop. And they're like, well, go back.

And I'm like, there it is. I can visually, for some reason, but I think a lot of that has to do with me back then coding by hand like hundreds of lines and being like 10 or 11 years old and doing this and being like and then having to figure out what went wrong now picture having to go through all that without even a real debugger or a compiler you know the ability to set a breakpoint didn't exist so you know like you couldn't set a breakpoint to see oh maybe it's, you know, the ability to set a breakpoint didn't exist. So, you know, like, you couldn't set a breakpoint to see, oh, maybe it's here, you know, oh, maybe on that path, you know, maybe the value is wrong. So I think there's a combination of things that people need to know. And I think people should, you know, definitely, you know, you're in an industry

that's ever evolving, number one. Number two, you should always go in and do the hard stuff because that'll help you learn, right? You know, debugging the hard things, like go online, look at Stack Overflow, look at some of the discussions there, find some sample code from some person's GitHub, take it down, look at it, and then try to figure out

why this discussion was happening by looking at all the commits, right? You know, find some of these and be like, oh, look, you know, I wasn't getting a return value because of this or I wasn't implementing a function correctly because of this. And somebody gives a good explanation to Stack Overflow. I learned a lot of that, you know, like in the early 2000s when Stack Overflow was like starting up and all this kind of stuff in those discussion forums. And I learned a lot by screwing up. Yeah, I think there's like you bring up some great points. I mean, a lot by by screwing up yeah i think there's like you you bring up some great point i mean a lot to dig in there we will just ignore all of it and move to

our next topic but i mean i'm gonna say i'm like sorry i know that was a lot to throw at you but you know what i mean it's great i think what what i'll counterbalance there and i think you did it you you kind of mentioned it like do the hard parts where i think sometimes early in a career people say i try this technology i don't want to just move the next one, move the next one, move the next one. And it's not what you're saying. You're not telling people. I don't hear you telling people,

like try something if you don't like it, just move to the next flavor of the day, framework of the month, whatever it is. And just keep, you're never getting work done in your code base. You're just rolling your code base around through some weird search of the space. You're not saying that you're

saying get good at something do the hard parts but at the same time don't say i've found something that works nothing better could ever be invented exactly and that's actually one of the problems with don't get me wrong like i said i work with all different types of technologies i do a lot of our public speaking right i'm fortunate enough now, like I said, it's funny is that like I found the place where I feel like I can take all the garbage that I have in my brain and have an outlet for it that's constructive.

You know, like, you know, be able to, you know, talk about things like I love talking. It sounds ridiculous when I say it out loud now. You know, like one of the things I think we're having this discussion about was like software supply chain, right? You know, what is software supply chain? People ask this all the time. Meanwhile, it's the most systemic problem in the industry right now, right? So, you know, software supply chain is all the things that you use to build the stuff that

you build as a developer, right? You know, 85 to 90% of all code is someone else's code that you don't know. I always say this when I give my talks and I mean it wholeheartedly coming from my life, which is I always say, look, developers are artisans. They're, you know, they're artists. They really are, you know, right? You know what their medium is, whatever, you know, is programming, right?

And whatever language they use, you know, instead of it being, you know, instead of being titanium white, you know, it would is whatever you know is programming right and whatever language they use you know instead of it being you know instead of being titanium white you know would be some titanium white oh wow that was very that was very specific yes but right but you know what you know what i mean like you look at a situation you you you assess the situation and if you're fortunate enough to have a you know start something you can choose the technology you feel best way or either way you feel comfortable with or feel is best for the appropriate thing you're trying to solve or you go into a situation where the product's already built and you work with the technology stack or whatever but the thing is software supply chain is all the stuff you utilize right so that that medium and the thing, is that one of my favorite quotes,

and I use it in all my talks, is that like, why are you so passionate about protecting software supply chain? I'm like, number one, a lot of the customers I deal with are, I'm a customer of theirs. So yeah, I want to make sure that my experience is good and make sure my data is secure. My banking materials are good. You know what I mean? And I'm not alone. I want to make sure that my experience is good and make sure my data is secure. My banking materials are good. You know what I mean? Like I'm doing it and I'm not alone. I want to help in that respect. Because basically the thing was it came from Dan Lornick.

And what he said was, is that every time you pip install, go get Maven Fetch, it's something you do with is the equivalent of plugging a thumb drive you found in the gutter into your production server. Right. It's true. Because the thing is, let's see, you know, the thing is, is that how do you not squash the ability for developers to really develop, be artists? You know, I mean, their code is crap. I mean, think about it. I mean, building an algorithm is no different than building, you know, something structurally or creating a sculpture, right? You're molding, you're malleating, you know, things. But at the same time, how do you ensure that you're not using lead paint, that you're not using tainted clay, you know, that might have some sort of latent E. coli because you're like, oh, I got some Mayan mud that I'm going to go build something with. And they're like, yeah, sure. I found it here. Use it.

And it's containing something. Right. And so my thing is, is that like what we're doing at my, you know, the company I work with, Janefrog, is that we're trying to protect that. But at the same time, stop the hindrance of, you know, doing it behind the scenes, ensuring that those third-party transitive dependencies, because that's what they are, right? I need to parcel.

I mean, you guys are programmers, right? I want to parse a string, and I want to find a particular value in that string. I'm using the most basic example, right? I could go in there and write a regular expression thing that goes in and says, hey, tear this apart, look for it. Or maybe I have to do something special with it. Maybe I have to encode it.

I have to encode it a specific way for some reason. Yeah. And I'm using Python. I'm going to go out and look for a Python library that maybe says input is a string, output is a blah. And I go, hey, that's great. It saves you time. And I go, hey, that's great. You just, you know, right? It saves you time. And I'm going to use it. Now, the thing is, is that in this world today, the problem is, is that that software supply chain, and the reason why you hear about it so much is the fact that

those transitive dependencies, you don't know where they're coming from. But at the same time, you still want to have that naive approach to solving a problem. And you don't want to think that the world is a terrible place, right? You know, you try to keep optimistic. But just give you an idea. In 2021, there was a 650% increase in supply chain tax alone. And it went up 40% last year. Think about that. 85% to 90% of the things that you rely on as a developer can be potentially nefarious or malicious. And we're not just talking nice, you know, like, ha, ha, ha, funny hack thing. You know, we're talking detrimental. I mean, the one that everybody always talks about and the example I always about, because it was $100 billion remediation globally, it was 18,000 customers, including the DOD, DHS, Federal Reserve, you name it, right, was, of course, SolarWinds. Now with SolarWinds, that was, I'm sure you guys did a podcast on that at some point, or maybe or not, I don't know. But that was actually a fourth level transit dependency, right? It was a fourth level, I don't know. But that was actually a fourth level transitive dependency,

right? It was a fourth level, actually indirect transitive dependency. Okay. So I'll double click. Can you maybe, so transitive dependency, you dropped it a couple of times. Maybe just take one step and just let folks know so they can follow along with, what do you mean by a transitive dependency? Oh, sorry. Sorry. Yeah, sure. No, you're good. You're good. So anytime you're programming and you choose? Whether it's C, right? And you're using a header file and you're pointing to a library, right? That library you might use or Python or NPM, right? You get a node module. Those are libraries. Libraries are dependencies, things that you depend on to do your code, right? Like I said, 85 to 90% of code you write have dependencies. That's what they are.

And then a transitive dependency is you have implicit or direct, which you state that you want to use this library. But those libraries that you're utilizing, right, those dependencies you're using have dependencies. And those dependencies have dependencies, thus it's transitive, right? It goes down the stack. And the thing is, you have implicit, like I said, or direct, which is the ones you usually put in your code. Like if you're doing NPM, it's package.json, right? You put your dependencies in,

you put in your specific versions or wildcard versions or whatever. You should never use wildcard versions. Please stop using wildcard versions. Just saying. It's like, you should also be using Docker. Please erase the word latest from your head. Stop it now. Anyway, that's a whole other digression right there. But the thing is, is those dependencies are the threat, right? They're the threat. You know, I always equate it to is the

idea of like a, you know, I wouldn't say like a Trojan horse per se, but picture you're in a castle. You're protecting your castle and your citizens and you're having a good time, right? Suddenly a horde of angry invaders comes from the east and from the west. Oh, I'm starting to sound like the Lord of the Rings here, right? They're coming in, you know, they're coming over the hills and all this stuff, right? And suddenly somebody goes, hey, you know what? It might be easier if we just open the door, right? Let them in. What's the worst that could happen, right? Because basically what you're doing is, is that, you know, some of them are friends, some of them are foes, some of them you don't know, right? These dependencies, and you're basically, you're letting them in to your company, right?

And it's not just a destroyer of potential lost revenue. The biggest threats are actually reputation, right? Are you really gonna go work with a company, again, that just took all your data and shipped it off somewhere and put it on the black market, right? Or are you gonna go with one that's a little more secure, right, that you don't read bad headlines about. And the thing is, is that the threat model is insane. I mean, to give you an idea, in security land, when it comes to transitive dependencies,

right? When it comes to threat models, there's a thing called a zero day, right? Everybody hears about the zero day, meaning that is the moment that that issue became an issue. That's the threat, right? Zero day. It's start, you know, you know, I always have to explain to some people. I'm like, when you count in programming, you always start off with zero, one, two, three, right? You always start with zero, right? Like whenever I describe things, I always start with zero.

So thus zero day, right? And then it goes up from there. And when zero, you know, the thing is, is that since 2021, 40% of the zero day exploits of all time have happened. Think about that. And it's done by volume, just a sheer number of actual issues in this kind of third party space, right? These transitive dependencies, the things you don't know. And the thing is, is that when this happens, how do you protect your organization? How do you protect yourself? How do you do it in such a way that you're not squashing your developers' ability to create? You know, because you don't want them to be hindered, but you can do it in a way that's actually productive. And like, we try

to do that as a company. That's one of the things that we do. Like we provide IDE tools to say, hey, you know, that library you're using is potential threat, is a potential threat. And, you know, we're a CNA. We're actually a CVE member authority. We actually have a giant research team that does this stuff. And I'm so happy about that. Like I said, I take this very personally. I think it's, and I love the ability for me to go out there and work with the organizations, to stand on stage, to do webinars, to talk here, and be able to say, you know what? You can still do what you do, but you can do it safely. You can do it securely. You can do it in a way that can also be preventative. And that's one of the

things, like we just released a new feature to me that is fantastic. One of the biggest things is companies spend millions of dollars on basically trying to remove these threats, right? And the thing is, is that, put it this way, for every threat that you detect in one of these transitive dependencies, you're detracting from the developer's ability to go in and develop, right? You're now doing a threat assessment model instead of an innovative model, right? Like I always joke around. I was like, wouldn't you rather, you know, we're doing a campaign now I'm working on called Innovate More, Remediate Less. The thing is, is that we actually can go in there and tell the developer, the security person or whatever, that this CVE, which is a CVE, just so you know, is actually the assessment of a library in terms of threat, right? So there's

low, medium, high and critical. Critical, of course, means that you should burn it, burn it, burn it. Log4j, right? And we'll talk about that in a minute, if you guys don't mind, because that one's always hilarious because there was things that were leading up to it that everybody ignored, right? The thing is, is that being able to pinpoint them and act on them quickly saves them the ability for time to, okay, address the issue, go back to my KPIs. Like, where do I have to release this sprint, right? Yeah, so let me just dig into a couple of things there. So I think you've mentioned this,

and I find this very interesting. And I guess not everybody realizes it. Someone told me long ago, I have no clue who, but this way that you're sort of speaking, I'll use an analogy to talk about lawyers the same way. People will say, hey, we're at a company and we're trying to figure out whether we can do this. So we're going to go talk to the lawyers. Maybe I don't mean to demean other people or say maybe everyone knows this, but I didn't. And it was an educational experience to me the first time I sort of worked with it this way. The lawyer's job is to tell you no. The lawyer is just going to say the safest thing for you to do to not have legal risk is don't do whatever you're asking. It doesn't matter if it's literally the business case. It doesn't matter. They would just say the safest thing is for you to shut your business down and not do it anymore.

Okay. Well, thank you. That's not helpful. Okay. So what is it? And it's your sort of job as a person looking for legal feedback to go to the lawyers and say, well, what are my risks? And then you need to own those risks. Now they may tell you, I guess you were sort of alluding to this. Your risk is that the department of Justice is going to knock down your door with the SWAT team and haul you off to prison because this is a felony. Don't do those things. Other things are going to say, well, there is a chance that someone could get hurt. And you say, well, okay, well, I'm going to counter that by going getting liability insurance or designing a safer product or documenting, right? There's this

balance and counterbalance, but going to a lawyer whose job it is to tell you the risks, they're going to tell you risks. And so I think this is this balance that you're speaking about, which is the safest code is do not write code. Well, maybe not, but it's have no code at all. Okay, but we can't do that, right? Like we want to write some code. And so balancing these things out. And as you point out, there are libraries that are extraordinarily helpful, the open source stuff just can't be ignored anymore. And lots of companies tried to, and I think all of them have given up at this point. And so there are many companies that want to ignore these things. But it is very difficult because you pick it even if you did an audit, even if you reviewed line by

line. And even if you were capable of detecting a bug, you use latest. And that doesn't mean that next month, they don't add a new dependency, or they don't change what they're doing, right? This is a very subtle, but difficult, like, environment. Yeah, but let me unpack that, right? So there's a couple of things, right? So let's talk about the legal side first, right? There's there's a couple of different functions here in terms of legal that you have to be cognitively aware of, right? There's, of course, the greater one, which is protection, ethical, and those kind of questions, right? Take it from somebody, you know, I think earlier on, we were kind of before this started, we were talking a little bit like chappy GPT, right? Before I joined JFrog, I actually had a startup where we actually built something very akin.

I still have all the code in my source code, by the way. And we actually had I had an office in San Francisco, had a bunch of my friends. And I we built an ad based AI engine. Right. And I'll tell you right now, I had a hard time. Five. This is six years ago, almost seven years ago. Hard time getting funding because it was too creepy. Oh, that was that was the exact that was the exact words from what was and i was in the vc space and these are friends of mine who were like love what you're doing this is pretty awesome but god i'm gonna do a hard pass uh this seems a

little bit almost borderline unethical and i had to think about interesting okay i was kind of hurt uh basically what it was is it was i won't say what technologies helped us at this but there was a point where i was i was able to take messages 1200 characters you know 1200 words from a customer from a consumer and construct it with my algorithm construct a media campaign around them specifically targeted towards them based on their exact who they are oh okay like their likes their dislikes favorite colors things like that but do it in a way that was very it was yeah and i admit looking back now yeah it might have been like might have been might have been a little much i also might have harnessed the power of watson at one point to kind of help me parse through this data faster. But that's neither here nor there. That's one aspect of it. I had to do a lot of legal talks. I had to do a lot of ethical talks around this. Then there's the next side of this, financial and reputation. They're kind of hand in hand. Your reputation is strong. Your revenue should be strong. Your reputation is strong. Your revenue should be strong, right?

Your reputation is low. Your revenue will be low, right? There's a very interesting symbiosis between the two. That's a hard balance to maintain, right? It's kind of like we were talking about, you know, we were talking about Star Wars, right? We were talking about it earlier, right? The whole idea, you know, light side, dark side, the balance between.

I always consider the legal dark side. Sorry to all my lawyer friends. Anyway, but like this whole, come to me. You know, I am your lawyer. No, it's, but, you know, the thing is, is that there's that side of it too. And then there's the last side of this, right? Which is the programmatic side. Now let's talk about the programmatic side.

Now, protection, right? So as an organization, like I said, how do I ensure? And safety. And now legal also has the aspect of things like license, compliance, and governance, right? And most companies in the past, especially when you get into certain industries, they take the air-gapped approach, right? You know what? Let's sit in our enclosed castle, let's lift the drawbridge and ice ourselves from the world. If anybody has learned that over time, especially in the more medieval Dark Ages model, it doesn't usually bode well, right? At a certain inflection point, the sheer consumption of the people inside the castle are going to outgrow the resources in which they've actually done, right? You're going to have to leave the castle. Well, companies for a long time,

specifically, of course, and with purpose, I mean, there's a reason why Amazon GovCloud and Azure Gov and all those kind of exist, right? Those isolated environments. But a lot of companies took the approach is, if I can't control the influx, I might as well just shut it off. And I'll put in these antiquated models where my developers have to request the libraries that they want to use, right? And you also hit the nail on the head with that too. You said, what if there's a new version available, right? Maybe there's inadequacies in the library I'm using. Maybe there's a bug, or maybe the function I call returns only two parameters and two values. And now the new one I need has three. You know what I mean?

Little things like that. Well, how do you keep up to date in those kind of level environments? You really can't, right? You really can't. It's almost impossible. Like we're actually going to be introducing something. I already got a legal talk from my marketing team and everything. I have a tendency to get really excited about the things that we're doing, and I can't wait to talk about them.

But I will talk about what you can currently do. And the thing is that, let's put it this way. Any organization that looks to find these components, these potential threats, nefarious components, you know, things in their software, if they find it in production, is 100 times more expensive to fix it than where it matters most. And I'm sure you guys have talked about this, and the concept they already calls it shift left, right? Which is, how do you, if you really want to combat this scourge, you know, that's really, it's really a thing. You need to put the weaponry, right? The tool sets, the fortifications, where it matters most, the people where it matters most, which is the developer, right? The developer needs not to be scolded, not seriously, not to be scolded, not to be, you know, shamed and all that, but given information.

We work in the information trade, right? I mean, think about as a developer, what are you doing? You're manipulating information. It's what you're doing. Input and output. In its simplest sense, you know, you're building tools to manipulate information or analyze information and produce results too. Once again, manipulating information. By putting the tool sets that matter, which is informative, like static code analysis, show me where my algorithm could potentially cause a threat or an issue or a race condition at worse.

Everybody's like, oh, it's intrusions. I'm like, no, dude, race conditions are more detrimental than anything you could, because once they start, can't stop, right? It's like, you know, it's like, it's like a perpetual motion machine. You can also, but the thing is, is like, there's that aspect, right? But the thing is, is that by giving the tool sets, even down to the libraries, we do this. We actually have ID plugins where we show exactly where it's happening. We're actually like, here's a library. Here's all the potential. And CVE, just for anybody who knows, basically that's the numeric system they use to actually number value, well, label issues, right?

Potential threats or issues in the software supply chain stack, those libraries. Anyway, by pretending that information, and we actually have a part of our product, we're the only, by the way, our product, I will say, like I said, I know I'm boasting a little bit here, but it's freaking phenomenal. I'm sorry, I'm watching my language. I know we have the clean tag, but the whole thing is, is that we provide contextual analysis. Is the threat, right? Now, the threats are usually isolated to a particular function most of the time, right? And a library can have hundreds or thousands, you know, I wouldn't say thousands, but hundreds of functions, you know, sometimes, right?

You know, do this, do that. Now, if you take a library and there Right. And that's a problem. That is a systemic problem, because in most cases we get back to the idea of of air gapping. Right. Or the moat around the castle. Right. Once again, you're just you're not fixing the problem. You're not identifying the problem per se. You're just you're treating it like my repressed feelings. Right. Very deep inside. And where does that go? I don't know. I'll unpack it later. I'm just going to bury that deep inside. Wait, this isn't that podcast? No, I'm just kidding. It started back when I was a kid. No, no, no. Sorry. Anyway, but you know what I mean, right? So we're providing tool sets now with our advanced features that says, hey, by the way,

this library is a potential threat. It could be a critical, right? Meaning that everybody should be hands on deck. But you know what? Contextually, you're actually not affected by this because you're not using that function. Interesting. So we actually provide the information now. Is it applicable or is it not applicable? Perfect example that I always love to talk about is, like I said, I love teaching. I love helping improve experience.

I love removing the minutia of things to help people do what they do. And I had a guy last year. I asked him, you know, in part of the discussion we were having, it was like a group discussion. And I, and he said, you know, what's the worst part of what you do as a security analyst is a security analyst, right? This is his job is to be that person. It's like, I always equate it to like, I feel so bad for most security people. It's like, you always watch those cop shows. They're like, oh, we're to get internal affairs involved. Right. And then they're like, oh, those guys security people. It's like you always watch those cop shows. They're like, oh, we're going to get internal affairs involved.

And then they're like, oh, those guys. That's what I always feel like. I feel like these poor security guys. They're like internal affairs. They're like the internal cops to make sure. And the thing is, is that when you think about this and you look at it, it's like the guy said to me, he's like, look, he's like, that's not the worst part. He's like, the worst part is, is when something does happen. Now, in most companies, it takes about 26 days, by the way, for companies usually to identify these CVEs and, you know,

the effectiveness, like we provide a blast radius, like if you find a library, because of the way we store these transitive dependencies, we can actually associate them to the build. So if I look at a transitive dependency, I can say, here's all the builds it's associated to. But he said to me, he's like, root cause analysis reports are my hell, is the way he said to me. He's like, where I have to go in and I need to go ahead and take a look at what happened and diagnose. And I said, well, what's the biggest pain point you run into? And he's like, the biggest pain point I run into is basically the effective radius of something that happened. How much did it affect or how long were we potentially exposed? Remember we talked about solar winds before? What made solar winds so dangerous dangerous was is that when it went in and affected 18,000 customers,

the actual issue didn't happen for 14 days. It actually had a timer that when the software started, it waited for 14 days in wait before it did its attack, right? So the thing is, is that there's a 14-day window in that time period where you have to go investigate what happened. Or if you're developing and you find a library like Log4J, let's talk about that, right? Log4J, one of the most used libraries in the entire Java spectrum, right? Everybody pretty much uses Log4J. Suddenly, yesterday, it was my new friend I've had forever. We go back way back when, right? And now today, it was my new friend I've had forever. We go back way

back when, right? And now today, it's the most evil thing on the planet. Just so you know, by the way, CVEs, these numeric values, when that came out, when that zero day came out, one of the things was is people were like, oh my god, this is happening, right? Well, you know what? They were actually for weeks and weeks sending out info and warnings on this. Why? Because a CVE doesn't happen overnight. Right. It gets found. It gets validated. It's just scientific method. Right. You have a hypothesis of why this is happening. You need to put the information in. You need to get peer reviewed. Right. You don't just push a CVE out there and go yep there we go that thing's evil and somebody

goes i didn't find that right so we're going back is is that saying is is that providing the right context right tool sets the proper way to do this is at the developer level and then the build level right you kind of go through and if you follow your sdlc right your software development life cycle you should actually have it at every phase, dev, QA, staging, production, right? Wherever these binaries are living, you should always have some level of security. But if you want the greatest investment in your company to help fix things, you put it at the developer level. They're the closest to it. It's where it matters most.

Stop it before it begins. Or like what we do is actually you could even pre-evaluate those binaries before they get in their hands to make sure that they're not even starting to use this, right? It's amazing. The threat levels that are out there right now are insane. It really blows my mind. You know, there's a morbid curiosity behind it at the same time, almost an embarrassment. that was a real long explanation but i kind of wanted to like give some context no no no no i think it's good but let's use that to parlay it here as we as we sort of get onto the the tail end and say okay so you we've talked a little about the the problem the setup i feel like we we got it now like yeah this is this is a problem

we want the developers to fix it what is the actual mechanism and specifics that you guys are using? So a developer wants to build some software. It sounds like you need some mechanism where the platform understands what versions of what dependencies are being used. Walk us through a little bit about just sort of how that all works. Sure, sure. I mean, like I said, I work for JFrog, right? And our product is Artifactory. I always joke around with the biggest little name that we're everywhere, like I said, I work for JFrog, right? And our product is Artifactory. You know, I always joke around with the biggest little name, you know, that we're everywhere. But everybody goes, I go, I work for JFrog. And they're like, huh? And they go, oh, Artifactory.

Like, oh, we use you guys. I'm like, yeah, we have over 7,000 corporations globally, right? We have almost 100% of the Fortune 100, top 10 banks. I mean, you name it, you know, we're there, right? I mean, everything from software, you know, we're there, right? I mean, everything from software development to software deployments. I mean, automobiles, space things, right? You know, like, I'm like, I love that. Like, I actually got a tour of a facility, a manufacturing facility once because we were helping them. And the whole time being a nerd, I was like, yeah.

I was like, let me taste the rockets. Can I put my arms around it? Can I take this one home? You won't miss it. You know, the thing is, is that, you know, with us, with Artifactory, we manage those transitive dependencies, those implicit and, you know, and those direct and implicit dependencies and also to the, you know, the ones that come along for the ride. You know, when we talk about dependencies, I always, my favorite analogy that I always like to use, especially is like NPM. NPM is the most notorious, right? along for the ride. When we talk about dependencies, my favorite analogy that I usually like

to use, especially is like NPM. NPM is the most notorious, right? With NPM, you put three, I call it the house party. You put three things in your package.json and 500 show up, right? And you don't know those 500, they're just there, right? That's just what happens, right? Because those dependencies have dependencies, right? It's the most notorious. I mean, just to give you an idea, in our database of CVEs and potential threats, we actually have over 16,000 threats from NPM alone. Just NPM. Think about that. Anyway, but the thing is, is that we manage that.

But we also manage the builds you produce, right? So the things that you create, and we have over 32 package types, right? Whether it's like Docker images and Helm, like we're actually governance board members of the Cloud Native Foundation. Actually, the guy who co-created Helm is actually a JFrog person, right? He's actually at our company for like Kubernetes and stuff. So it's like we're doing web services and device management with our Connect product, you know, whatever it is, we have the stack to manage it. And so for us, we have our X-Ray product. Now, our X-Ray product is actually, the thing is, is if you're not familiar, though, and

this, I just got to explain this, is that we, you know, you hear about CI, right? Continuous integration or CD or continuous development, you know, continuous distribution or deployment, whatever you want to say, right? It's just kind of throw, you know, I've heard development, I mean, I've heard deployment, I've heard distribution, you know, I mean, whatever. I mean, I've heard deployment, I've heard distribution, you know, whatever, you know, we talk about CS, continuous security. And the reason why I say it's continuous is if you're not familiar with the way that we store binary, you know, binaries, we say binaries, we're really, they're just software package types, right? Whether it's a JPEG or it's a Docker image or a jar file or whatever. And we tear them apart

and we actually index them into a database, right? We store them as a checksum, a SHA-256. And this allows for things like speed and efficiency. So in our product, you're actually interacting with the metadata level. And the metadata has a representative context of the actual binary, the library you're using, right? And that library and all its friends that you're using,

we use that information for security evaluation. So instead of it being a physical evaluation of a binary or a library or anything that most products do, ours is a metadata representation. So it's a metadata to metadata comparison that you can use. And thus it's continuous, right? Because you can constantly keep it going. You're not going to constantly want to upload things to a evaluation. So we're doing metadata to metadata. So it's a constant thing. Thus, the reason why I talk about zero day.

When a new zero day happens, we can immediately notify you that's something terrible, that you're a terrible bad person and that you should fix your mess. No, I'm just kidding. But you know what I mean. But the thing is, is that we're doing our best to do that right so we're doing deep inherent scans of all the dependencies too i mean going through docker containers docker containers are my favorite thing you know what they're the biggest hot mess in the world can't live with them can't live without them right you know i'm a big believer and you know we'll go back

you know i am a 12 factor zealot um when it comes to like this kind of stuff right i don't know if you've never used 12 factorfactor methodology, right? But 12-factor, everybody goes check that out. It's 12factor.org. But the idea of it is that, you know, you develop against a Docker image that has a representative runtime that you would have in your production, right? So you remove that whole, what works on my machine, right? That's the whole thing. But Docker's a hot mess, right?

I mean, let's look at it. It's a black box most of the time, right? That's the whole thing. But Docker is a hot mess, right? I mean, let's look at it. It's a black box most of the time, right? You know, you have a base level OS that could be whatever, whatever. It could be busy box, it could be sent OS, it could be Red Hat base, Windows base, whatever. Then you have a series of runtimes, right? That, you know, you use for whatever you're doing, whether you're deploying an application or you're developing an application. Then you have an application layer, right? Where all your stuff lives, right? All that, you know, that stuff that depends on all the other stuff, you know, and remember we talked about, I talked

about the fact that, you know, security threats are based on these third, you know, third party trends, not just libraries, Docker images, and they're not safe either, by the way, you know, we also look for things in our security product like secrets. I actually tested our product with a whole bunch of random Docker images I grabbed off a Docker hub and did deep build the content. Do you know how many API keys, AWS keys, GCP keys that I found buried in these that still work? And the best part was is where I found them. You know where I found buried in these that still work. And the best part was, is where I found them. You know where I found them? Everybody's really good, by the way.

Most people are really good about going through their directory structures and pulling out all that information, right? Oh, I don't want to leave my API key there. Somebody might get it, right? Yeah, well, you might want to check your history. Because if you go into any of these Docker images and you go into the user and you go into the dot history, you can see all the API keys ever used and nobody ever.

So we find these or my favorite one is I downloaded one. I typed in the simple words Docker and Google, right? Docker, Python host host, right? And I found this one container and it said top rated container. You know, everybody's like, works great. It's super small, blah, blah, blah. I downloaded it, decided to pass it through our system.

And I found a service that said, when this starts up and you put this information, a particular code, like, you know, you you're executing with Python, do me a favor. It's going to create a TLS connection to somewhere out in the world and send it all my log files. Oh, what could go wrong? What could go wrong? What could go wrong?

And this is a number one download. This is like a number one approved, downloaded, hosting Python container. So, yeah. And I guess maybe for folks who are, I guess, playing along at home or not familiar. I mean, this is one of the things that people talk about with Docker is it's not just you mentioned zero day exploits or someone introduces a race condition in Postgres or just whatever. Right. And you're screening for that version of that Docker image being in someone else's Docker image being in your Docker, right? It's sort of the transitive thing. But I think the other thing that's popped up recently has been where someone gets a hold of your credentials for uploading an image or uploading to your repository, and

they do one of these things, right? So it's not just, there's like the spread of things is very large from accidental introductions of security bugs to a long-term contributor secretly being there for the sole purpose of inserting a very subtle, very well-crafted bug, which is a very scary thing to think about, or someone hijacking credentials

and you're pulling latest. Overnight, someone changed it to a Bitcoin miner instead of running a Postgres host or whatever. And all of a sudden you deploy it. Right. You actually touched on a very, very interesting thing here, actually. Right. You know, we talked you just talked about it. Right. You know, pulling, you know, you're pulling down these dependencies. Right. And those are ever evolving too, right? Those are constantly changing in addition to that. So always being a security aware of that threat level is very important.

But the thing is too, and I want to ensure, yes, I am talking very doom and gloom scenario stuff here, right? I mean i mean think about this i mean just give you an idea like in 2021 right i love i love like stats and all these kind of things right exploits used to take around 40 something days i think it was like 42 or 43 days to be like recognized it is before 2020 actually and stuff it's now down to 12 days. And the thing is, the reason why is that these third-party transitive dependency models that are threats, why are they so easy? Well, number one,

it doesn't take a lot of, by the way, it doesn't take a lot of very good, you know, a lot of tremendous technical know-how. You don't have to be an elite coder to do this stuff. Right? Number one. Number two, it spreads very rapidly. And the thing is, the reason why is it's something we don't want to stop, but at the same time also causes a

problem, which is the open source community. I'm a huge open source person. I've been doing this forever, right? And we're very accepting as part of the open source community, but also at the same time, as anybody knows with any community, it's very easily, it can be easily pulled in on savory elements, including the various people, right, who are looking for either bounties, you know, financially, or just want to watch the world burn, right? You know, like that whole Joker thing, right? They just want, you know, they're not there for the money. They're not there for the recognition. They just want to watch the world burn. But because because they once they get into these

communities they can go in and you know a lot of them wait they wait for a time i mean by the way when like solar ones happened it was like i said like it was like a fourth level transitive dependency that came along for the ride by a fix that was done to a library right and? And this thing served no purpose except for that, but people are like, oh, it must be just another dependency this person used in one of the other libraries, so just come on in, right? And the thing is, is that that's actually one of the biggest threats, but you don't want to stop that.

That's the problem is, is like, that model, you want to still encourage people to be part of a community. You know what I mean? One of the things that really always I loved about this was that it was that tribalism of being able to go in and work on something together. I mean, look at NPM. When NPM started, I always loved what I was talking about. I started off with the NPM community in its infancy in the mid-aughts. Back then, it was like, oh, this is amazing.

At one point, I worked for a company called Aptana. And we were working on ID open source stuff and things like that. So I became part of this community. And when I was going in, I was like, this is fascinating. Back then we had the same kind of idea of like server side and client side JavaScript. Wouldn't that be awesome? And then all of a sudden MPN came about. We're like, oh, let's abandon that and let's go focus on this. Let's help out there. Let's take what we learned, right? And I love that. It's like, you know, and for me, now that's kind of translated into me working with companies to say,

look, you're not alone, number one. It's threat is terrible, but if you have the right tools, you have the right things to do what you do, the right education, right? The right, you know, that slight bit of paranoia, but that's still semblance of being a wonderment that you have as a developer right because you don't want to squash that right i

mean innovation is not it's a you know people talk about you know software like i said i talk about artists they are you know software are developers are artists you know they develop algorithms that do things they do magic they create things right it's one of the last true mediums in the world in my opinion that still is still a big huge green field don't get me wrong we can always talk about chat cpt and all that stuff later on one other time because i've had mixed results with that but at the same time it's like it's one of these things it's like you want to encourage it but you also want to make sure you have the right safety gates but not enough of a safety gate where people start to freak out.

You know what I mean? You don't want to be overly oppressive, but you want to be at least have monitors that let you know. Yeah. I mean, this is, I mean, I feel like there's been this narrative through the whole episode. Just this balance that everything is this sort of balance between, between both sides. Yeah. Wow. Wax on, wax off.

Okay. Sure. Come on. I'm going down the Karate Kid path now. Yeah, wow. Wax on, wax off. Okay, sure. Come on, I'm going down the Karate Kid path now. Yeah, I'm trying not to get distracted. So, okay, in kind of, I guess, conclusion, I imagine there's sort of a couple of different groups out there. There's people out here listening

to the show saying, oh, yeah, yeah, I know what this is. This is great. This has been exciting. I'm familiar. I got Artifactory. I got my stuff tracked. I'm up and up. I love it. Then there's people who are sort of in this space. They are hearing and being aware of this problem, right? Like, you know, they're kind of pumped. They're sort of sold. They got the pitch. They got the message. They're excited about it. And then the third group, I guess, for people who either, I'm not going to say they don't have their problem. Maybe they're not aware they don't have their problem yet, or this isn't where their space is, or they're a student, or they're early in this field.

What would you sort of, you know, is there a way for them to sort of like start thinking about these problems, getting experience? Maybe the tool isn't really targeted at them. Is there like something we could kind of like tell to those folks who maybe don't know they don't know? Oh, absolutely. Like our stuff, right? I mean, like I said, there's tons of companies that use us. I mean, and so it's not like, you know, if you wanted to, like we have our academy. I would also look, we have a like research.jfrog.com. It's our open research page that we actually open up to talk about what we're talking about in terms of security. Like I mentioned, we are a CNA, we are a CNA.

We are a CVE member authority. There's not many of us in the world. There's actually, I think there's like 81 companies in total in the world that can produce CVEs. So basically, look at this. We're part of the peer review process that I talked about before. Take a look at that. I mean, look at things like Hacker News. Look at things like Stack Overflow.

I mean, the list can go on and on. In terms of getting involved you know like with our stuff that's easy like i said we have some stuff if you're a student we have some open source versions of things just go to jfrog also to anyone to reach you know if you anyone wants to reach out to me it's just william manning uh it's my twitter handle once again early you know early adopter catches the uh the best handles you know and it's like i think i'm gonna make that a thing now, by the way, who cares about the worm, worms don't matter anymore. No, I'm just kidding. Anyway. But,

you know, the thing is, is that I think it's one of these things that learn, learn, learn the best practices. You know, when you look at a language, don't just look at the semantics of it. Don't just look at what you get. With more of like, here's how you create a function. Here's how you inherit things. That kind of stuff. Also, dive into medium articles. Look at the community.

Look for insight into these. Look to your peers in these know, in these kind of, you know, various language types and fields and whatnot, because adhering to, you know, working with best practices is the first thing I tell people, right? You know, stay naive, stay hungry, you know, that whole thing, right? But on the other side, you know, on the other side of it is also to, you know, have that slight level of paranoia, but without obstructing your abilities, right? And in some cases, that's getting a tool like what we provide, which, you know, provides you with, you know, it does that for you,

kind of provides you with that to say, hey, this is a potential threat, or hey, you know what, this library has a threat, but you're not affected by it, you know, or, you know, being able to, also to, you know, like I said, you know, become involved, by it, you know, or, you know, being able to, but also to, you know, like I said, you know, become involved, become involved, you know, learn, you know, discuss, talk. And in some cases I've done this before with other communities, right? Bring up a crazy topic that might be controversial, especially when it comes to a best practice that somebody might recommend. If you see that best practice actually can be done better, betterest, I'm more better.

I was getting best practice, right. You know, but become involved, you know, learn. But I said, it's not just learning the semantics.

It's just not learning the little details that make a language, a language, not learning how to organize your files, how to, you know, properly put things in, you know, we're going to,

you know, you know, specific folders and all that, whatever. That's the easy part. The hard part is a little bit of cynicism, right? Some, well, seriously, some community involvement, right? Discussion. You know, you become a, I mean, I learned a lot by working with my peers, by working

with the online community, right? Also being able to admit I was wrong, right? That's another thing, you know, it's hard. Remember, a lot of coders, a lot of people who do this, you know, they were there, you know, they were the best of something, right? Or they were like, you know what I mean? Like there's this thing and, you know, we want to be right. Everybody wants to be right.

But at the same time, it takes a humble man to per se, oh, you know what? I was wrong. You know what? This is a better approach or this is safer. Yeah, there might be a couple extra steps involved, but you're right. You're right. We should discuss this. You know what I mean?

Voting does not need to be solitary. Wow. Bill, you're teeing up those life pro tips right there at the end. This is getting deep, man. Once again, we're getting to the end of the episode and the real nuggets are getting dropped. I feel like I've just dropped a bunch of stuff. But seriously, you know what? I mean, look, yeah.

Did I mention earlier on that? I think we talked. It was like my happiest time sometimes is when I get my headphones on. I'm in my shell or my IDE working on an issue. But the thing is, to get to that point, I need to be in a room with other people or be in a Zoom or whatever, flushing things out. And then being like, ready, and break. There's all those sports analogies you could throw in. Or if you're somebody who plays Escape from Tarkov or one of those, there might be some team action play involved.

You know what I mean? Your X-Wing squadron. Yeah, yeah, yeah. There you go. What do you have all up? You know what I mean, right? So the thing is it's not solitary. And the thing is that actually all the most successful programmers that I know who have gone on to, like I said, I'm the old dude, that have had successful, fruitful careers in engineering have, number one, always adapted and changed.

Secondly, always been involved, right, in the community in some aspect. You know, I'm not a natural speaker when it comes to this stuff, right? Like, people are like, oh, you do so awesome when you get on stage. Come see me sometimes when I'm behind stage and I'm almost vomiting and hyperventilating before I get, I have like debilitating stage fright before I go out on stage and do these kind of talks. But I get past them. But the thing is, is that I'm out there. And the thing is, is that I think if we get involved as a community, a lot of these things can be resolved through just working together on this stuff.

Can't we all just get along? No, I'm just kidding. I was like, you know, but you know what I mean, right? It's just, it happens to be. And like I said, combination of people and tools. Yeah, so that's great advice. So in conclusion here, so we've talked about, I mean, all the great life advice.

We covered the basics really well. Maybe let's tee up a little. JFog as a company. Do you guys hiring, like got the pitch? How's it like to work there? Like, you know, people who are out there looking for jobs. We talked about macroeconomics. I mean, what is JFrog the company? So I've been like a professional butterfly, right? Flying the company to the company, finding the right pollen. You know, I've worked with like, I've had like three acquisitions, took one public before this.

JFrog just went public. I was, like I said, I was a mentor with like Techstars and a bunch of the other things. You know, I've done this over time. Like I've been able to share my knowledge with people too. But when it comes to JFrog, what I love about it is it's people. Actually, number one, the product and the people, right? We're actually really affecting things.

You know, like people are always like, I want to be, I want to change the world, you know? You know, like that's always the joke, right? But we people, right? We're actually really affecting things. You know, like people are always like, I want to be, I want to change the world, you know, you know, like that's always the joke, right? But we are, right? We really technically are, you know, everybody's like, like I said, we're, you know, not many people know who we are when I say J-Fraud, but they understand Artifactory. You know, what we do is we provide the foundation, right? Really, I mean, I'm about to give a talk in a couple of weeks, actually, on platform engineering, right? Everybody's like, DevOps is dead. Long live DevOps. But now people are talking about platform engineering.

It's that whole idea of natural cycles. It started off with Waterfall, went to Agile. DevOps came about when the CTO of Amazon was like, you build it, you run it. And they're like, wait, I got to learn infrastructure now. And then now it's retracting the other way. Now it's starting to go towards consolidation of tools. And actually, by the way, it's funny ising the other way right now, starting to go towards like consolidation of tools. And actually, by the way, it's funny is platform engineering is symptomatic of two things. Right. Number one, just the sheer vastness of companies being able to use as many tool sets as they want.

Learning it can be a little uncontrollable. Secondly, it's also the evolution of the recession. Right. Companies are looking to lower their OPEX and their CAPEX, right, their operational costs and things like that. I should say OPEEx, CapEx, but like capital expenditures and operational expenditures. And then, you know, what do you get for your TCO, right? And the thing is, is that, you know, that's like, okay, we have all these tools that cost a ton of money. What if we could consolidate them down, right?

And so this, and it's funny, is at the same time, like I said, the talks of platform engineering happen. It's kind of like the convergence of two things. And we provide that platform, right? We have everything from our art of factory product, manages the third-party transit dependencies and the builds you produce, right? And be able to do things like promotion, right? One of my biggest things is like 12-factor or multi-tier, it gives you the ability to

manipulate the actual atomic unit of the build, right? Whatever you produce in development should be the same thing in production. With our XTree product, we make sure that you have those third-party dependencies covered. You know, your ability to go in there and ensure safety, security, reputation, and financial stability for your organization

based on having all the proper tool sets to ensure that security, right? We have our CI product, right? We can integrate with any CI product out there, but we have our own pipelines product. It has CI, CD, and CI orchestration. What I mean is you can actually extend your current CI environments and orchestrate them, right? So you use it as an endpoint. You can either extend it or see how they're interrelated to each other. Then we have our actual distribution

product. You know, we have a lot of, you know, it's funny is the big thing I see these days is, you know, we see a lot of people moving to the cloud. I always laugh when I hear that. But we also see companies not doing what they did in the past, which is proverbially putting all their functionality or all their resources into one cloud basket. In the past, they'd be like, we're migrating from this to AWS. We see that, but we also see more companies saying, you know what? I'm going to migrate. We're going to move, you know, we're getting rid of our DCs, we're getting rid of our data centers, and we're, you know, and we're moving over to AWS, but we also want to have GCP,

just in case, in case the world burns, I want a backup, I want a backup. Or maybe Amazon works for one thing, right, with my production, but maybe I'm in APAC and maybe their coverage in APAC doesn't really qualify. So I'm going to go ahead and use maybe Azure because Azure actually has fantastic coverage in APAC compared to most, right? And so I want to use both. You know, our product line and our distribution

and our artifactory operates no matter what. It's hybrid, it's DC, self-hosted, it can be in your cloud, it can be managed by us, all these things. And so like our distribution product allows companies to distribute to either devices or to web services or whatever globally across multiple media, you know, multiple different infrastructures. And then we have our JFrog Connect. Actually, this Wednesday, I'm actually giving a talk for our IoT, which is I'm actually doing a lunch and learn globally on using our Connect product, which is our IoT platform. It's a device management system.

It's a remote diagnostics tool. It's a software updater. It has all the things of an NBM. And it integrates into the rest of our platform where you can start automating, right? Automating the software you're building and getting to your devices as rapidly as possible and roll them back and get results and all that, you know? And the thing is, is that like, there's one mantra and we literally have a book and the book is actually sitting behind me. If anybody wants to read an interesting book here, check this out. You guys can't see it if you know, there's no visuals, but it's called Liquid Software, right? I really can't see. But it's a book we wrote. And the idea is that software should flow, right? You know, release cycles have gotten smaller.

Like when I started, Waterfall was king, right? It was like two weeks of planning, six weeks of development, you know, two weeks of QA. And, you know, it compiles, ship it. You know, like that was our big joke. We even had a sign up at one of my companies that says it compiles, ship it. But the thing is, is that as the software flows increase, right, and the number of releases increase, which we see, is how do you still ensure security? Just because you're putting out smaller, more consolidated releases, in a way, you're actually more susceptible to potential threats than large monolithic deployments. So the thing is, is what we are as a company, we provide that.

Everything from shift left to ship, right. You know, now there's marketing has fun all over the place by applying labels to things, but basically it's developer to device code to cloud. I work with the military. My favorite one is compiled to combat. And you know, the thing is, is like, that's what we do. You know, we provide that, you know, everything, like I said, from like restaurants to space exploration, we're everywhere. And it's, I love it everything, like I said, from like restaurants to space exploration, we're everywhere. And it's, I love it. And like I said, I love being able to help companies be better, right? My job is not to tell them what to do, but I can be a Sherpa and help them climb that insurmountable peak on the way up and say, you're good, right? So. Thanks. This has been. This has been amazing.

So we'll have a link for sure to Liquid Code, the book you were mentioning, Liquid Software, sorry, the book you were mentioning. And, you know, as well, you mentioned your Twitter handle, so folks can check that out there. And then if anyone has any questions or comments,

I'm not offering it, Bill already offered it. Feel free to reach out to him. And it's been a blast. I mean, it's been a whirlwind tour through like your background, the topic of hand shape. I mean, it's been a whirlwind tour through like your background, the topic of hand, I mean, this has been really awesome.

Thanks for coming on the show. Guys, thanks for having me. I'm really appreciative of this. I hope this has been helpful to people out there. Sorry for some of my ramblings, but I hope that there is some, at least some little sage vice there

I could possibly give at some point. No, I think it's always great to have people who have that just wealth of background and experience and just willing to provide perspective. I think we all think this time is different and normally it turns out it's actually just the same, but a little different colored.

So this has been a great episode. Thanks for everyone for tuning in. We'll catch you next time. Thanks guys. Thank you so much. I appreciate you. Music by Eric Barndollar. Programming Throwdown is distributed under a Creative Commons Attribution Share-A-Like 2.0 license.

You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide an attribution to Patrick and I and share alike in kind.