Secure Supply Chain, with Henri van den Bulk

Episode 222 · Thu, 24 Jun 2021 12:00:00 +0200 · 32:28 · SRT · archive.org · all Tanzu Talk

Why don't you introduce yourself? Yeah, sure. Pleasure to be here. André Vannebalk. I'm one of the global CTOs in Tanzu, VIMR. I primarily focus on a lot of the executive advisory roles. So I work with a lot of the Fortune 500 companies and their executives around transforming their organization. I actually came from a customer originally from when I joined Pivotal. I worked with Charles Schwab as an executive role primarily in the technology space. So all the core technology, so all brokerage, retirement, and stock purchase programs as well. So the topic we were going to talk about, basically, I don't know, a grander idea behind DevSecOps, a phrase that we in Tanzu land use a lot. When we use that word, a huge part of what it means is basically, as you would say, having a trusted supply chain, which is essentially, I have this piece of software that I'm running. I want to make sure I trust the provenance of it. I want to trust everything that happened and I can make sure to not only patch things, but I also want to like be able to figure out how much do I trust this piece of software based on what I know about where it came from and who built it and all of that sort of stuff. Yeah, it's an interesting time. And that's why I want to step back a little bit and put it in perspective what these things mean. If you think of the whole DevOps motion that people have been talking about, it's the code du jour currently what's going on. Everybody loves talking about these things. And can I add any more words to it? Seq is now part of this. And I was reading another book the other day, but FinOps. So now we're going to add financial pieces to it. So you keep throwing at the same thing, but you have to stop back. And what does it mean? Like, what are you trying to really accomplish? So the analogy I tend to use is similar as if you go to the grocery store and you look at a product that you pick up, you can rationalize as an individual over what is in the product. So it has a set of ingredients that tells you and informs you, I eat this product. Am I allergic to the nuts that is in my Nutella? To use some of your video analogies. But so can you rationalize over that? What's in it? But then also you want to have a level of when they actually say things that are in there, can you trust it as well? So there's like, for example, organic. The vendor can say it's organic, but is it organic?

So do you have ways of kind of rationalizing over the product? What's happening more and more in the industry, like back in the day, you only have maybe one or two vendors that you have an implicit trust in the software industry, right? You could go, for example, VMware or Microsoft or fill in the blanks and I pay them a check. So I implicitly trust what they're doing. But more and more, the supply chain has exploded because you have so many different more vendors and also open source contributors from countries that you might or might not have a positive reaction to that software came from those industries. So that's why I've been touting more of this notion, like you need to create trust in the supply chain because by default, we use it just implicitly trust. But now with all the vulnerabilities that have happened, SolarWinds being an example, is you need to have a way of rationalizing that trust. Can you actually trust what has been done and what's been said in that particular space? And it gets to the question of what are those things that allow you to trust those things, right? The same way that you walk in the grocery store and then the vendor says, yeah, this is in there. Sure, do you trust the guy or is there a way of verifying what you've done? The classical way that people have done this is in security space is, okay, I'll install hundreds of different scanners and then maybe I can then find things. But what if you can turn it around and instead of doing things upfront where you look at an artifact or look at the attestation of an artifact and say, yes, I trust what the vendor has said because I have a way of verifying and to test it to these pieces. So that's how I've been thinking about this is that you have a set of concerns that you're really trying to address. So let me step this forward in the industry, for example, in financial services. We were chatting about this a little bit earlier, but big concern is things around compliance and regulatory concerns. Most of those really look at what are the steps that you have done to make the sausage per se? And what they want is a way of verifying that you have done what you said you would do. It's like Sarban actually kind of approach in a manual way. But how can you codify those concerns

