BSides Perth 2023: Sajeeb Lohani & Ben Christian: Achieving Supply Chain Security on a Budget

okay hey everyone welcome to zero to here achieving supply chain Security on the shoestring budget um this is going to be a little bit of a different talk but before we say anything we want to make sure you know it is not a vendor talk we're not trying to tell you something and that's done very purposely but we are going to talk a little bit about what exactly bug crowd is and why we go and do the depths of what we actually do so for the scholarship bug crowd is basically a crowdsource security platform which basically means that we take epic individuals like yourself from our security community and put them in touch with our customers and then we basically

get them to submit some awesome bugs and get paid for it so if you actually think about it it's basically Linus's law personified uh if you've heard of rhinos as well it's literally um you know given enough eyes all bugs are shallow and it's literally taking that entire concept and bringing it into a platform um but enough about background today we actually thought it'd be really fun to go and basically introduce each other because you know we'll get a little bit of each other's thoughts in there um so this is Ben he's humongously tool and his Junior security engineer he is a bug Crowder and an avid you know ethically uh awesome security engineer so he

actually does some really really epic tasks in Bell crowd um he's on the purple tune so he's both an attacker and a Defender and we like to call them the true purple team so apologies for anyone out there who doesn't agree with us but um basically uh he's also the ex-president of the UTS cyber security society and uh and currently it's the partnership director so he's doing all of that while working full-time which is a pretty epic you know initiative he's a computer science student and he actually wants to steal my job and my salary but he recently found out what I actually do for a living do you still want to see my job mate no I still um I still saw this

calendar um meetings too I'm very happy in the in the technical side of things um but of course I love to introduce my my good friend sudeep he's fantastic he's the global head director of science community at bug crowd uh he's a fantastic purple team leader I have to say that just to say for my employment um he is in his spare time he's an adjunct uh lecturer at the University of Melbourne so if you're fortunate enough to go there do sign up for his web security masters from what I heard it is a fantastic course um he's a security researcher so he does do bug bounties and he's an ex-pentester um he loves to learn and maybe a little

bit of a sometimes annoying thing he loves the automation to the point that if even if it's quicker manually he'll still automate it and he'll find a way to do it so we have a fantastic um Talk lined up for you today if you haven't heard of supply chain security before we're going to be talking about that and then going into identification of risks as well as classifying those risks different attacks and also what to do in the case that everything goes wrong so some incident response as well as some leadership tips um so actually you know how do you present you know getting some kind of supply chain initiatives to your board at your

company and getting that implemented so what is supply chain security do you actually know what software you are using in a project do you know what software your dependencies use or maybe you've come to the realization that your dependencies might have dependencies but you know you might notice but you know going that extra step and making it secure but let's actually Define what it is uh supply chain security is accounting for and protecting all the software and use for your projects so this includes you know different types of languages you're using software components third-party vendors all of that included we are not talking about Hardware today so sorry for all our Hardware people out there

but for example you know packages that you would get from npm or maybe Pi Pi or even a Docker image that you've gotten from a you know a repository like Docker Hub there are all sorts of things we'll be discussing today but why should you actually care about supply chain security and the fact is if you don't um the significance um of it and the lack of it can be catastrophic on your environment so I've got six reasons um on why you should care and first of all is business continuity um everyone makes everyone makes sure that their business is running fine with no hiccups a breach is not a great way for that if you're not caring about your

supply chain breaches is absolutely something that could could happen if you have a breach down in your supply chain you know let's say a package or also it gets compromised their compromise is your compromise as well of course it's you know important to have processes um in place for your supply chains so for example getting packages approved making sure that you do have good processes to cause no delays in your business data protection we hear about it all the time in cyber security it's a massive thing that's why we're in it we're wanting to protect data and you know having a strong supply chain and the security of that is Paramount to that so for example example let's say

you know you've gotten a malicious package or you don't know it's a malicious package you've gotten and portable malicious package are using in a python software project for example and turns out there are some lines of code it wasn't properly reviewed and it's able to you know find your environmental variables and then send that off somewhere and you know if you had your AWS creds in there you know there goes your production API Keys Etc so vulnerabilities can be introduced through your supply chain leading to massive data exposures so it's absolutely important to care about it three compliance requirements we're starting to see that a lot of modern compliance standards are starting to touch on supply chain security we

