← All talks

Elements of an Effective Software Supply Chain Strategy

BSides NYC · 202349:4957 viewsPublished 2023-06Watch on YouTube ↗
Speakers
Tags
About this talk
Attention to securing the software supply chain has escalated in response to software supply chain attacks such as Solar Winds, new standards in regulated industries, and new government policies requiring that software producers attest that their supply chain is secure. How do you secure your software supply chain? And how do you attest to that to your customers? In short: it’s complicated. It’s not as simple as just issuing a Software Bill of Materials (SBOM). To better understand this problem space, we surveyed where attacks occur in the software supply chain and what the new standards and regulations will require with respect to software supply chain risk management (SSCRM). We then defined twelve essential elements to a successful SSCRM strategy. This session presents the results of our analysis, then describes each of these elements and which ones are most important to software producers, procurers, operational IT, and risk/compliance teams.
Show transcript [en]

what I'm going to talk about is software supply chain risk management but the abstract that was in the uh in the tracker it says it's about s-bomb that was another presentation that I submitted and the organizers said to me we have something on s-bomb but we saw this article that you wrote in information week about the elements of software supply chain and we'd really like you to talk about that I said fine but so you got the wrong abstract I hope you're still interested in the topic my name is Anita D'Amico and I am at synopsis for those who aren't familiar with synopsis synopsis is a publicly owned company it's about five billion dollars it is a semiconductor chip design

company primarily but there is a small business unit about a half a billion dollars which is all software Integrity it's called the software Integrity business unit and it is all about application security and securing your software and anything related to that both services and products and uh I am fairly new to synopsis I'm the vice president of cross-portfolio solutions and strategy so I'm dealing with big problems like software supply chain risk management and uh that cannot be solved by any single product or service that it really takes in integration of a lot of different people processes and Technologies in order to solve that problem so that is my mission I came to synopsis in June of 2021 when

synopsis bought my startup so I mentioned that because for those of you who are parts of startups and you want to know what that journey is like I have lived that Journey I started out with a 99 000 six month research project that was funded by the Department of Homeland Security and grew it over time a lot of it's funded by grants but not all of it bootstrapped it uh we spun out a company we got Venture Capital which is not easy and we got venture capital and we were about to get our second round when um synopsis uh made an offer and So for anybody who wants to talk about what that journey is like uh I would be happy

to share all of the uh all of my experiences they say that uh VCS only like to fund uh CEOs who have been down the that process before and now I understand why it's it's difficult the other thing I wanted to tell you about uh myself is that I don't have the typical background of probably many people here that PhD is in experimental psychology and it just goes to show that you can you can you'll have a career in this field no matter what your background is and then Ariel's here and she has a cognitive Science Background as well um and uh so I mean we could talk maybe in the Q a if you want to know what you

know how I got involved in that or what the relationship is between psychology and software supply chain risk management but you know I'd be happy to to tell you that story so that's just a little bit about myself and um and now I I'd like to talk about what is involved in securing a software supply chain so let's get started everybody's talking about this it's in the media it's uh in conferences they talk about software supply chain security and s-bomb s bomb is like everywhere now that's software bill of materials but what's it about well I want to first of all talk about the software supply chain because one of the questions that I get is well isn't

that application security so let's take a look at it the supply chain is like any other manufacturing you know supply chain whether you're manufacturing software or cookies to some extent and there's a design process where you have your requirements and architecture and threat modeling and then there's the development which is the manufacturing process you have an assembly line which in the case of software is your devops pipeline and you have the parts and the parts are your custom code uh your open source and those other third-party pieces of software that maybe aren't custom or open source but they come from someplace else and when you look at the supply chain you know who your developers are

of custom code you sort of kind of don't know who your open source developers are you know something about it but they're largely unknown and you're a third party software commercial office sales off-the-shelf software has known suppliers but you don't necessarily know where that stuff came from and and so then after you've developed um You release now I understand that there's continuous release Cycles you know this this kind of iterates around but let's be simplistic and say there's a release where you have your executable code but the supply chain doesn't end there uh it it goes into deployment and your software inherits certain risks from its deployment environment whether it's mobile or cloud or on a server or even a

cyber physical system like an iot system and then there's also other stuff that gets pushed into the deployment there's other third-party software that comes in and then finally there's the maintenance where you have upgrades and patches and so that's kind of what the chain looks like and the important part about this is that every single Link in this chain can be compromised if you look at the well-known uh attacks that have happened in let's say the last five years there are all different parts of this chain so uh there was there was code Cub it's a code coverage tool um that uh that that was hacked in there were about 22 000 customers that were