into your supply chain? Because at the end of the day, your supply chain is just the flow of materials that you're working with. But you have also other regulatory like the HIPAA, PCI compliance that's trying to rationalize over these set of concerns. In the United States, there's the NIST Institute that has started to articulate what things should you be looking for from your software to say, is this a good thing or a bad thing? And currently, we don't have the tooling in place for beyond scanning, essentially, to rationalize over something arriving at your doorstep. So the way I break this down is you have a set of phases in the supply chain. Each of it, you can rationalize over what's happening. So if you break it down, like first, you start up with the basic things in supply chain. Supply, like where is the supply of the raw materials coming from? So you open source projects, vendors, et cetera. And thinking through that, like where did they get the pieces from? Have they done testing? Have they done scanning? What are all the components that are inside of the raw materials? So this is what we typically have been calling like the build materials, even in the physical side or digital build materials. It really specify things around what's in the product, like using a Nutella example. What is in there? What nuts are in there? What chocolate is in there? Where is it coming from? Have they tested it? What is the quality assurance that they have done around this particular piece? So you can then define that in the build materials in a way. But you also, the other key ingredient with that is you have to make sure that you attest to those things as well. So beyond just saying I put a label on my product and say this is in it, you need to actually sign off on it the fact that yes, it is in there. There's maybe a third party that's verified that those things were in there as well. The reason you really do that is so that when you take that into inventory in a company, you take a piece of software, you can quickly inspect that build materials and say, you know what? I like what you have here. I am allergic to nuts, so I'm not going to do this. Or there's CVEs in it that I don't care for. Or you haven't done enough testing to do these things. Which is an interesting notion because this part is the regulatory bodies in the United States are starting to make

some suggestions of companies should really provide a bill of material. Just like what they've done in the food industry. Like you should really say what's in it. And we've done it as in hardware for a long time. So why doesn't software have this concept? Let's go in reverse order here. So as you were just mentioning, there's this idea that the reason you have a bill of materials, you know, to slightly go off the food analogy, being allergic to something is a good metaphor for security concerns. But in anyone who might want to consume a piece of software, let's say a bank gets some software that does whatever. Let's pick my favorite benign example. It's a pagination system. They have a framework that paginates its tax collecting season in the U.S. You got to go find all your expenses. You need some framework that paginates everything for you in the UI. And no one should write that framework on their own. That's a bad idea. So that's right. So you're going to go find some pagination framework in whatever language that you have. And that's displaying to the end user critical data. So that could be a point of whatever, leakage, some bad things. One would want to know when we're looking at this pagination framework, can we trust it? And one of the things as you were saying is it's good to have a bill of materials. Probably the pagination framework uses other libraries. And those libraries use other libraries. There's a bunch of dependencies. So you need to have this bill of materials that says, what is everything that it contains and what version are they? And then as it's, okay, so that's me defining it for myself. You're doing a great job. And so in that area, as you're saying, talk to this idea that we've done this for hardware, but not for software. What is that? Like when you get a chip, is there like a bill of materials that comes in it or storage? Or what does that bill of materials look like for hardware? Yeah, it's interesting. If you look at a lot of hardware, a lot of them have, even when you order it, it has a list of SKUs that tells you all the different parts. And you can actually rationalize that where some of the, like where does the silicon come from, which Intel provided, right? So you can have some pieces of it. It's still not perfect in all sense, but to use your analogy, which you have

for some of the UI components, currently a developer that has implicit trust. It's just an NPM, install the package, poof, it's there. But you have trusted all the things that the package contains. And most of the developers don't know what's inside of the package. They just know like, I need this library and magic happens. On the hardware side, to a certain extent, you can rationalize over because there is a, an actual piece of paper that says, well, there's all the stuff that's in it. And so it creates this direct acycle graph per se that shows this component uses this component of this version. And you can walk that piece to understand like at each component, where did it come from? Who created it? What were the vulnerabilities in that particular component? Is there licensing concerns? Because this is another part that people forget. Like certain libraries have licensing that actually requires you to contribute back. So to your example, so if you use that particular library and you make changes and now you have to contribute your code back to the community, well, bank might not want to do that. And so do you need to be able to say, okay, is this license conducive for me to do business? There's two other things. There's scanning. And that seems to be like, especially when it comes to licensing, as you just mentioned, right? There's companies like, I think they're still around, like Black Duck and Palomita. Way back when I was an analyst, I used to know them better. They'll literally like, and it's great for open source because you actually can get the code, but they'll scan your code and even your compiled code and generate fingerprints of everything. And they can tell you what you're using, essentially. And so when it comes to like scanning, because scanning is like, what would you call it? Post facto? What's the English for that? It's after the fact. Is that good enough? Or like what, how good is scanning things versus not? Like where does it fit into this idea of really understanding your supply chain? Yeah, I think more and more the scanners definitely do a good job. But the problem is that if your CPU cycles in your environment, there's more about scanning continuously, taking it away from actually doing actual work. So I have to have an hypothesis that you, if you have the right at a station, a trusted, you can eliminate actually a lot of scanning