believe that this is only something that's going to get more important going forward so it will allow you to get ahead of the curve if you are starting to look at supply chain now and how you can secure it and of course talking about getting ahead competitive advantages against patreon security isn't something that is really being discussed too much it has only really started so if you are dealing with it now it is showing that your company is mature and it is giving you know that confidence in your company in your organization with your customers your clients and your internal team and finally risks so mitigating those risks it's important that you do control risks during your supply chain you can

set up various technical controls different processes to manage this one thing we'll be talking about is a software building materials later on so if you're not sure what that is we will cover it but it's a great way to measure exposure on your attack surface and then of course third-party risks you know what happens if a company you rely on or holds your data gets compromised what do you do in that situation and that's some other things we'll discuss further on fantastic so looking at some case studies um I guess one instance where you know it did go wrong in the supply chain in the other time where it was fortunately caught so a little bit of a trigger

warning for anybody from Microsoft but we are talking about um so that's all the wins that happened about three years ago um it uh was essentially solar winds they produce a I.T infrastructure management system it was really popular about 300 000 customers at the time and essentially it did get targeted by a savior Espionage attack and as a result hackers did insert malicious code into a software update uh that was then pushed to about 18 000 people including Microsoft and the US government and a whole bunch of other people uh and unfortunately you know this did provide a back door uh into these companies um you know solid companies like Microsoft uh and this really

emphasized that even if you know a company's primary software is secure um third-party software can introduce major vulnerabilities um so definitely you know something to keep an eye out on um it was also identified that things like an s-bomb would have been really quite helpful in terms of mitigating what went wrong on flip side um again um we're talking about something that was found through bug crowds which is really awesome essentially what happened is a hacker an ethical hacker will say social engineered an employee account and is it able to place uh some proof of concept codes uh into a Docker image this is well within the Scopes and nothing unethical here but that Docker

image was pulled by the customer and unfortunately it doesn't you know hash verification and use and this did as a result allow the proof of concept code to be run in the production environment leading to the potential of a full compromise had this not been caught so fortunately that was found in bug crowds the hacker was paid out and the customer was able to fix that issue within 24 hours which is just fantastic foreign tastic we're going to talk about identification you we hear it all the time you can't protect what you don't know I'm just going to briefly talk about what an s-bomb is and I had to be very careful reading the slide out in the

airport um but a s-bomb is a software bill of materials it was derived from the bill of materials that is used in construction uh so essentially a bill of materials is an inventory of you know raw materials different components sub-components [Music] um or everything you would need for a construction project and we've managed to hijack this software again dangerous slides here at an airport while practicing and this uh yeah essentially use it in software and it's a great way to maintain the keeper list of all the different software components you are using in a project which is fantastic and I'm going to briefly talk about transitive dependencies so if you're not sure what they are essentially they are

dependencies of your dependencies so for example you might have a software project that depends on the python request package that python request package depends on URL lib3 and therefore as a result URL lib3 is a transiter dependency of your software via the python request package so you just don't need to keep in mind because we will be talking about that a little bit further on anyway I'll be now handing it over to sash awesome thanks right uh so what exactly is the solution to everything we've just given you basically just dumped a whole bunch of information but the reality is how do you actually go and do all of these different things and what we're

actually going to talk to you about today and the reason why we keep bringing up bug crowd is we're going to show you how bug crowd does it and how we did everything for a very small amount of money now the reason why we did it for a small amount of money is not because Bobcat doesn't have money or not because we didn't have money to spend we did have investment but the reality was there's so many different vendors out there and there's actually quite a lot going on in the space but no one's actually doing every single aspect of what we needed and in other words basically we'd have to either spend you know thirty thousand dollars a year

thirty thousand dollars there and screw ourselves over or alternatively we go and consolidate it ourselves and kind of pop in a bit of engineering and Ingenuity to make it happen that's kind of the way we ended up going so background just bomb and the way we implemented things we went with a bit of custom tooling so the general thing that most companies end up doing which is Python 3 a bit of golang and basically having a bit of fun with it we ended up using a lot of different open source projects to be able to go and kind of help facilitate our own um you know usage of things so we actually ended up you know bringing in parsers and things

like that from other places and utilizing it in the best way we can that includes you know if we're literally pulling up something like a go mod file and trying to actually pass it down and figure out what's going on there's actually Parts is already out there that you can go and utilize so literally importing those or forking them and then using those bits of code after they're audited to make sure that they're safe for our usage and it works quite well now the other part of it is um we're very lucky about cred because we are a small company we're about 10 years old um but the reality is we have epic Engineers where we actually have some of

