EPISODE 1805 [INTRODUCTION] [0:00:00] ANNOUNCER: Docker Container Vulnerability Analysis involves identifying and mitigating security risks within container images. This is done to ensure that containerized applications can be securely deployed. Vulnerability Analysis can often be time-intensive, which has motivated the use of AI and ML to accelerate the process. NVIDIA Blueprints are reference workflows for Agentic and Generative AI use cases. One of the most prominent blueprints is focused on vulnerability analysis for container security. Amanda Saunders is the Director of Enterprise Generative AI Software at NVIDIA, and Allan Enemark works on NVIDIA's Morpheus Cybersecurity SDK team. Amanda and Allan join the podcast with Gregor Vand to talk about blueprints and their application to vulnerability and container security. Gregor Vand is a security-focused technologist and is the Founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk. [INTERVIEW] [0:01:22] GV: Hi, Amanda and Allan. Welcome to Software Engineering Daily. [0:01:25] AS: Great to be here. [0:01:27] GV: Yeah, great to have you both here today. We're super privileged to have you from NVIDIA, and we're going to be talking all about blueprints and obviously we'll get into what they even are, and especially in the context of security today. As we often kick off, I think we don't often get to hear from people from NVIDIA, so I'd love to hear from both of you your paths to NVIDIA and what you're doing there now. [0:01:52] AS: Absolutely. I'll kick off. My name is Amanda Saunders, and I'm the Director of Enterprise Generative AI Software here at NVIDIA. My focus is on NIM microservices, which are packaged AI models that are optimized to run on our infrastructure and blueprints. I've been at NVIDIA 10 years, so I've had roles from everything when we started with graphics through machine learning and data science, and now obviously, into one of the most exciting topics that we get to see, which is generative AI. It's been a really fun ride. [0:02:22] GV: Awesome. Al? [0:02:23] AE: Yeah. I'm Allan Enemark. I'm part of the Morpheus team here at NVIDIA, and this is the team working around cybersecurity, cybersecurity issues. Yeah, it feels a bit unreal to say it, but at NVIDIA for about seven years now. Joined on as a data viz person on Rapids, which we're still working very closely with. Yeah, actually, my original background is in design, industrial design, actually, and then meandered my way to data viz and then to more product and now cybersecurity. [0:02:56] GV: Awesome. Yeah, I mean, just before we dive in, I guess, both of you've been at NVIDIA relatively long time now. I mean, can you just describe maybe very briefly, what's it felt like to, I guess, about, I think you said 10 years ago, you've been there for 10 years. Yeah, how does that feel? Because I mean, I think from the outside looking in, it's sort of, I mean, I was quite aware of NVIDIA given, I like gaming and just keeping up with technological advancements generally. Then, I think, for most of the world, NVIDIA has only become a word that you even understand maybe one year ago, maybe two. Yeah, how's it felt from the inside? [0:03:29] AS: Yeah. I think, I mean, from the inside when I first joined, the only questions I got were about gaming, even though I've been focused on enterprise since I joined. There was a lot of, "Oh, so tell me about your gaming GPUs and things like that." Now, the questions are obviously very different. It's all about AI and it's all about what we see the future in. I think that's a very cool evolution. The other thing I would say is as somebody who's watched the work that this company has done, grow from graphics and particularly gaming graphics into AI, I think what's just really fascinating is that these building blocks, it's not like we started something totally new. It's all building on top of that original mathematics of graphics that then transitioned seamlessly into AI and again, now this generative AI wave that we're seeing. It's really fun to watch people as they see gaming go to graphics, go to machine learning, data science to where we are now, to the point where we're actually bringing that AI back into gaming. It's a full circle exercise, which I think is pretty cool. [0:04:36] GV: Yeah, that's a fun loop. Let's dive into blueprints. It's interesting, blueprints had crossed my radar from someone else in Singapore. Admittedly, I hadn't really gone in depth with them, until we were going to do this episode. The more I've got into them, I'm just more and more impressed and fascinated by what they are. Maybe, can we just talk about what are NVIDIA blueprints and I guess, why this initiative? [0:05:01] AS: Yeah. I'll jump in here on really, this was again, a journey. Everything we do here in NVIDIA, we've building software, we've been building libraries, SDKs, now microservices. All of this is to package up software that can run on our accelerated infrastructure, on our GPUs, on our networking, so that customers can get the most out of it. Developers can build these applications. As we built these building blocks, customers, developers, they were really excited. What they started to say is, well, can you show us how to use them? Can you give us recipes? Can you give us guidelines that help us as a starting point? We didn't want to build end applications. We wanted to build reference workflows, and that's what NVIDIA blueprints are. They take all the libraries, the SDKs, the microservices, even things from the open source and from the ecosystem around AI and simulation and everything like that, and it packages it up into something that can be taken, composed, customized to meet the needs of whatever companies is taking them on. I think that's really the why. Then, they're continuing to evolve to solve some of the most common use cases that we're seeing out there and bringing on new blueprints from not only NVIDIA, but also our partners to just really help people take advantage of the software as quickly as they can. [0:06:21] GV: Yeah. We're going to be diving into one of those blueprints specifically today, around vulnerability scanning. Could you also maybe just, before we do that, just what maybe some other blueprints topics that blueprints cover that come to mind? [0:06:36] AS: Yeah. I think as of recording, we have about 14 that are available. As I said, I think we introduced five at CS a couple weeks ago. We're continually adding to them. There's four main categories that we're really building these out today. The first one is AI, very common, lots of things that we see there, whether it's customer service agents, or digital humans. Obviously, as you said, the security blueprint we're going to dive into fits in there. Omniverse, which is our digital twin platform, lots of blueprints around simulation and how we can advance those use cases. BioNeMo; the healthcare marketplace is a really important one for us and we want to help those digital biology developers take advantage of all the new techniques in AI. Then the latest ones that are going to be coming out are for Isaac Group, which is our robotics platform. As we see that start to grow, again, how can we make it faster? How can we get developers started more easily? That's where we're going to start adding blueprints. [0:07:35] GV: Nice. Yeah, I mean, just to, I guess, describe if I'm looking at just the build.nvidia.com site and what does a blueprint look like? I've got three tabs here. I've got experience. Instead of actually being able to just try out what results that might come back. If I was to use this blueprint, I've got the blueprint card, which is giving me architecture. Then I've also got NIM. I am, did you say NIM, or N-I-M? How do you - [0:08:05] AS: Yeah, NIM. These are NIM microservices. They are just packaged, optimized AI models. [0:08:10] GV: Awesome. [0:08:11] AS: Again, making that run really well on our software and really easy. [0:08:14] GV: Yeah. I think we'll be talking a little bit more about NIM and which NIMs, I guess, are being used in this specific blueprint. I think, let's now dive into the one that we're talking about today, which is vulnerability scanning. Again, we've had a few episodes on in the past, just about this topic in general, usually focused on maybe a particular product. I mean, just for listeners, maybe, I don't know, maybe if we could just kick off with just simply talking very high level, what is vulnerability scanning in the first place, for those that are not familiar? [0:08:45] AE: Yeah, absolutely. Cybersecurity, broad, broad topic, lots of different areas of interest. This one in particular is around CVEs, or hum vulnerabilities and exposures. That's basically this registry, right, where if there's a known security vulnerability, it's registered there and available for everybody to look up and mitigate on their own. Now, the issue is there are so many CVEs that are registered. I think there was 40,000 last year. It's just going up every year. This is in our case, if you're trying to release secure software, it's very difficult to manage all that and keep track of it. Yet, in our case, this particular blueprint is for container security, right? If we have a container image, you're trying to release a container, you need to make sure that the CVEs, it's scanned for, or somehow mitigated, or not actually a problem. Then you have this many, you could see how it doesn't scale very well, right? If you're releasing thousands of containers, and then you have tens of thousands of CVEs, and each one is a real difficult thing to mitigate, it's hard to put out secure software. [0:09:57] GV: Yeah. This uses the microservices. It also uses, I believe, NVIDIA Morpheus, and I think that's a product, or - Could you maybe just speak to what is Morpheus in the first place? Yeah. [0:10:08] AE: Yeah. We call it cybersecurity AI SDK, which is novel in itself. Usually, when you think of cybersecurity products, it's part of some service, or some company that's providing services. What we've found to be most useful is to release this capability out as SDK, which means that you can build the tools yourself with this framework. This blueprint, like we said, is very composable. It's built using the Morpheus SDK. That is an event-driven pipeline. The reason we developed this framework in the first place is ultimately, cybersecurity is a data problem. There's so much data that it's hard to get grips on. You can't store it all. If you have stored it all, it's hard to munch through it. Really, the way we're trying to approach that problem is to use it as streaming in-line event driven. You can manage things line speed. Having GPUs enables that for the first time, because you're able to process data rapidly and quickly. Online speed and do ML on it, you can do ETL on it. That's a very modular pipeline system. As you can see, we're all kinds of capabilities through the Morpheus SDK. A while ago, back to CVEs, right? It was our own pain point, where it was our own Morpheus container and this was during the holidays or something and we got a CVE, was critical. Nobody was around because they're all on break. Whenever leads was, "All right, I'll handle this myself." He's going through it and munching through it. To do a good CVE mitigation, you have to open up the container, you have to see if the CVE is valid. You have to again go and see, all right, well, in this case, it's a version is that the versions that we're using. Sure. Okay. Then, is this an actual function call, and whatever. Long story short, hours and hours later, it turned out to be not actually a vulnerability. Because in this case, there was something with some Java runtime and we're not even using the Java runtime. But to even get to that point, you have to dig through everything. You have to be an expert in code base. At that point, he's like, there has to be a better way. Make something. You have a bunch of energy, just figure it out. That's how this whole thing started, to use this Morpheus SDK. Then we were like, okay, these LLMs at the time were starting to get really big, so we're like, well, how can we take these LLM capabilities and push it further in the cybersecurity stack? That started the prototype of what eventually became this blueprint, and which was released out to the wild world, basically. [0:12:43] GV: Yeah, the CVE problem, as you call it, it's not solved by any means in the sense that, okay, it's great that we have CVEs, that people report something that is in theory, a problem with a particular piece of software or hardware. The critical problem is knowing what is actually critical, or even moderate. There are some not exactly false positives, but there are also some there that are not really a problem for anyone, but they're still there, because yes, you have to in theory, you have to report this. [0:13:11] AE: Right. It is a very messy space, because sure, you can have tools that do the security scans for you, but the issue is they don't have access to the full context of what your software is, and what you're actually using it for, right? It's a pretty naive scan. It's like, is this version and this software there? That's what traditionally would have this security analyst, or application analyst do. Oftentimes, it's not their full-time gig. That's something they do on the side as part of some group right ever, like they meet every Tuesday. It's not something that is terribly pleasant to do, because it's not even the software that you're writing yourself, right? You just want to deliver a secure software. Then, so you have to go through all this, you have to ask the right people. Like I said, it's a very often tedious process, where you're aggregating tons of information from different sources. You have to even validate that it's a CVE. You have to ask, how is this stuff use? You have to be an expert in a lot of different domains, but then you also have to summarize a lot of information and then go out and find it. That's how we approach this problem in the first place is, hey, this workflow that this person is running for, it seems like it's something that can be automated in a sense of creating a workflow using this Morpheus and these LLMs, right? That plan, execute style LLM pipelines that we can then use to really accelerate the timeline. Because some of these, it could take a long time to figure out and just collect old information. Also, you just don't have enough people to do it and do it well. [0:14:49] AS: Yeah. I think that's what makes this such a great use case for AI. Humans do it. We don't like doing it. We're not particularly good at it, because we get bored, we get distracted, we have other things that are on our plate. By leveraging an LLM to take not all the workout, but the security analyst still has to come in at the end of the day and they have to have their expertise, but taking out the tedium that they don't need to do and doing that a lot faster and probably a lot better, to be honest, because it is an LLM, it doesn't get bored. I think that's what really helps us identify a great use case for AI. [0:15:25] GV: I completely agree. I was in a role a couple of years ago where we were building, it was a tax service management. We were looking at CVEs more from the outside, but exactly we had a person who would be tasked with trying to translate, okay, take the CVE, what's reported from the CVE, but let's try and change this into effectively natural language for the end recipient. It's got to be very contextual. This person might not be technical, so that can't be technical language. I think that's, as you've just said, Amanda, that's exactly what LLMs are fantastic for being able to be applied to. [0:15:58] AE: Yeah. It's the magic sauce for these LLMs too, is also they're able to ingest so many different types of information modalities, right? If you look at our architecture diagram, it's like, we are ingesting stuff from the actual code repository, we're ingesting stuff from the S-bomb, web searches, general documentation. I mean, it does this all stuff, but Morpheus is really good at that, but you're able to feed that all into using VDBs and good prompting and stuff like that, into something that LLMs can just digest. Usually, you'd have to even do the pre-processing back to more data analytics days to get it in a way that you could do a traditional ML, for instance, is like, that's a huge project. That's going to always break. The fluidity that these LLMs enable you to do just widens the amount of context you can feed them. You don't need that level of API specificity to make it be useful still, right? That's a superpower. From there, you can then more naturally describe tasks for it. Again, something that mimics how a person analyst-driven workflow would work, right? In our system, you have one LLM call that's setting it up to do a task list. The first thing you do is like, all right, well, I have the CVE, what are the tasks do I need to do to figure this out? Okay, well, first, I'll check the version numbers. Then second, after that, did the version numbers match? Is like, I'll do what as a deep function calls for this. After that, it's like, all right, is this actual function is the vulnerable aspects that is described in CVE, yes or no? Then, to the benefit of our systems, we can do all that in parallel, instead of CRA like a person would do, and then we make an ultimate judgment on it with a summarization. Based on all these individual tasks that these agents have gone out and concluded on and reason through through serial reasoning, are you ultimately vulnerable or not? Then present that to the security analyst as a summarized view, which is useful in an outright saying like, yeah, you are vulnerable, you aren't vulnerable for ABC reasons. We also found that super useful is generating a very big report that is the full reasoning process, and it's marked down nicely, so that they can go and verify the sources, or indicate that, oh, yeah, this reasoning is accurate, or maybe it's a bit off here. Let's go tweak that. [0:18:24] GV: Yeah. I'd to maybe just step back one piece, which I mean, we're just talking about, so they actually, the architecture and some choices around what's been used here. Because I think that's where a blueprint to me comes into its own, where some of these quite hard choices have been made for me in a really good way. You talked about plan and execute LLM pipeline. Could you just describe that architecture a little bit and actually, why that was applied to this blueprint? [0:18:50] AE: Yeah, absolutely. Essentially, something that best matched how the analysts actually approach the problem, right? Mimics how we can break up a task into something that you can parallelize and then you can connect this reasoning to. That's the main structure of it, as well as what we're finding out is, while this is a cyber specific use case, the benefit of the blueprint is it's extensible, right? A lot of people are saying, "Hey, you know what? This general architecture, if I ingest different types of data, or I do different prompting, I can apply it to different problem spaces as well." We having a lot of solution architects, which are folks that run out and interact directly with partners, they're doing a lot of very interesting stuff with this as well, that is cybersecurity adjacent, but they're using the similar agentic architecture that this blueprint, like you said, we got a lot of the complicated stuff sorted out and laid out before you and like, hey, how do you connect these pieces together? What framework should I use?" Say, "Well, hey, here's a really good reference." It's much better than starting with a blank page, right? [0:19:58] GV: Exactly. I mean, even the choice of models and both from the pure LLM side and the embedding side, I believe is llama 3.17TB was the model of choice. Could you, yeah, just speak to why that model and how do you even go about choosing a model for this thing? [0:20:19] AE: Yeah. That's been a fun process. We've gone through the gamut of so many different models here, and which again, shows the ability of Morpheus and blueprints to be very extensible. We started with GPT 3.5. We were experimenting with some lower tuning to make it more cyber specific. Then essentially, as we're prototyping this out, NIMs became available. That just made our life so much easier, because then it handled all that stuff for us. It's like, look, you just hit an API and we're like, "Awesome." We don't even have to spin something up. We just ran with that. We found that the specifically 70B was a sweet spot with number parameters. Yeah, if you do more, like we have some 405s out there, it doesn't do that much more improvement. Then if you do smaller, the agentic actions are as good. It's not as good as a tool usage. It's a little bit of trial and error. But then with that, we dialed it into 70B being the most robust. In the case of a blueprint, you could mix and match models if you need to, if you want to go just a little bit of extra performance, or tweaking it for your use case. In the case of a blueprint, it was just a little less complexity and easier to deploy if we just kept it the one model, which is pretty much good at everything. [0:21:33] AS: Yeah. I think one of the cool things about this, I mean, and you know this, Gregor, models, it's almost weekly that we're seeing new models come out as well. [0:21:41] GV: Exactly. Exactly. [0:21:43] AS: I think that was the great thing is llama 3.1 70B is an incredible model. It's so powerful. Meta continues to innovate on what they're putting out there. As new things come out, we can put it in and we can test it. Because it's this containerized model, it's really easy to swap them in and out and then say, "Okay. Well, the prompting has to be adjusted a little bit," or things like that to get the same performance. It does really simplify this down. Yeah, the blueprint today built on llama 3.1 70B, because we think that works really well. Three months down the line, six months down the line, maybe we'll update it with some of the later models, depending on what new features come out in the models themselves. [0:22:24] GV: Yeah. I mean, I'm going through that process at the moment with a product I'm working on, which is it's both that model, as well as the embedding model. I guess, yeah, just also speaking about the embedding side, again, I never want to assume anything from our listener base what they perhaps know and don't know. Could you maybe just speak very briefly what is embedding and why is there such a specific model for embedding as well? [0:22:43] AE: Yeah, sure. I mean, the embedding space is how you translate a document to something that the model can understand. There's a couple of different ways you can give a model context and embedding is the best way to do that. There's a lot of performance up stuff you can do by creating an embedding. This is a really good example for this blueprint, we've made the embedding process and the VDB process in-line. There's a lot of different libraries, rapids associated that are good for VDBs and utilizing them in very accelerated ways. Definitely check those out. In our case, it made sense to do it in-line because, again, for ease of deployment and when you're turning a code base into embedding, you kind of, all right, is this the latest version of the code base? Is this up to date? Yes, if we do it live, then that's not a problem. If you were to take this into full actual production, maybe not the best methodology. You want to separate that out, right? You want to have it. That's another process. I mean, still could use Morpheus. It still can use the same embeddings, but it's running a nightly basis, because you could have, again, your thousands of different of code bases and that you don't want to do every time. It's up to you to define your process of how often you want to update it and mimic that. But piping it into the LLM would be the same way. That's where we draw the line between this is a blueprint versus what somebody would take into production. Being mindful of it and, again, taking the ability of the fact that a blueprint is pretty extensible. It's not too hard to decompose. [0:24:16] GV: Yeah, absolutely. Talked a bit about how all these processes, or how the data makes its way into the system, if you want to call it that, and at a higher level, how that's going to be queried. There's a repo with all the information, incredibly well documented. Really - [0:24:33] AE: Make it very hard on the documentation. I'm a little bit of a nerd when it comes to good docs. Thank you. We work very hard to look at the index. It's huge, right? It's because you want to - [0:24:43] GV: Yes. Yeah. I mean, yeah, I was going to say it, from such a large company, I was not expecting such good documentation. Within a repo itself, sometimes you can go find it somewhere else. Yeah, this is awesome. Arc diagrams in there, etc. If I look at the main one that talks about the key components and on the left side, we've got the ingestion, things, S-bomb, etc. Then on the right-hand side, that's all the bits that are then doing the figuring out, I guess, is mostly NIM. We've got NIM checklist generation, we've got NIM task agent, NIM summarization, NIM justification. I guess, a question I've got is NIM walk through, like are these API endpoints, or these things that can be self-hosted, or how do these work? [0:25:31] AS: Yeah, I'll jump in on that one. Yeah, NIM is essentially a containerized, optimized model. NVIDIA, as I said, has loads of libraries and SDKs that we've been working on for years. Rather than asking developers out there to go package this up themselves, we thought, why don't we do it for you? Put it into a container that either you, or your IT person can go deploy. Then we build standard APIs on top of them. We use whatever's common in the industry, and we try to be compatible with that. Or we invent it ourselves if it doesn't already exist. We have these standard APIs. From a development standpoint, all you're doing is accessing APIs. This is something we're very, very used to, very used to developing with these days, but it's totally managed and controlled in your own environment. You can take it with you, you can run it anywhere from PCs, workstations, all the way up into the cloud. That's really the benefit there. Then, like you said, the blueprint has a number of NIM in it. This one, we're talking llama 3.1 70B, but if there are multiple NIM, one for embedding, it's the same deployment mechanism. You're getting this really common way of deploying whatever the model is. No matter if it's an LLM, retrieval model, speech, avatar, you name it. I think it's just a really powerful tool for both developers, as well as those IT teams who support them. That's what makes being able to do these blueprints and give the building blocks that Allan's been mentioning that are extensible, give those options to the developers. I think that's the beauty of NIM. The secret of NIM as it were. [0:27:16] GV: Right. Yeah. Again, as documented in the docs for this blueprint, as I imagine, for most, it's very clear that they can be NVIDIA hosted, or they can be self-hosted, right? What's the platform for the NVIDIA hosted? Where does someone go, I guess, to spin up an NVIDIA account, for example, for that side of things? [0:27:37] AS: Yeah. We host the NIM for prototyping on build.nvidia.com. Hopefully, easy to remember so everyone can find it. On there, you can go, you can test out all the different NIM, you can run the blueprints, as you said, experience them without even doing any coding. Then we also have options to download and deploy them yourself. We also have another option called launchables, where you can actually deploy onto another infrastructure. To answer your exact question, if you're using the APIs that are hosted on build.nvidia.com, you're actually accessing those models running on DGX, which is our most powerful infrastructure that's out there. You're getting the best of the best. Then you can take them, you can deploy them anywhere, move them into production, and really build real applications on top of the same software, just wherever your GPUs are hosted. [0:28:28] GV: Yeah. It's super nice being able to get to test out the Ferrari of GPUs, even if you maybe can't afford them for your own projects at specific times. Yeah, that's really nice. I mean, looking at how this has been received in the real world, what have either of you seen in terms of, let's start with this blueprint specifically, what has been the reaction and who has given those reactions, I guess, and then we might also just talk about any of the other blueprints that have received some attention. [0:28:57] AE: Yeah. I mean, I can start with, I mean, we're deploying this internally with on our own teams, security folks. Because if anything, we should be using our own things that we're putting out there. I mean, the feedback is, if you work with security people, they can be very conservative and skeptical. It's like, oh, somebody's just throwing another tool that I have to figure out how to use. While there's a little bit of hesitation at first, once we were able to present it to them in-line to their work stream, it's not they have to do something new. It's part of their process. They're like, "Oh, wait. This is great. Oh, this summarizes everything and you give me the sources? Okay, I can start trusting it." Then very quickly it goes from like a, "I don't know if I want to use this to starting to ask for more features." Then like, "Hey, can it do this? Can we make sure it is accurate?" That's one of the important parts of using anything like this. You got to have good domain experts at your disposal and point them. We have also worked with some partners that we're working with deploying these blueprints themselves, and they're working really closely. I feel like, some of the best feedback you can get is if folks start contributing back to your code. Because it means they're starting to get vested in it and they're starting to - they're a rocket and understand it and they want it to improve. It's the worst when you don't get any feedback. When you do get feedback, it makes people - it shows that people are invested, right? The blueprints, we're continuing to improve them, we're considering doing commits and updating it to the latest models and any new features. That's the feedback we're listening to it and then we're improving the stuff based on that. [0:30:34] AS: Yeah. I think just in general, I think developers have been really excited to have a starting point. I think, Allan mentioned earlier, it's hard to start with a blank page. Generative AI, it's coming fast and furious. We all can think of things that we would love an agent to do for us, but then actually going about building that and making all those decision points, it's a lot. I think just having that starting point for people to then say, "Okay. Well, I followed the blueprint, I did these things, but actually, for my use case, if I make these changes, it works better." That's been, I think, the best part of feedback and the thing that we were really striving to do. Everyone's going to have their own changes and they're going to evolve over time. We didn't want to try to build the final solution. We just wanted to give a development starting point. Yeah. So far, that's been the feedback. Like Allan said, the more people use it and the more they contribute back and let us know what other use cases and what other areas, I think, will be really impressive and will help us. Then I think the next interesting one that we're hoping to see and we're starting to see a little bit, especially internally, is daisy-chaining blueprints. How can you connect these things? How can you take pieces from one and add it to another? Our digital human is a great example of that. Almost any agent can have an avatar in front of it. If you want a CVE avatar, you can build that. I think that's going to be a really cool thing to watch when people - multiple blueprints and build their mansion, or whatever it is. [0:32:13] AE: Yeah. I mean, just to chime in, too, it's pretty impressive to see NVIDIA. Basically, one of the things that NVIDIA is really good at and I'm slightly biased, but the way it makes - you can buy in as well as much as you want into the system, right? Hardware-wise, software-wise, right? It's like, you can go full everything, NVIDIA up and down the line, or you can just say, "You know what? This one piece is what I'm interested in." We're doing that a lot with the software now, where if you want a NIM this is just, you can build out your own framework and you just hit the API with NIM. Okay, great. I don't want to do optimization. Blueprints, great. I'm going to take this and customize it. I'm going to change blueprints together, and build some crazy, crazy big system out of these things, but it's all available and very easily enabled. There's no real gatekeeping to this stuff. It's pretty out there. That's another reason why a lot of these blueprints are released on GitHub. It makes it just easy to use, in a sense, what we're going for here, right? [0:33:19] GV: I think that comes out in, I don't know, all aspects of what, at least from an outsider's perspective, I've seen from NVIDIA, which is just this overall openness to try and help people use its stuff. It is complicated stuff, but it's exactly - I feel like blueprints is, to me, anyway, shown how invested NVIDIA is and actually having it being used in the real world, as opposed to just saying, "Well, we're going to produce these incredible GPUs and then buy them and that's where we finish." I mean, to me, this is just a really great initiative. In terms of any of the other blueprints, I mean, I don't know, which would you say has had the most reception? I don't know if it is, perhaps it is this one. I don't know. I'm just curious if any have - [0:34:01] AS: We had a standout, again, announced a couple of weeks ago at CES. It was a PDF podcast. Taking PDF data, processing it, having speakers, multiple speakers be able to come out in a format. Gregor, we're not coming for your job, don't worry. [0:34:17] GV: I have used, I mean, just to, I guess, today, but no big LLM. Obviously, I've tried that out. Yeah, I was impressed, but I was also not too worried about my job, quite. [0:34:26] AS: Exactly. The way I like to think of this one, and I think, I think we all touched on it, and even the CVE blueprint covers this, is this is another one of those use cases where how can I take masses amounts of data and summarize it and structure it in a specific way? We happen to choose podcasts, but it could be any structure. I think that's a very common task for us humans, especially as the world continues to grow and data continues to grow and we want to absorb and learn as much as we can. These types of tools, I think, have just endless amounts of use cases. That one's been really popular. It's only been out for a couple of weeks. We've had thousands of people going to it and testing it out. It'll be interesting to see what comes out of those initial development efforts there. [0:35:17] GV: That's really fun. Exactly, just going back to, I guess, this talking about reception and contributing back, etc., can you maybe just speak to, I mean, there's a repo there. I've seen a lot of people have forked it. How do you class this from a open source point of view? [0:35:29] AS: Yeah. I think we want to make blueprints, Allan said it well, we want to make them open and available. A lot of this, this stuff that we do internally. We're using it ourselves and we had the same problem. Rather than just us doing it and us learning from it, how can we put it out there into the community? We're going to continue to evolve these blueprints. We're going to continue to learn from these blueprints. We love seeing them forked and being used in other ways. I think that's great. I think one of the big next steps is opening that up to the ecosystem. There are incredible partners out there, like LangChain and Llama index and Crew AI and Daily, even some of the MLOps partners, like weights and biases who have expertise in this, who have blueprints that not only include NVIDIA and NIM and the great work we do there, but include their own libraries, SDKs, services. Being able to create a hub of recipes for the community, I think is just really, that's what we're trying to do, and be as open as possible. [0:36:37] AE: Yeah. I want to just maybe wrap it up in a little bow tie here with like, maybe we noticed that we haven't talked that much about cybersecurity specific things. It's in a sense, what we do here in NVIDIA is we take all these amazing frameworks, we build out new frameworks, and then we apply them to a multitude of use cases. We're not trying to do one specific product domain or anything. You can see, we're all over the place with interesting problems we're trying to solve. We're not prescriptive, like how we think they should be solved, right? It's like, we're going to give all these tools and all these capabilities out there. Morpheus started that way. It's like, well, what are these GPU acceleration capabilities? How can we do new things with them to solve cybersecurity problems, right? Hey, these LLMs are out there. How can we use them to solve cybersecurity problems? The same thing can be said for all kinds of different domains in the tech space and enterprise space, right? That's what we like to do is put all this really interesting, useful frameworks and then see what people can build with them. We're not trying to build the end thing ourselves. We're just trying to find how people can come up with really great and interesting solutions to their specific use cases. Because I mean, at the end of the day, folks are their own domain experts. They know their problem space better than anybody else. Enabling you to build for your own problems and solve them is something we like to do. [0:38:12] GV: I'm glad you brought that up, because I did want to just come back, so to speak, to the security part of this. I think, to me, even it was a little bit almost surprising to learn that NVIDIA was looking at security, full stop. I mean, you've, I guess, summarized it there, but how might we see NVIDIA evolve in the future from a security standpoint? I mean, I liked that the blueprint, this one specifically you mentioned, actually came from an internal pain point of how do we solve our own container, CVE munging. Half of the best products in the world come from people trying to solve their own problems. Can we expect to see more maybe outward-facing security, I don't know, products, or I don't know, GPUs that are almost designed with this use case in mind? I'm curious how that looks. [0:39:00] AE: Yeah. I mean, there's so many cybersecurity specific use cases that are big problems. You can solve them a lot out of different ways. Yeah, we're continuing to just see what we can do with the Morpheus SDK and with gen AI. Essentially, trying to get this sense of there's been a shift here where instead of thinking about you're making an application, you're more of a agentic system application, right? We're internalizing that shift a lot and seeing how can we uplevel that capability to a wider audience? You don't necessarily need to be some hardcore dev person. Blueprints is like, it's a good starting point for you to take advantage of this agentic AI stuff. Continuing to do that. There's always graph, which is something that is super powerful, but always gets pushed back a bit. There's some amazing graph capabilities within rapids and that we're working around the cybersecurity space. A lot of applied research that we're doing in Morpheus time. [0:40:10] AS: Yeah. Just to make a make a point on that one is, we don't want to be a cybersecurity solution provider. You're not going to see NVIDIA up there competing in that space. We are an AI company. We love AI. We're excited about it. We've got a lot of experience in it. What we want to do is bring AI to cybersecurity providers, to cybersecurity problems, to things like that. I don't want to confuse people to say, "Hey, NVIDIA, they're diving into the cybersecurity space." No, we really, we're focused on AI and where it can help, and whatever those problems are, and cybersecurity just happens to be one of the great ones that we can help with. [0:40:49] GV: Someone came up with a phrase that week, saying the future, or at least 2025 looks more like it's not software as a service, but it's service as software. I think that's a good way to think about it, which is solving slightly more specific problems in a very deep way, whether it's for a specific enterprise, or maybe a group of companies, but not this blanket one tool fits all for - I feel like, this is a very good example of this, where again, CVE remediation has many different contexts. Am I remediating it from a external attack surface point of view? Am I remediating it for internal container point of view? I would want very different results based on that. I think this definitely leans into that way of thinking. Just as we wrap up, I always like to ask guests just a couple of questions. The main one I like to ask is knowing what you know now, if you could tell yourself anything at the start of your career, what would you tell yourself? [0:41:47] AS: I'll jump in on that one. I would tell myself, you can learn anything. As somebody who doesn't have a traditional technology background to now having been in technology for a long time, but been then in NVIDIA 10 years, there are things I have learned that I never realized I could and would never have bet on. I think as long as you stay open and keep learning, there's no telling where you can go. That's what I would have comforted myself, that there's nothing that you really can't just learn. [0:42:15] GV: Yeah, I love that. I was thinking this morning. I was on the bike this morning and thinking, yeah, it's just about, as long as someone knows how to learn, then possibilities are endless. I like that a lot. Allan, what about you? [0:42:26] AE: It's hard to top that. I mean, if you're working in NVIDIA, it's you have to, right? The amount of different and new things I've had to learn every couple of years and just not out of necessity, but out of just curiosity, right? Because it's like, wow, that's neat. How far does that go? You just got to be open to that and adaptable to it. Even as I'm getting a little bit older and I'm getting a little bit more grumpy about, ah, this new thing came out. Do I have to learn it or not? You start getting a sick sense of if you've been in technology place long enough, where like, no, no, there's a thing. This one has a thing to it, right? This AI stuff, I mean, yes, very hyped, but there's a thing there and it's - Sometimes it's easy to be very jaded about this tech stuff, but sometimes it's also good to take a break and pause and really, this is magic. It really is magic. I mean, I was thinking about Star Trek the other day and how before they were like, oh, iPads. They're little pads, right? You're like, "Oh, they're so futuristic." Now like, oh, they look clunky, you know? Then I'm like, oh, that's so funny. The tech looks. Then I was like, talking to the computers and you'll just magically make a thing, that's never going to happen. Now I'm like, they're doing that right now. I'm like, huh? Yeah, it's pretty magic, right, what stuff is able to be done right now. On some level, just be open to it and yeah, stay curious. [0:43:57] GV: Definitely. Yeah. I know, I mean, I can identify with that. There was a phase where JavaScript frameworks were a dime a dozen. I think my learning capacity just tanked at that point. I was like, yeah, this is difficult. This is really difficult to get excited, or even think about learning. Then as you say, things evolve and luckily, that phase went by. Now we're here. Again, my learning enthusiasm has just rocketed. I couldn't agree more with that. Look, it has been, again, such a privilege to have you both join Software Engineering today. Just again, as a recap, where's the best place for a developer just to head to get stuck in? [0:44:36] AS: Go to build.nvidia.com. That's their starting point. We've got all the latest models on there. We've got these blueprints that you can go and explore. Then your journey just starts there. We'll give you the notebooks. You can start running. Hopefully, you'll have your application going in no time. [0:44:53] GV: Awesome. Well, thank you again. Yeah, we'll get to catch up again in the future. [0:44:57] AS: Thanks so much. [0:44:58] AE: Thanks. [END]