because what you can now do is say, yeah, I have a level of trust with some risk parameter that I allow things into the environment. It doesn't take away all the scanning. Don't get me wrong. There's always some level of piece. But to use an analogy, like if I take the Nutella, if you go to the grocery store and you can take it home and spread it out on your table and then get a lab and say, hey, take a look at my Nutella before I eat it, if you have to do that every single time to understand like what are the ingredients and that just takes away of what you're really trying to accomplish is to use the software. And then, so the next thing, let's continue the analogy. We'll stick with, apparently you have a Nutella obsession. I don't know why. We joke because I have these little videos where I put Nutella on things and taste them and see what it's like. Anyways, this brings together another thing I wanted to talk about is that I'm always interested in why are we talking about this thing now? Like this is security is like one of those things where things have always been secure or not. It's always an issue. And I was thinking like, let's, I'll see how far we can stretch this analogy. One of the things that comes up nowadays with doing like cloud native development or let's just call it development nowadays is you can go through a coding deployment cycle so quick that to your point, scanning wouldn't necessarily be feasible to scan the entire stack, right? over here. As I'm sure you're familiar with, there's booking.com and they're renowned for doing like thousands of tests a week or a day, like different variations of things. If you were doing like 2,000 deploys a week, like that would be, scanning would start to take too much time. Similarly, if I came home and I made 100 Nutella sandwiches and it took me like three minutes to lab scan them, each sandwich, that would be impractical. Never mind the practicality of 100 Nutella sandwiches. It's almost as you're saying, you need another way where you can more deterministically not have to scan something. And so scanning reaches a limitation if you're deploying multiple times a day, essentially. And at the very least, when it comes to code, you need to know a smaller amount of things to scan than the entire stack

of software that you have. Yeah, it just becomes a complex problem at the point. It's like Intel famously said a long time ago, it's like if we had to scan and test every permutation in the Intel processor, we would never release a new processor because it takes them so long to do this stuff. So companies forward doing every scanning, any permutation that might potentially exist, it's just too much to do. That's where the problem comes in. So at some level where I come back to the supply chain, you have to instill trust in it. You trust certain vendors, you trust certain things based on some risk scoring, relative risk scoring. And there's some interesting research being going on in this area, but can I create some relative risk scoring of what I get into the door and make my decisions based on that number? And that it's a factor of what is the impact potentially, the number of CVEs and whatnot versus in trying to scan the whole thing, you can really take what the vendor has said and there's some level of attestation and accreditation that might happen. Does that make sense? So then hopefully this won't be too much of an abstract rabbit hole to dump on the table right here. But anytime people come up with things like attestation, that's a funny way to say it, or trusting the bill of materials and then that immediately, like in the modern way of thinking about security, it's all about like risk management and expressing the risk to a decision maker who then makes a decision, lesser no. And especially since you have experience on the actual, whatever you would call them, customer side, on the side of companies who go through this, like that always seems nice until like you're on the wrong side of the risk assessment and then people get fired. And I don't mean that in a flippant way, but there's something about understanding like a risk assessment that I don't quite, that I don't quite appreciate yet because it's almost like when if I say I'm 95% sure everything's cool with this security thing and then it's just the way statistics and percentages work, that means there's a 5% chance that it's not cool. 90% confidence interval. That's where you're trying to go. And then so for example, let me try to ground it some, it's like for every big solar winds blow up,

there are 90, there's I guess 90 more didn't blow up and those were cool. But it's, I just, it's always like how do you deal with that 10%? Because it seems like if you're in that 10% of failure, no one cares, right? No one's like, we gave you the risk assessment, these were the numbers, but we were just on the wrong side of it. Or am I thinking about it completely wrong and it's not that you want 90%, you want 99.999%, right? Yeah, it's interesting though. If you think about what risk assessments really are trying to do is you're trying to quantify, for those that do it well, that you're trying to quantify what's the impact. Like if there's no impact, then there's no, you don't care too much about it. Yeah. But what's happened, what's happened is the way things in the industry has prevailed with these risk assessments. Like this is like the compliance department coming down or the security of it. Hey, they shall have so much or less risk. But there's no context with these things and we're trying to do this through process like Serb and Oxley or any of the other ones that are out there. Somebody comes out there with this large spreadsheet of 500 controls that they shall meet and if they shall not meet it, then your risk is high. But it doesn't have any rationale in the sense of if I put this in my little cup over here and it's not doing anything with customer data, so what? But the problem is that we're using spreadsheets and processes to rationalize over this versus the circle back to DevSecOps is codifying ways to instill this in part of your flow of what you're trying to do and then have a better risk determination based on actually what's something that tests to or that you can verify. Yeah, no, I like that. I'll have to think about that for a while because I think what you pointed out is a lot of the risk management conversation I have encountered over the years as you're joking is about a number or like a percentage. And I'm sure as with all process like this, the intention is never for the following state. It just ends up being that way. Whereas what that one number lacks is context and that context being at least two things.