them in the room today which is awesome um but they basically end up putting all the code in GitHub which means we have one single source of Truth and I know a lot of other companies basically have it a lot more spread out which makes it a lot harder for you so unfortunately we're going to go with the easy route which is our route and basically say that all code is scored in GitHub which means you can pull it all from GitHub API that's basically what we ended up doing we literally just wrote a bunch of different queries for the GitHub API and pulled all the data in found out exactly where all the different files are

located since you most files actually do have a common naming format so something like say go mod you know it's a go uh basically mod file and you've got everything in there same thing for like a rake file and blah blah blah you've got all the different things accordingly and you can basically then just go and parse each of these different files and utilize them and then create your own report now the way we do our reports is a little bit different we basically put it all into git repo so it's version controlled and the reason why we do this once again is it all stays in one place and it's nice and easy but the real good

Advantage is that it means you can actually go and get diff things meaning you can now find when something actually was introduced into your ecosystem so hypothetically you want to find out when a certain package was involved you just keep get diffing further down the line you actually find where that package came in just look for the pluses and you're good to go the interesting part of it though is as you continuously keep looking over and over you can also and kind of as this ecosystem grows out over time you could probably actually even do things like a few years Beyond because GitHub actually stores all of that data in one place so it's version controlled data retention

but you don't have to actually pay for it which is awesome once again comes into the shoestring budget now what we found honestly was bug crowd produces a lot of code which means that s form basically is megabytes um you know we're not like a Microsoft so we don't have humongous amounts of code compared but it's still megabytes for us meaning we have to find efficient ways to be able to go and search it um you know and actually go and import all the data and utilize it so that we can actually do it in things like incident response now the advantage for us was where a bunch of Engineers so we can actually go and just write searching

scripts and we did exactly that we pull up the data grab it in whatever way we need and we can utilize it within the incident response process now for the actual infrastructure this is all built upon it's actually done within GitHub action so we're trying to keep that entire ecosystem in one place and the good thing about keeping in GitHub actions is it's completely ephemeral meaning that you know the the action spins up it does the task and then it dies down and it's gone you have nothing else to maintain uh the workflows that we actually go are yet again version controlled implying the entire automation is version controlled every single aspect of that actual bit

of automation is entirely version controlled even down to the images and all that's being pulled from it is actually once again maintained by a reputed source like GitHub so it's also looking at our own supply chain security while doing this and also the S form includes the code being run inside for the S1 so it's like you know looking at itself too which is pretty fun um and then finally it also fixes a major issue around kind of data residency where the data all stays in one single place github's data stays in GitHub implying that it's an accepted risk over and you don't really actually have to look beyond that which is awesome now the cool thing is this

actually costs us peanuts um literally it cost us less than five dollars a month which frankly most businesses can afford and if you can't you should really look at your business model that's scary um but yeah cool moving on um we the reality is actually how many people here software developers can you put your hand up or has developed something you've got a good amount that's nice now keep your hand up if you can please pop your hand down if you were able to create something in a single hit and never got it wrong and didn't have to import another package cool so if you actually look at it there's not a single person has a hand

up implying that everyone makes mistakes and that's the reality I come from a software engineering background and um yeah basically the reality is people make mistakes and they install the wrong package or they do a spike or something and realize that things didn't go right so what do you actually have to do and the answer is s form for your endpoints so not only just your code bases not only your containers and everything running all your servers has to be all the way down to every single laptop inside your ecosystem and that's basically where things get very very different because not many people are looking at that space so a bug crowd we use this tool called OS query which is

basically creating a database out of your operating systems attributes it goes through and runs different extensions and creates these different data points puts it into a SQL like database a SQL SQL light database actually and then you can go and query it and utilize it in whatever way you need which is awesome now um the interesting thing is OS query itself can't be deployed without some helping tool so you need a deployment tool to be able to go and do that so once again both of those are open source which makes it cheaper for us but instead we go and contribute there which you know it's a win-win for everyone um the good thing is we can actually

host all of this in our own AWS and we do it for something like 200 bucks a month which is quite cheap compared to vendor tools obviously because you're looking at something like 30 or 50 000 depending on the size of your environment but for us it's scalable and it's very easy to keep within that 200 paradigm uh the interesting thing is it's not only just response you can also use OS query for things like insights and system performance you know monitoring the different processes you could virtually turn into a bit of an EDR tool um but you know I recommend actually using a proper EDR for that but whatever um but the interesting thing is OS query