affected um you have the log for J vulnerability which was subsequently attacked and that's in there and that that was throughout the supply chain and then there's solarwinds solarwinds was a big attack and that's actually the one that got a lot of attention from the federal government because it went right into networks and it was a software supply chain attack that resulted in major breaches and networks so every link can be compromised and if it's compromised early on in the process the impact is felt later on in the process so why is that the only reason that this soft that was getting a lot of attention well no I mean there's the attacks there's vulnerabilities open source software

um the fear of litigation standards and and a lot of uh Federal uh procurement and Industry procurement requirements so let's just take those apart a little bit this is why there's so much attention being paid it's a software supply chain so the first is the attacks you know we I just mentioned a couple of them solar winds not pet yeah log4j um and vulnerabilities like log4j it was a vulnerability that was uh in open source software and that was in 50 of all Enterprises so when this vulnerability was discovered in log 4J 50 of the Enterprises around there were running around saying do we have it and what are we going to do about it and as soon as it was

announced there were all kinds of exploits that came out and uh that 40 of global Networks were uh there were attempts to exploit them assume within just a few days uh log4j vulnerability being announced and semantic blocks 93 million exploits in the first 12 days following it so just knowing what your vulnerabilities are is important and then the thing is getting a lot of attention is open source software 96 of code bases contain open source software and in fact there's an average of almost 600 open source components in every application and you don't know who the developers were there's there's a limitation on how far back you could get go into open source in terms of

provenance which it still makes it worth it to bring the OSS in but you have to be aware of what the risks are in fact 84 of those open source components contain at least one vulnerability and about 48 percent have high risk vulnerabilities so when you bring open source into your supply chain into your software you are inheriting those risks and you have to be able to find those vulnerabilities before you incorporate it replace it with a a component where it's already been fixed so these are some of the reasons that people are getting so excited about software supply chain and then there's the fear of litigation if you have if you have not taken good

practices in trying to secure your software supply chain and something happens with that software you may be liable but even the easy stuff like checking licenses is something that people will get litigate over and in fact if you look at it you'll find that 54 of code bases have some kind of license conflict or or uh improper licensing and so the lawyers get excited about it and then finally and this is what's really driving um the market you know the the people who are interested in in making money off this is there are standards that are emerging in verticals like Automotive medical devices where they're saying you know what you have to secure this and in fact

good thing I mean if you have an insulin pump right you want to make sure that the software that is in there was secured throughout its development and so there are now regulations that are coming out in standards in these regulated Industries but also the big thing that has changed is that in 2001 or 2001 2021 the federal government the there was an executive order that said we're getting sick and tired of this you know these software supply chain problems on on our federal networks and we are one of the biggest purchasing powers in the world and we're just going to start requiring that you secure your software and that you secure your total supply chain

before you sell your software to the government and since June of 2021 slowly what's been happening is that different parts of what you need to do to secure your software has been coming out so starting in June this June if you are selling software to the US government or you are selling software to somebody who is selling software to somebody who is selling software to the US government right you will have to conform to certain guidelines and I'll and I'll talk more about that in a few minutes but that's what the big deal is about you might say well okay so it's the federal government what does it really affect see all that stuff in blue that's what

it affects when you go look at the guidelines for what you have to do in your software supply chain to make sure that your software is secure it is affecting all these things threat modeling everybody likes to say oh yeah threat modeling is so important but like we don't do it right right yeah we did it last year right well these these new guidelines are saying you need to show your threat model and the requirements and track that then there is the the parts okay now I'm I'm in at synopsis we do we build scanners that scan custom code and open source and all that there's plenty of business now that's been going on for years for

decades but securing your devops pipeline being able to attest that your artifacts are secure and that they have been tamper resistant is is part of of this and then you get to the release now this is where s-bomb comes in because when you release your software you will now be required to basically produce a parts list and that's what a software bill of materials is it's a parts list and it's not just the parts of open of Open Source which is what most s-bombs produce here's all your open source components you have to show what's in your custom code what came in from from that third-party suppliers and and do all that and disclose vulnerabilities

and there's and this is a big thing because do you disclose do you really want to disclose what your vulnerabilities suppose that you have taken who have taken good practices to ensure that that vulnerable piece of code is never called is that does that stop do you have to disclose that right so there's all kinds of things going on with that and security at testations this is a big thing if you take nothing else away from this take this away that it will not be enough to secure your code to secure the pipeline to make to do check all your vendors you have to attest to it so somebody in legal right right is going to be on your case going