One is, to put it in another flippant way, what's the worst that could happen? Right? Like, what are we talking about? Never mind that it's 99.99%. What does that lead to? And then the other part of context is not only what's the worst that could happen but what am I giving up? The going through the analysis of getting of that risk assessment should include what that context is so that you can really make that kind of assumption or not assumption, you can make that kind of thinking. and so you can figure out like, we are willing to take on this risk because we want this outcome as a common day thing and then we understand the risks that we're taking. I don't know if this is actually true but it would be fun to think like, if we take on this risk, we can hedge by getting some insurance over here that if something bad happens and we all agree that. I like that analogy because you could to a certain extent associate, like insurance companies are actually good at this, assessing risk. That's basically what they do is risk assessment. You see a rover behind me but I worked at NASA for a while and one of the things that they've done very well is risk assessment and there's this notion of a two-by-two matrix. So the context is really also, you look at what the impact is but the other dimension is the likelihood for it to occur. So that's a part of the context. So you can then map out if you get a CVE and what's the likelihood of sets being exposed? It might be in a container and nothing happens. So that part is you need to get to that motion where everything in your risk, you assess it based on those two dimensions but you need to have a way of codifying those capabilities when things come into your inventory in the company from your supply chain. Say, oh, I can now rationalize over this. What's the likelihood of this happening? And it takes a little human intervention to a certain extent knowing the context of an application. So getting back to the trusted supply chain sort of thing, I think that's an interesting not consequence but not feature but capability you would want to have out of a trusted supply chain as you were teaching me there is I would like to be able to assess the trade-offs that I'm doing and using classic productivity thing. It's not only that I want to assess

the trade-offs by like you giving me maximal information. I want you to like minimize the amount of noise. It may be positive noise but I don't want to know about every single thing or like spend time scanning every single thing. Figure out the optimal set of information that you can put in front of some people so that they can decide on the trade-offs and the trade-offs might be like, no, I don't trust it. Go back. Yeah, I guess that's what happens with scanners to a certain extent to talk back. It's the same as if you get so much information you get so much noise but you really want to get and try to find the signal to noise or reduce the signal to ratio and there's some interesting software already that people are starting to come up with to rationalize over the supply chain like dependency tracker is an example of an open source project where you can bring it in and you can actually see the CVEs and then have a way of in context associate some risk scoring with that and so instead of looking at oh CVEs are high medium or low and based on that making determination that's kind of noise in the overall perspective but getting it down to this notion of okay what is a relative risk score that I can do and then systematically like what flows into production to base it on a risk score versus on high medium or low CVEs right because the volatility and the velocity on the CVEs is just going to increase more and more as we move into the software industry you just want to be able to rationalize more on a risk basis. All right so let's see if we get back to the main so I cut you off at Bill of Material generation. Yeah so Bill of Material is kind of like one of those first like what are the ingredients but the other thing that the industry needs with this is a way of attesting to this as well to give an example like you can slap a label on the product and do you just the guy that made this or is there a way of attesting to it so create some credibility is important to establish trust so for example is that the FDA in the United States or is it some institution that can attest that yes that vendor has provided the right material or whatnot so like an example that we're starting to do like in Vietnam our application catalog in Tanzu what I'm really excited