doesn't go all the way it goes a certain amount of the way it doesn't have everything built into it if you actually try to grab like Ruby packages or something like that Oscar doesn't have that capability yet so what we ended up doing is we wrote custom extensions on top of os query and we basically deployed it into each of our different systems and that then started feeding data back into our database and then we were able to go and query it grab all of these different things and Version Control it accordingly now the next question that basically actually gives us a fully Dynamic s-bomb so we don't have to literally we don't pick up a

single finger everything happens automatically and it just feeds in the data which means our instant response team and our stock team can basically just sit down and go cool we're ready to go we don't need anything else and we basically just search data um now the really interesting thing is how do you actually go and store this data when it's actually changing so rapidly and uh it's going to cost a fair bit of money and the short answer is um you store it in a you can store it in something like an S3 bucket or whatever you really want but instead of actually storing it in such a manner we ended up actually piping it into our scene the

reality is the scene can hold a huge amount of data you know it's expecting over 50 gigabytes of data a day and some pretty hectic things so instead what we ended up doing was piping 50 megabytes 100 megabytes a day of just s-bomb data which is Json uh parsed by the scene into the scene which allows for foster searching allows for kind of version controls over the few days or years that we actually retain the data and then we can basically go and utilize it in whatever aspect we need so it's literally falling under your existing bills of your scene credits and whatnot if you use Splunk then great you can go and literally pop it into there and

you're good to go which is a little bit of a creative way of using a seam it's not intended but it works really well and once again it's free so even better um but we've gone ahead and built s-bombs in the entire classification of like all your different uh kind of assets there but now we're going to talk a little bit about the actual risks what do we actually do with all of these different assets and knowing about them just knowing isn't good enough and the short answer is we can classify them into three or at least there's a lot of different types of risks we're only going to talk about three but the reality is is risks literally everywhere

and we're going to talk a bit about all these different types so the first one is author risk now that's basically the risk of the author doing something wrong or something going wrong with the author like directly related to said author now the malicious push risk at least we Define it as such is that and author goes and actually pushes something malicious in and when I say pushes I basically mean the action of introducing new code into the package which thereby goes into the package repository so something like pipey and thereby propagates into every single system from there so if it's new installations or upgrades or something like that it's as simple as just following the ecosystem

system but who's actually watching what's going on in every single package being introduced think about that there's not many people actually watching it do you actually look at every single upgrade that's going through every single time someone goes and clicks a button and introduces a new actual um you know package inside your system or upgrades it the answer is no no one is or usually not on top of that a lot of places use the at the latest tag which basically just pulls the latest version of whatever package or whatever image which can thereby actually open yourself up to different types of risks now moving on to actually the concept of author compromise which is basically

sometimes accounts get compromised people get compromised things happen um so if the actual author gets compromised what do you do um you'd hope that they use something like verified commits or you know signed commits and if they do great you're able to verify that it came from their system and that means it's likely legitimate unless their entire system got compromised um reality unfortunately most people don't because open source software is basically just a heroic effort people are going and doing some epic things to make the entire ecosystem last now unfortunately since that isn't the case we can't really go ahead and do some you know that type of triage or automation to be able to go and keep this entire

thing alive um doing so you basically have to keep monitoring and making sure that's nothing new is being introduced once again be allergic to things like Atlas at latest or not defining a version especially for things like python uh purely because it'll just pull the latest thing and uh we also wanted to give you a bit of an example of kind of what an author risk might be now I'm hoping everyone's seen Shrek before and it's like you know ergors have layers onions have layers that entire aspect it's the exact same thing where the the actual author's ecosystem is a part of your ecosystem implying that if they get compromised you are likely going to get compromised

too it's an upstream compromise and uh the idea is a lot of these different authors actually go and have their own email addresses created um you know it could be custom domains or you know some kind of weird web server email server maybe they're hosting it on the best Trends email server and they get compromised to something like that but there's ways that it can actually Upstream back up to your ecosystem in your company so you always want to look at author risk and author reputation um so you know hypothetically if I had a domain and um you know I accidentally let it expire someone comes and registers the domain Pops in a new email uh you know email