did we do this do we have evidence of this so um that's part of the requirements and then it percolates the these uh new standards and procurement they percolate through to there's certain things you have to do in the cloud and you have to be able to automatically monitor vulnerabilities in code that has been released so now you receive code you receive a product you're going to have to monitor it to make sure that if the next log for J comes out whatever the next one is that everybody gets four I didn't know there was a vulnerable you know component there that you have to be able to scan all your your s-bombs and know that you got one of those and and

you have to have a certain SLA to fix it so that's what the fuss is about and s-bomb which is what's getting all the attention is just one part of this so people say to me well isn't this app SEC isn't this application security you know this is like what we should be doing yeah sort of not it right um because it's this part over here uh where you have the purple where you have Architects appsec managers the dev team they're the ones who are doing that that software security the appsec part you got a whole nother set of people whose hair is on fire right now about about software supply chain you've got the CSO who has to report to the board

right because the board is seeing this stuff going what's all this stuff about well we have risk the risk officer the risk officer is that person or the person who is the product security incident Response Team the piece here one of those is going to have to attest that yes our product has gone through all this so they're you know they're on the line you have your I.T operations people who are now inheriting they realize I'm inheriting all this risk I you know tell me that it's not there you know and and prove to me you gave me this s-bomb you told me this is the list of ingredients how do I know it really is prove it right so you

have all those things going on so there's a lot of people and and now involved in this that weren't there when it was pure application security um before I move on are there any questions right now before yeah um

[Music] so the question is of those 54 um that have license conflicts how many turns the lawsuit I don't have an exact number but I'm going to tell you probably very few and that's because it gets flagged it gets flagged I it license a good I mean if you're doing a good job you're going to um flag it so let me give an example I'll tell you where that number came from all right synopsis has a a small business that is purely for mergers and acquisitions and before a company is going to buy a Target right uh the big company's buying you know the smaller company or any size they want to make sure that they're not

going to inherit any legal problems so they come to synopsis and they go you they we become the third party like you know uninvolved right and we take their code and we check it for things like license compliance and and and then we oh and we do thousands of these a year and and so uh and it's called black duck right and and so they um so if your code's been black ducked that means that you know it was scanned and when we looked at all those we found the 54 of those code bases had licensing issues now the pre-acquisition Now The Inquisitor the the one who's acquiring is going to make sure that all of those

are fixed because they're not going to inherit that legal but that's how we know that's what the number is and they're the ones that somebody has gone through the effort of auditing you don't know how many didn't get audited um so this is kind of complicated and people when I started looking at software supply chain risk management maybe about 15 months ago um I started saying this is like my head is spinning my head is spinning and so about 15 months ago I said what is it all about like are there just a couple of things that all this gets distilled into and I first I came up with like 10 things and then I I basically circulated around and for

like the last year I've been presenting you know this to various people and no matter who I presented to like it's only we've only added two things over the course of of 15 months to this list and almost everything fits into this so that's what I'm going to go through so I'm going to group these by who should care all right if I gave you 12 things you go that's just too much you know head in the sand and I'm not going to deal with this but really it depends on who you are so if you are the operational people the I.T people of all these 12 things here are the three things that you have to pay

attention to the most and that is asset inventory you need to know what software you have and when you do this you're going to find stuff that you didn't know you had you probably don't want s-bomb you need to be able to produce and manage the software bill of materials that's the list of ingredients and basically if your operational I.T you want your supplier to produce it and you as the it operator need to manage it and by the way you're not just going to get one s-bomb from one supplier you're going to get 10 000 of them so they have to be put into a repository and indexed and queried for every time there's a new log for J that

comes out you need to be able to check that by Deepa [Music] so it depends on how you negotiate what what s-bomb you want like it could be that the that the supplier only has to produce an s-bomb for major releases yeah so so um there are so that so that's something that is between the supplier and the pure as to which ones you want um that you know that's it and by the way we'll get into it but there's a whole bunch of different types of s-bombs depends on when you produce it as to whether or not it changes a lot yes [Music] [Music] open source and third party is absolutely essential but that's not a

fine enough uh granularity you need um what um people want to know first of all who the supplier is when you produce an s-bomb you need to know who who the supplier is you have to name the supplier but it is either people want to know either where it was developed and and often they want to know what country because of export laws and and that becomes a legal issue you know certain certain places you can't develop you you you can't bring in code that was developed in Russia for example or North Korea uh China and and so uh depending on who who was procuring the software there are different rules about that so you have to be able to mention that