about is that we are actually doing a lot of the tests we're creating a bill of material the CVEs and we're doing it as part of a process and then the next thing is to attest to that as well so cryptographically signing that or a third party through an audit mechanism verifying that what we've done is actually true so that creates excitement because now a customer can then take a look at that and say ah you've done the things and I've got attestation in place as well but the interesting thing with attestation is not just saying that the stuff that's in there it's also what are the processes that you've used so for example in the development space has a developer created tests unit tests for example great have they checked in what was the PR that they did QA have they done their job right or there's some other scanning those steps along that flow need to be attested to as well and there's interesting things in the industry happening with this it's like there's frameworks like in Toto that's starting to you can certify every step that you've taken so like in the factory when you're making the product as it moves inside of the factory every step that has happened in the factory can you attest that it actually has happened like using SolarWind as an example this wouldn't have solved the SolarWind problem just don't get me wrong but the steps that we're taking to build a piece of software could you inspect it to say yes testing has occurred yes it was built by this person or it was built by this machine over here what does that look like is that a manual process or like cyborg process manual and automated or like just just to let me make a really simple example we have someone specify a feature in our pagination framework so that's one step then we have a developer write the feature in the pagination thing I don't know they want to use two dots in the middle instead of listing 500 pages whatever and then so then someone has to test that and then you bundle that into a build whatever and then you upload that to a website and I only mention that because there's a step I don't know what you call this but there's a step of making sure I got the actual build like verifying so like with the in toto what does it do in each of those steps so first you define what the steps are right yeah

and any transition from one step to another step gets certified like signed essentially and so an easy analogy we're already familiar with using git for the most part right so you're already implicitly doing this by saying hey I do a pull request right you've signed you get a signature but it's not cryptographically signed for any means it's more of like a hash that happens so in total what that allows you to do is more in general terms say what are the steps and along the way you can sign the fact that you have performed that step so now you can rationalize more over have you done all those steps that you've said you would do like testing okay so what you're doing basically is you're verifying that someone did something and so part of what you're trusting is the meatware sort of pipeline there like the people but you basically want to know this person said they did this thing right this product manager signed off on the feature this developer signed off on checking it in and we can also verify that what we have is actually what they did instead of another thing and then this QA person we can verify that this exact QA person or entity said they did on and on and so there's nothing like magic about like and then also some AI came in and looked at it and made sure that they were actually doing what they said they were doing it just lets you track like an individual's saying yes I did this thing if you think about a lot of compliance right if you actually go through that 500 step compliance checklist most of them actually have these things like oh what is your flow have you accomplished QA and currently yeah sure just check the box and move on but this gives you more of a automated way to attest to these things and like if you start thinking like our build service right as it builds the different pieces you're going to test that it has done these things you've done the testing capabilities I'm not saying that every piece of software will do this because ideally you want to establish trust at a higher level first right have you ever built material great then the next level is are you doing the things that you said you would do for your software like testing and all that that's kind of the next level of trust that's going to happen in the industry so what's interesting is that obviously the customers

are wanting to to do this on software that they get from their vendors open source community is starting to make a lot of headway in this space as well like Debian and some other open source product they're starting to embed some of these capabilities but then the interesting becomes now is that inside of organizations that build software if they want to be more of a leader in a lead software company they're getting currently bogged down by a lot of compliance and security things and so using those same principles and capabilities codifying that in their own internal flow of the supply chain like the building processes it starts you start getting higher velocity now because you're not like oh wait I need to schedule a compliance check with x y and z in the organization and now we're a couple of weeks away from actually deploying to production or like what you said like certain cases they're preventing us from going to production because they say the relative risk score is high and then everybody starts unpacking this like why is it high what is it causing and emails back and forth that start happening you want to codify those mechanisms and so what would you say is like the current like status quo broadly of like large organizations managing their supply chain yeah I think they haven't gotten to the codification piece beyond like doing the scanning that's kind of the first basic step that the compliance department say hey Dysol scan everything into harbor registry or sonotype or fill the banks and then they assign a lot that has a high level of CVEs and then they have exception processes in place so the maturity level is still like a one I would say we're still in that scanning phase we're not nearly what I would call making rational decisions what goes into production based on some set of attributes that the software has that just apply to the attestation yeah my impression from talking with people when they ask about this is that it's a lot of what you're alluding to there's emails going back and forth right just simply extracting the information you would need to like do a security assessment is not automated at all like it's really time consuming and maybe even if it is automated