records or DNS record or something like that inside the DNS Zone then they can route all their emails say if I had mine going to Microsoft they route it to Google they can now basically intercept all my different emails then all they have to do is go to npm or Docker Hub or something and click the forgot your password button literally just go and get a validation link and walk into my account obviously if there's MFA things are a little bit harder but it's not necessarily impossible MFA bypasses exist as a vulnerability class on purpose so um that is a very very significant way that things can get actually compromised and you want to keep an eye on it

now we're going to actually change from authorisk into maliciousness risk now the reality is malware is out there you know things actually are kind of going around and people are going to continuously keep making malware I mean it kind of keeps our entire industry alive um now the good part of it is that it gives us strobes the bad part of it is it makes us actually work for a living but type of squatting is basically a very prominent thing in all parts of security now in this case all you have to do is accidentally miss the U.N requests and you'll go and install the wrong package and then you accidentally basically deploy someone else's code inside your

entire ecosystem and it could be game over uh in that same way we have the same general homograph attacks that you would normally see in any other place so you know um it would basically be using Unicode within the package names to be able to make it look different um like as you can see down the very bottom uh we have an example there which is actually from a Blog where inside the blog they explain how to use Python flask and um the command that they actually give you is PIP install flask but can anyone tell the difference between the two flasks yep the a okay you're close but it's not only the a it's also the s

um so it's the A and yes but the reality is if you paste that into your terminal you're probably not really actually going to see it um or at least if you're trying to go fast you're not going to realize it especially if your terminal supports Unicode um and uh then you're just shooting yourself in the foot but the reality is that's all you need to basically get compromised and that's scary because your developers are going to go and read those blogs because they're actually pretty good resources too um but yeah basically now we're going to move on to the next part which is dependency confusion which is kind of changing a bit attacked there but the

idea of dependency confusion is basically installing different types of um packages which generally are supposed to be inside an internal source so you're looking at different things like say from Google or something like that hypothetically Google is developing their own python packages and they basically install from their own registry when they go and do that it's um literally just going you know the developer's computer goes and pulls it from the registry and then installs whatever and does whatever they need to um then hypothetical particularly if the developer's endpoint is actually misconfigured it'll go to the public repository first and then the internal source and then basically you know wherever it needs to go now the fun

thing is if it goes to the public place first and the user actually goes and registers that package and puts up a malicious package it's game over once again and there's actually been a lot of different examples of this if you look at the Bounty space and look at like you know the crowdstream reports and stuff you'll see a lot of different examples of uh these different cases coming up and it's kind of scary but it's actually a really fun way if you actually get a chance to do it yourself look at you know public code see if anyone's got any internal package names that you can kind of go and register register it if that's

assuming you have permission to do this register it and then um you know watch them pull your own package in and we did one recently where basically we had one and a half thousand downloads from the company and that's basically one and a half thousand endpoints compromised and we literally just went back and said hey this is a P1 pay up and they did so it was really awesome a very very fun way to actually go compromise organizations and back to you right fantastic so the last book we're going to talk about is vulnerability risk and it's probably the one we hear about all the time and that is did you patch yeah um so have you updated dependencies

of course we have talked about the dangers of updating your dependencies if you aren't you know verifying those updates um but it is always good to update your dependencies because you know those updates will fix known vulnerabilities or any CBS that have been found in those packages and of course there are things out there like dependent dependabot it's a really great tool that can if you are using a GitHub environment can assist with updates uh just something to keep in mind is the safety of transitive dependencies so we did touch on it before uh essentially transitive dependencies is a dependency of a dependency um and of course they're compromise doesn't matter how far down the chain is

your compromise it could lead to your compromise and of course that will depend on the context of how it's used but it can fully compromise an application environment often so you know for example to something Food For Thought imagine if the request library in Python was compromised how many different things would be compromised as a result so just something to keep in mind when you are using dependencies also to be thinking about the dependencies that they use but of course we didn't come here today without a solution um so fortunately most packing managers out there allow for things like hash Integrity checks as well as version pinning so this is a really great way to

ensure that you're getting your packages from the right place and that it hasn't been modified um and then of course version pinning you know not using that latest on things we did see that bug crowd the thing found through the blood Cloud platform that was done because the customer was using the app latest on an image so they weren't seeing what was coming in and so it's like updates to that image and as a result they did get compromised because there are a number of different tools that you can use out there that are free and available to assist with finding all these different I guess vulnerabilities and risks a really great one is phylum we've been working closely