provenance hey the next three the next four is if you are a producer of software you better do this yeah this is like you have to do the other stuff too but like this is where you want to put your attention a secure development environment you need to secure that Pipeline and the artifacts you need to be able to um attest to the Integrity of the software that it was that hasn't been changed that hasn't been tampered with you need quality quality control are there bugs are there bugs in it uh are there reliability issues and and then security uh you know what are the security issues so those are the four that's your pretty much

standard appsec you know bread and butter then if you're the procurer here are the things that you want to ask um of course you want your rest bomb right but you want to know about Regulatory non-compliance and I say non-compliance rather than compliance because you can never actually prove compliance that you could prove non-compliance and and so you want to determine if there's any obvious non-compliance with regulations or with industry standards licensing non-compliance we already talked about that that's a big issue and unexpected functionality is there something in this code that I wasn't expecting it could be malware but it doesn't have to be it just could be hidden functionality maybe it's calling home and it shouldn't that doesn't mean

it's malicious but but you want to know about hidden functionality and then the last thing are the governance people your risk officers your legal people they want to know do you have a policy if you don't you got to build one and did you conform to the policy it's all about conforming right it's all about attestation you had a policy everybody agreed yep that's a good policy it's a best practice if you've followed it things should be pretty good I mean like 90 there right you took reasonable you know caution but you have to be able to demonstrate you follow the policy and and report it this goes back to something I think Ariel that you were

talking about earlier is you need to be able to put the information in the form that the risk officers understand and can read and so there's the risk management reporting so that's it those are the 12 things that are involved in the software supply chain and all the attention is being given on s-bomb and that's just one of them uh it touches the other things but that's just one so um let's go on a little bit more into s-bomb because everybody's talking about it what's an s-bomb it's a list of ingredients it's the list of ingredients that's in the software and the depend that your software depends on and that those components that are in your software depend on and

that they depend on and that they depend on right so that if you have a component that calls five things it depends on them you have the list then and if the each of those five things call another five things you have to list those and so you have this tree um so that's really what an s-bomb is now many places only produce an s-bomb for open source because traditionally that's open source is most of your software so you know if you produce an s-bomb for your open source you've covered 80 percent of your application but nowadays what people are asking for is what I call the full monty that's bomb reveal it all just let it hang out right

um the you know it's got to be open source custom components that uh you know your proprietary code your base images you know uh and your firmware and your third-party libraries that might be commercial or freemium all of that has to go in and you have to have those information about the transitive dependencies those that chain and the licenses all right so you need to be able to put what the license situation is and it has to be in a standard format there are three standard formats two of them are really popular the other one swid is yeah it's I hope there's nobody here is a big Swit proponent but um okay 90 of it is like cyclone and

Cyclone DX and spdx Cyclone DX was started by the OAS group and spdx by there's an spdx Foundation Council and you can almost any good software composition analysis tool will generate an s-bomb in these formats what you want is one that's going to give you a comprehensive full monty s-bomb and so that's what you need to have for an s-bomb all the stuff in a standard format now depending on your industry someone a little bit more someone a little bit less like there's six minimum Fields but if you're in automotive they want to see this if you're a medical devices they want to see that so there are there is there is a tailoring to the

s-bombs and you should be able to get a sulfur composition analysis tool that tailors as well now one other thing about s-spons is that there's different types there and in fact I built this slide before yesterday because yesterday the Department of Homeland Security came out with a document that actually lists like eight different types of s-bombs right so I have to update this right I mean I knew they were coming out with it and so this we built the slide kind of based on that but then they really came out with like okay and and so like sometimes you want an s-bomb that you've done you do during development for development purposes or build s-pump most people

are asking for a packaging s-bomb which is you release your software here's your here's your picture there you go but some procures or some I.T operations people want to actually know I want to know everything that's involved in that software in its runtime environment what is actually in that when it's running so that's a run time so I'm not going to go into any more detail but just be aware that not all s-bombs are created equal um I want to spend a little bit more time on attestation because this is the thing that if you are developing software if anybody here is developing software and you want to sell it and make money at it