each team of developers automates it a different way or that there's multiple ways of automating it which just adds more cognitive friction to doing these things so that almost feels like one of the first steps to like just doing software better is like you got to automate this stuff right there needs to be a way of essentially you're doing the same security and audit checks you just don't have to do so much of it in email you can just get that not even bill of materials I don't even know what you would call that what like the raw ingredients of doing a security audit like all that yeah it's I think the level of automation right now is that Sonatype or any ability and automatically a ticket gets created into and put in your backlog for remediation that's about the level of automation right nothing that moves it up to the supply chain like the shifting left piece that it's data developers automatically have this way of rationalizing other things to take or not take software or attesting to the steps that they do I think we're getting closer there's some of the capabilities but people think of it as a complex problem to solve and as you put security in the DevSecOps you have to have codification and automation capabilities to really rationalize other things okay so far have we reached I interrupt and ask questions so much I lose track of the narrative thing but have we reached the end of the trusted supply chain where are we positioned now yeah I think we're getting to the point of inventory and build building but the other heart is that even customers that ship software now you have to start thinking about how do you distribute this as well so how do you make the build materials how do you make it at a station because even us as a software there's 50 million different ways of supplying this build material so there's some interesting notion here there's some proof of concepts happening in for some of the energy space in the US do you do centralizing all these build materials right Google is working on a project and some other ones like do you put it all in one place and people can download it well what happens if that gets compromised right or do you use a distributed way there's distributed

ledger mechanisms to make this available so I think there's work that's being done in that space it hasn't settled what's an ideal way of distributing your build materials like even the with docker and oci could you make it be just be part of your image that you get just like in the food store that the product hasn't labeled stuck on a thing you can actually see it so the industry is working on that aspect of it as well that's interesting you mentioned it there without saying the blockchain word but that would be that's a perfect non-monetary application of blockchain stuff we have these multiple parties that all that attest to a fact happening so they could attest to the attestation essentially and then distribute it all out and which is still like you get if you get a trusted bad actor then that's no good but whatever that's the way it goes yeah there's no 100% guarantee with anything anything but it distribute ledger has some promises there in the sense of some consensus mechanism it's a multi-party system right if you take a look at those properties and capabilities it could have some benefit in doing this and you can have third party certification as part for example you might ship your software to somebody else they verify these things as well attest to it and now it goes back to the chain of trust for all intents and purposes and then like you're saying the second part is for software that you're making your own you don't necessarily want to publish all the stuff you have right like I'm sure all the way from retail to banking to missiles like you don't necessarily want to have a bill of materials out there for anyone to consume to figure out like all the components you have in those things which means you need to have more of a private way of doing all of that and hosting it internally which is another yeah that's really good point to make right there because I haven't actually thought about it in those terms but there is like the double blinders type of approach where certain people can look at the ingredients per se but other people cannot so yeah so that part hasn't quite been figured out yet I think there's some promising technology capabilities in that area but we do need to get to some level that says okay how do you concerns because without it it's just implicit trust and we see sometimes how that turns out this is good because I think what we've laid

out let's just call them we've laid out the problem or the requirements or the things that we would like and I think we had a little bit of discussion of why this is an issue nowadays and that being that to use the old phraseology except genuinely here things change so quickly nowadays you generally are doing faster and faster releases so you have to do more and more of these checks which back to our hundred Nutella sandwiches becomes a problem it's just no matter how quick you can do a scan if you're doing it thousands of times it's going to add up eventually so that that brings in the need for this stuff yeah no that's good that's good do you have anything else we should go over before we wrap up no I think he thinks I really enjoyed the conversation I love talking about this topic I think there's a lot of work still ahead of but I'm encouraged about what's happening from a regulatory perspective that they're starting to be concerned about these things obviously and simplifying but the industry also corralling around this notion of how do I create more trust as well and I think at the end it's like a playbook from Apple right is that it sells trust sells so if you're like the vendor in this vendor space that is able to do this I think there's a good financial incentive to do this the piece around this I don't think people are going to be spreading around from a marketing perspective hey we're the most trusted piece I think it will become self evident right are you going to go to the grocery store that it's easy and convenient for you to see these things or do you go to the one that you have incidents what not so that's the thing with trust is like what I mentioned earlier it takes a long time to gain easy to lose but that first part of gaining that you'll maintain it for a long time for sure the value we provide all right if people wanted to poke around at things that you're up to you have a weblog a Twitter account you would send them to what what's something you want to promote for yourself check out my Twitter or just LinkedIn I post and share some things once in a while out there we have a VMworld session that we did last year about this topic as well be glad to share that all right I'll put some links to that wherever I post this whether you find this in YouTube or in the podcast or whatever I'll link to those things great well thanks for going over

you

Tanzu Talk · 🍕 Get more pizza.