with their company they're solid people and essentially they're a new tool geared at identifying vulnerabilities and risks particularly in software dependencies things like outdated libraries insecure versions typo scrolling they're fantastic for that as also maliciousness risks they've got a whole research team behind that which is this fantastic you need to have OSB where you can find Dev essentially that is a vulnerability database and triage infrastructure that's really good for open source projects and finding I guess known vulnerabilities on there or at least telling you about it it does have an API which is fantastic so it means you can build some custom tooling off that uh simgrip is a really fun tool that we started using a lot um if you get a

chance to top Sarge after this talk um it is a static analysis tool that is used for finding bugs detecting vulnerabilities and third-party dependencies you can enforce even code standards with it it's got a lot of granularity which is fantastic and that is also free um you know you don't have to use the paywall features it does a fantastic job there is guard dog that's the CLA tool that's really helpful for identifying malicious pipei and npm packages it actually uses sound graph in the back end but that is a CLA tool and as a result you know you can automate it and you know have it scanning things that you are using and final finally we did

already talk about depend about if you do want to get ahead of the curve of course we want to talk about threat intelligence so you can pull data from sources like GitHub advisories essentially is a security vulnerability database inclusive of all these different CVS that have been found in the world of Open Source it does have an API and it does able to identify some malware which is fantastic so something you can build into your tools we did talk about them before they are working on a certain intelligence feed so you could use them the other thing is behind a payroll but definitely something to keep an eye on in this pie chain area and then of course custom tooling what

we recommend uh you know you can kind of string all these different things together to build your own tools to get some threat intelligence and as a result of all these things you know s-bomb um the hash intelligence version pinning the threat intelligence all these free tools is actually what we use and it does a fantastic job for us um at bug crowd uh so I highly recommend looking into it if you haven't you know dabbled too much in the supply chain area so that's your hand about to search awesome so basically at this point you've gone ahead and implemented a good security standard and you actually know what you're doing which is awesome the

reality is you can still get compromised and this is basically the oh case um at some point in time you're probably going to get popped and it's scary now um pretty much as Security Professionals it's part of our kind of ethical obligation almost to go and have plans for things like this it's um I mean it is actually a compliance requirement it's legislatively required to but um ethically I strongly recommend doing it um the idea is trying to sit down and actually go and say okay what do we do when something like this happens when hits a fan and uh the reality is first always go into I'm sorry we're running out of time so I'm going to

speedrun this but we're starting off with monitoring know exactly what's going on if you can identify impacts of whatever is being compromised if it is actual information and if you do that kind of assessment and see it's severe enough contain always contain and then try to figure out what the actual impact is something that we actually strongly recommend and we're very lucky to have an epic engineering team they have everything done in infrastructure as code which means hypothetically if we have to rebuild our systems it doesn't take us that long it's like less than 10 minutes um so we basically just tear out the entire dependency figure out whatever is necessary and then we basically just

spin it up and go again and so containerized so for us that's a win I strongly recommend it to everyone to see if you can actually move over to something like infrastructure is code because it will save your life now removing from endpoints is a little bit more difficult because sometimes malware might actually backdraw into your actual operating system or screw you over in that way and if that does happen just removing from an MDM might not be enough you might actually have to go and completely start cleaning things up and nuking things so be wary of that um now very very quickly uh the final part of this talk is showing the money which is how do you actually solidify

your investment now it's you know you've done some really epic technical things how do you actually go and uh show them what is going on and why you're doing this the very quick answer is that the management team needs to see the impact they need to see why they're spending money and um what we've actually done about crowd is we've used our buck banning program as a benchmark and basically said all the different risks that we identify be a p ones p2s whatever critical all the way down to informational we give it a dollar amount in the Bounty program so we use that as an absolute minimum amount that will cost the company um that way we can actually

mathematically prove exactly how efficient our actual security team is so we literally take that amount and take our salaries and then match them up and say hey we saved you more than our salaries we need more investment trust me you want to spend it and we've pretty much never heard no um so trust me it works it's really good I strongly recommend it and it actually shows off a competitive event because if you can mathematically prove your security posture there's not many places that can actually go to that amount of maturity and basically show it off so it's really awesome and I strongly recommend it um now to wrap it up we've talked about a whole bunch of different things in

supply chain security and I really hope that you get something out of it and enjoyed this talk and we're pretty much always going to be around for questions and you can hit us up on Twitter or something or LinkedIn if you do have questions and we're more than happy to answer thank you