somewhere along the line it's probably going to wind up you know if with a big purchaser like the government or some other really big companies right if and you're going to have to know this because the government and Industry are requiring self-attestation at self-attestation means I swear honest I swear that this was developed you know in according to good practices and so I I can't just say yeah yeah it was developed they want to go well did it do this did you do this did you this so what is that well all of this started in June 2021 with president's executive order and they said you got to attest so then people said well let's test to what they said

wait we're going to tell you and in 2022 the National Institute for standards and Technology nist issued a document called the secure software development framework ssdf you're going to hear these these letters ssdf ssdf says here's what you need to do and while the government hasn't actually said yet um it's this this is the ssdf that you're going to have to attest to they haven't mandated it in law almost everybody thinks that's what they're going to do and they have to do it by June all right so if you wait like you know just eight weeks you'll you'll know whether or not I'm I'm right or wrong okay um and so that so so that's one of the

things if you are selling or or if you have an interest in medical devices then the FDA has its own set of requirements so those insulin pumps and and um those MRI machines and whatever it is anything that is connected to the internet in any way or is in any way connected the FDA is now has a firm set of software supply chain requirements that you will have to prove the government is just asking most of the stuff on the left is just self-attestation the right FDA is saying you know when you bring that truckload of documents in for your medical device approval well that you got to like have all the evidence in there that shows

that your software supply chain was was uh secure so what's in this thing it's really it's not rocket science I mean you're going to look at this and you're going to go yeah really prepare your organization okay yeah have the right culture um protect the software so make sure that you know your your software and you're developing it and it's tamper-proof produce well secure software uh perform testing on it make sure that you bring in Secure reliable components and and then respond to vulnerabilities and they're getting a little bit tougher now and that you have to and demonstrate that uh you will be able to find vulnerabilities in production and remediate them beforehand and find stuff

afterwards and of course it's the government so it's never going to be just those four things each one of these four things has practices like this one right here produce well secured software has nine practices and then they have tasks but they even give you examples I they they say you know you want to know what we mean by this here here's an example you need to um maintain a list of organization approved commercial software components right and a lot of it is you know maybe stuff that you haven't been doing but you should be doing well now this is saying you're going to have to attest to this so that's all I wanted to talk about

attestation just know that it's gonna it's gonna be coming and it's you know and it's probably going to be there forever eventually it'll probably go from self attestation to creating an audit Trail but they're crawling before they walk and walking before they run um any questions before I do my three predictions for 2024 yeah go ahead um

[Music]

what Regional affiliations oh

[Music] yeah I mean the procurs are very concerned about that and not just the United States we have international customers I go into those International customers and they're saying number one I mean they want to know provenance like they they you know they'll have a dashboard of what country this stuff is coming from yeah it's really important [Music] another question yep

um

yeah you know it's it's being handled even on the government Side by procurement and but except that that the federal government is actually saying is to make it easier in everybody we're going to have every agency in the government use the same procurement language thank God right right I know is that but but what we're seeing in Industry especially regulated industry I and I I'm not as familiar with financial services but I'm pretty sure they're going to do it in financial services they're certainly doing it in things that are related to personal safety you know so things you drive for example you know that that type of thing um that uh that they're going they're

putting it into contractual language and it and it works its way through procurement yeah Manish um [Music] now you have a bunch of things that you have to sort through again and prioritize um

yeah so that what you're what um menacius asked was asking was how do you control what happens when you get all these s-bones so very good question we've been thinking about this quite a bit talking to a lot of people about it and every uh certainly Federal contractors have because they they stood there going to the federal government so we're going to give you the cess bomb what are you going to do with it what are you going to do with it because that will determine like you know what we put in there and all that and and by the way what you put in there is very important because do you do you want to put in the fact that you

have a component from a from a contractor who you have a private relationship with I mean there's certain ways that an s-bomb could reveal business relationships that you may so so there's all that kind of stuff but anyway the um the when you the the big issue is what do you do with all these s-bombs and what we're calling that is s-bomb management and there is work now going on to automate that entire process the Department of Homeland Security has weekly working groups I mean they've been meeting every week for over a year I I sit in on these things and it's people from all over the world or industry you know to talk about all

those things like everybody in this room is raised how do we do this and here's what people are saying we need a uniform a uniform way of sharing the s-bombs and so the first thing is how do you get the s-bomb does somebody deliver it to you or does the supplier post it in a in a controlled environment that only certain people have access to and and and if you have the credentials you pull it all right so you have to be able to get it to to the picture then the procurer has to have a repository set up to receive all this and you probably don't want it to be a flat repository right you know I mean these

s-bombs they're they have a hierarchy to them if you are an automotive manufacturer and you might have your infotainment system well that's comprised of you know your your mapping thing and and your your uh Apple play and this and so and then each one of those has an s-bomb and each one of those has s-bonds so you kind of want to maintain that hierarchy so that you you know that if this thing at the top has a problem you can um go down the tree or this thing on the bottom has a problem you can go up the tree so you want that as you want aggregation you probably want to maintain the hierarchy you also

need to be able to query this repository to say I have 10 000 s-bombs which one of these has this new vulnerable component that just got released the new CDE came out I gotta find all these things right you got to find all them see who who who delivered them to me I have to have a system to go back and contact all those suppliers and then the other part of it is what I just talked about was querying it like pulling that information wouldn't you want it to push information to you wouldn't you want it to automatically like you know go through all of those those cves and say oh there's a new one

let me go through oh look that one right there it operator you know has it so those are the kinds of things that are really in the very early stages very early stages of being developed internationally um you know I talk to big companies around the world and these are the kinds of things that and expect that to be a really boom of Automation in the near future So speaking of the future my predictions for 2024 the first is that s-bombs will be required by almost all Industries and almost everywhere around the globe producers are will need to produce and disseminate those s-bombs procurers will need to receive them and verify that they're accurate we haven't

even talked about that verification and then manage them which we just talked about and that the operations the it operations will be able need to be able to regularly use that s-bomb data in vulnerability management which is what I just talked about second prediction attestation you're going to have to attest that your your software development processes were secure that your supply chain is secure and that you are ready to respond to post-production discovery of vulnerabilities and then the last one is the impact on business this is not just a technical problem this is hitting at the board level there this is considered a business risk because for a couple reasons one is that if your supply chain your

software supply chain gets attacked you're going to lose money you're going to be out out of business for a certain period of time so you're going to lose money you're you may or may not lose reputation uh but it's it's going to affect you and so it's considered a business risk from that perspective it's considered a business risk from a liability perspective for the things that we talked about before and so it's getting attention at the highest levels in an organization and it's going to be considered a business risk and the governance people are going to come in and basically say okay how do you control that risk well we need policies we need conformance to the

policies and we need to be able to attest to that and then we're kind of covered at least legally so those are my predictions um I'd be happy to answer any other questions that weren't asked and there's how you can reach me [Applause] yep

because of the velocity of change they'll get more what the velocity of change your album software no I didn't hear the first part they'll get more what even more distracted by them

yeah the um so you need I I agree with you that you know it can be very distracting but that's why I think that it's going to be automated fairly quickly I this is it's not rocket science how to automate this I mean it's a soluble problem it's just that people have been doing this manually before and and at a smaller scale it's never been scaled up like this so it's uh you know I think it's just going to be automated just think about a car recall system right you know the parts recall in a car they can track you know a 1998 VW right you know and what part was you know became an issue

and then do a recall notice and so you know it's going to be that way for software uh back there um [Music] so you're asking are there tips for a developing software company that doesn't have what did you have any test scores [Music]

it depends you know it depends on who is using your code all right so and how important it is to your business so if you are developing something that is in a regulated industry you are going to have to bite the bullet and and do the things that are needed you know spend the money because you're not going to survive you're not going to be able to sell in that environment if it is software that is not in a regulated industry then um it really depends as minimum you should have a pop you have policies somebody should spend the time to have a policy in place and and that and the software development team should understand what

that policy is and everybody should buy into it I was going to say you should have a security Champion but when you have a really small team I've been there I've had small small teams and uh you know at a startup we had like nine you know nine ten developers but um you need to have everybody be aware of of it and be part of the security process and then finally there are open source tools out there which aren't as good as as commercial tools but they'll get you someplace and and check your code with the open source tools and um so that at least you have some exposure to this and your software development team understands that needs

to be done yes

in our industrial control systems years old so the initial government information said that they were going to go back to 2021 I think um you know but I I think it's really I don't have any inside knowledge in this but I'm going to having worked for a major Aerospace company many years ago and for understanding how these things work I think that they're going to start with the mission critical systems if you're a weapon system they're probably gonna want this right so it's going to start with the mission critical systems and then work work its way on the other hand they may take the they may take the idea that well one of the biggest software

consumers in the United States is the Veterans Administration right and you know maybe you maybe you start with your biggest footprint I don't know

[Music]

liability is going to be at the company level and Jace is telling me I have zero minutes in that I am done it says done [Laughter] [Applause] thank you very much