Beyond The Code / SBOM: Supply Chain Security

good evening everyone I hope I'm audible to everyone all right so let's cut to the chairs and start uh a quick introduction about myself uh my name is Anand shav I have about 15 to 17 years of corporate exposure ranging from being a server admin to being a developer to being a information security professional to now running my own small company so bunch of different areas that been explored I've been a speaker and trainer a bunch of different conferences I like to do a lot of Open Source work so there are a bunch of different open source projects that I run uh primarily uh code Vigilant where I do source code audits for open source projects uh Tamer

platform where we try to do Android security and hacking archives for India is more of a collection of uh all information security conferences that are happening across the globe but where Indians are presenting uh that's my handle where you can find me U at anry on all different social media profiles so today I wanted to talk about supply chain and then there are a bunch of things that are very obnoxiously familiar for people when we talk about supply chain security because of the way the vendors have been pushing across I wanted to kind of give a feedback as well as kind of do a comparison of what actually supply chain security looks like versus what is being sold right now

where we are and what are the things that are still needed to be done in this space so taking software out of the supply chain if you look at supply chain what you see as a diagram is a two-sided approach to build a laptop on one side you have raw materials which are being procured and then intermediat material being created to the semi-finished laptop material being created to finally a laptop being created once a laptop is manufactured then the next next set of process goes on where from A supplier to a retailer to an end customer is where the laptop is being used so what we see here is that there is raw material of

providers there is intermediator in picture then there is a consumer who has consumed all of this and created a final product and then there's a chain which ensured that you re receive the product and then the end user who is actually leveraging the product and using the product putting supply chain in a software concept this is what the diagram would look like there would be four primary entities involved there would be a producer who is basically creating the basic building blocks what we generally call as third party libraries a very simple example of it would be lib curl in Linux or maybe Linux kernel itself could be a third party which helps you build the entire

product then comes the consumer these are software manufacturers who are basically leveraging on these third parties and creating the next step now consumer could also be the intermediat who is then creating something where they become the producer and the consumer then is a higher level entity which is leveraging this software that is being created so this could be a cyclic Loop that gets created whatever artifacts that are created need to be stored at a place so this is where the infrastructure providers comes into picture so when I say infrastructure provider I am talking about S3 buckets to Docker Hub to your cloud service provider accounts to anything where once your work is done you're sending across

the artifacts to be stored at us central place decentralized place a separate place than your development environment and the last part is the end user they are the people who are actually using your code or using your software now if I re simplify it put it across from a development point of view these are the six building blocks that you would find whenever you're developing a software on one end of the spectrum is a software developer who's basically writing code on the other side of the spectrum is a software or rather a service provider something like Azure AWS Cloud whatever Cloud vendor you may have whatever containerization environment you may have which is where the fin deployment happens in between

the chain there are code repositories there are CI systems there are CD systems there are containers there are dependencies all of this formulates your supply chain and when we are talking about securing your supply chain we have to look at the entire chain in that whole context now the fun fact is when people talk about supply chain we are actually talking about establishing Trust can we trust the entire process that there is no problem in the entire process and we have received the final product good in handy the concept of not being able to trust the software is not a New Concept the very relevant paper that a lot of people would kind of reference is

this article from or rather this speech from Ken Thompson which he did in I think 1984 and he talked about trusting or rather establishing trust and this was the first scenario where in computers context a publicly available document was talking about how to backd Door your compiler so irrespective of whatever your source code is the compiler would ensure that a backd door is always present but this was not the first thing or first written document which actually talked about this this is the part which a lot of folks Miss because a lot of us in software don't like to read a lot so if you if you scroll down to the second page of that article there's a mention

that there's an Air Force document which was the actual first document talking about this particular scenario uh so I was trying to figure out where that document is what was the reference and how it was so this is the document that I could spot this is if I read it right it's 1974 that's when for the first time someone thought about hey we're talking about building softwares we're talking about compilers and we're talking about n number of things and we're building trusts based on these entities are these entities 100% trustable can they be back doored can something happen to the entire process where my input is always benign but my output is always malicious so the concept is not

told now oasp I think everyone knows about oasp oasp has been shouting about this from the top of their lungs from the very beginning right from 2004 till 2021 now they've actually got a proper name for it vulnerable and outdated components or using components of known vulnerabilities effectively what I'm saying is when a vendor says software supply chain is a very big problem it's a very new problem you're not aware of it and it has never existed before it has existed for a very long time it's just that people didn't had something to sell us so they had something to talk about so now when they have something that they can sell us now they're

talking about it now like I said it's been known for a decade what changed so the things that changed was one an executive order came out from the president's office at United States and what was the reason why that came out this is a very interesting analogy that I'll draw later there was solar winds hack that happened there was Cod COV hack that happened there was colonial pipeline mostly Colonial Pipeline and solar wind were the primary ingredients which pushed the US Department to say hey there's something going wrong we need something to be done here now what actually happened because of this because of this executive order which effectively told nist which is the other government body

in USA that hey you need to work with the other departments come up with a framework how do we secure ourselves this was not for the world this was not for everyone else in the world this was a specific order for a national body to devise a framework to secure US Government softwares now because they do all things in open they put out their Frameworks in open a lot of us leverage that there are other Frameworks that come into existence but a lot of us leverage nist related documents so at the end of it nist came up with ssdf secure software development framework and Google and other parties came up with a framework called slsa we will

very briefly touch about both of them the industry buzzword that were taken out from this whole process were two one software bill of material to Provence so software bill of material in a very layman term is like when you go to a sorry when you go to kitchen and you want to cook a recipe you open up the recipe book and it has a list of ingredients you procure those ingredients and you make the recipe so this sort of is a document which tells you what is your software composed off and random buzzword facts that you will find in all vendors 80% of your code is not written by you 80% of your code is

written by someone else and you're leveraging that third party module 80% of code in your software is not written by someone else very valid fact what I've also found is a large number of times a large chunk of that code is not something that you're using you're leveraging a library for 10 % of functionality but you're importing that library with 100% of its code and making it your own problem this has a relevance as we move forward with this Providence is effectively a proof that whatever documents or software bill of material being a document is authentic no one has tempered with it so you need to establish Provence that yes whatever document you're receiving from me that

this is the list of ingredient these documents are actually authentic documents now I have these funny thoughts in between so you'll find them my assumption and my understanding of the software industry is we end up solving problems that we created a few years or a few months ago we keep doing that Circle we've been doing that for a very long time and we'll keep doing that so not exactly problem but looking at the steps in which we have reached this current situation we've been trying hard to automate software build Development building and development processes so when your software can be built faster there would be quicker release Cycles we've all seen from waterfall model to Agile model to

releasing once every 1 hour or once every 10 minutes that kind of release Cycles when you have these kind of release Cycles you can't do it manually you have to rely on an automation so when there is Automation and picture there is less weight for new features because as soon as I have written a feature I have to click a button and that would automatically create a release and the release would be out well and good everyone gets the new feature as early as we can prod produce it because there is very fast frequent release cycle you end up with softwares which are getting released say once every week or once every two days there is less and less interest in

developers going about trying to upgrade their dependencies because I started working on my software today and by the time in 5 days I'm done with writing all the code that I wanted to write there are three version releases on the library that I was using that becomes too hectic at one point the other problem that comes is a large chunk of software supply chain security related Paradigm that you would see is focused around open source softwares the funny thing is no organization or rather most of the organizations never have a service provider agreement with an open source maintainer yet it's the open source maintainers responsibility to keep their code secure to keep their code updated

and to ensure all the compliances are followed so it creates a situation where the developer might not even be interested in doing all of that and in old days if there is there are people people who have been in this circuit for 10 15 years you would remember the days when there used to be two different release Cycles there would be a feature release where new features would keep on coming and then there would be a stable release only bug fixes go into that release and after a while a feature release would become a stable release and then the bug fixes would go there now because of all this pressure around creating and churning out code people

have stopped doing that segregation you get one stream you have features 1 2 three release fourth release has a buck fix fifth release has a breaking change sixth 7th 8th have feature releases and it's just one single stream of releases that you're receiving so it becomes an overhead on the developer part who's basically importing that module to decide what to do with it problem so a solution we built automation which informs the software Developers every single time a new release is created what you see at the bottom is the list of bugs or issues that dependabot has created on GitHub platform to inform software developers that there is a new version of library that they're

using now this is one example I've intentionally removed the name of the projects and the other details where wherever I could find relations but if effectively my question to them was hey you're releasing software at the frequency of One release every 3 days how can I keep track of it and their answer was we don't have the capability to maintain segregation between feature fixes bug fixes and other releases so we keep a single stream we recommend you use dependabot and automation to perform all the upgrades now this is where the fun starts so another friend of mine having a conversation around software development and their problem hey we keep getting these dependabot requests we can't update it because there may be

regression there may be some problems in the code which can break the build my answer and this is like a proper security professional trying to just say hey you're not even looking at the right things like have a proper automated build process an automated build process would ensure that your build if it is broken would be informed to you so would get an immediate notification the response was yes if the build process works but if a feature fails while I am actually using the product the next question from my side is have test cases if you have 18 90% test coverage it is so simple to identify such flaws anyone here who is a developer did you started laughing when

I said 80 to 90% test coverage yeah see that's the problem test coverage is never going to happen if it happens then maybe the automations would reach a point where the utopian security dream of I push a button and everything gets updated the entire world is running on the latest version can happen that's not happening near future anytime so what the business is right now trying to do the industry has a few fun objectives right now find and rep as many third party dependencies that are in use which are older versions and try and get them fixed that's a big project create inventory because that's what US government has asked us to do validate inventory signature because the

US government has said that hey yeah you need to validate because these are the two things that you can do automated these are the two things that can be programmed so these are the only two things that can be productized and sold to you so that's what they're do and then at the end of it everyone feels good hey we saved the whole world uh this is the uh image that I generally use when I'm talking about me being a security professional talking to developers this is kind of how I've done a lot of times so yeah you get the gist so enough of rank what exactly is software bill of material anyone here who has seen nist

cyber security framework version 1.1 would recognize this diagram of the entire framework there is one line item which says Identify effectively that whole line item talks about if you don't know your assets you cannot protect them sbom fits into this particular block no your environment that's all sbom is trying to do so what is sbom a list of ingredients software name version check some license information dependencies that you're using generally what you will find in s bombs is a on level depth of dependencies that are used by the software so if I'm a software manufacturer I have used 10 top level dependencies I will list those 10 top level dep dependencies in my s bomb the

assumption is all these 10 would have their own s bombs which would be listing their one level down dependency tree so the s bomb trees are supposed to be built by plugging in all these smaller s bombs into one giant s bomb which has all the ingredients mapped across now what it does not contains what compiler was used what ml model is in use because yeah AI everywhere AI is there so there is some ml models in used you don't know which ml models are in used what SAS Services were used did you compiled it on GitHub or did you used gitlab or did you used a Jenkins solution you don't know why looking at an s bomb what operating

systems were in use this is again an information not provided there are a lot of other information which sbom cannot store inside it this where a simple shout out to OAS Cyclone DX project if you go to the website they actually talk about these problems and they're working on trying to create more bills of material uh there was a talk I think two days ago at blackhe hat EU where they where a different party was talking about about cryptographic Bill of material what are the cryptographic ingredients used in your libraries across your entire code base they were trying to build a cryptographic bill of material so Bill of material is a keyword that you're not going to stop

hearing for next 5 10 years this is the in keyword now what is Bomb can help you with identifying that one tiny software that is sitting and doing a lot of work for you when there is a curl cve which is say 9.8 CVSs a score you want to know hey how many of my softwares are actually using lib curl if you have a proper sbom system in place you'd be able to query that environment and get those details if you are a three-letter company and you have a incidents like logged for Jam you won't need 45 days to look up into every single inventory of yours to identify how many of my projects were

using log forj and trying to provide fixes for them so this was a joke around where when log forj incidences happened there were a couple of organizations which need 45 days or 50 days time frame just to go through their inventory and tell you hey you know what 20% of my softwares had log for and we have fixed that that kind of a cycle that was going on could be prevented if s bomb is there so end of it any inventory problem can be solved by it that's the whole purpose of sbom now fun fact if you remember I talked about Colonial pipeline Cod COV and solar wind being the initiators for the executive order even if es bomb was

there even if Provence was set for sbom files solar wind could not have been prevented solar wind hack happened because CI system got compromised there is nothing in this S bombb specs which talks about what CI systems are you using so that's where it's a solution to a problem not the solution to the problem that was in place and not the problem that people are trying to solve it's a solution to something plus it cannot actually tell you if the bug is in your code or not like I said you're importing 80% of software code from from some party but you're not using all 80% of it you're using a tiny fraction of it if your

third party dependency has a bug there is a very big chance you might not even be using the path that goes to that bug and you may be secure from that as of now the standard s bomb spec does not have anything around it there are attempts Cyclone DX is one of the parties who is actually trying to do attempts around it VX is the spec sheet that they're creating which should talk about of all the CVS that are against my dependencies these are the ones that are applicable to me and I have provided fix for it so that sort of detailing is coming up slowly and steadily now like I said it's not the

end of all solutions it's not the final Solutions it's a good first step we needed this we desperately needed this anyone here who has ever tried to solve Inventory management problem in their organization and has said hey I'm done with it maybe quit jobs look at the state now there is a government entity and like rather government entities across the space who basically telling software developers hey we need inventory we need you to do the inventory and the way the system is working if you are a top level seller to the government entities you have to be compliant but because of the way bomb Works in a cascading manner every single entity that is doing business with you

or the entity next to you all of them have to become compliant at one point so I am hopeful that inventory problem if it would not go away completely would be solved a bit we would get closer to having better inventories in our environment now has the world never done anything about it is this the first time think things are happening around third party components has no one ever tried anything so there have been two major approaches that you would have seen in software development and you would not consider them as a Supply Chain management problem per se they've been doing their job but it's kind of helping in the supply chain ecosystem on one

side we have a centralized approach where effectively one party takes care or takes the ownership that I will maintain this ecosystem any software that is getting installed in this ecosystem I will ensure the security updates are in place the other is a decentralized approach I want to use the latest thirdparty module so I'm going to create this container where I'm going to do all my work and I will not affect the main operating system now wetted software is where now from this point onwards any example that i' I'm giving I am talking about open source code there could be a proprietary approach around it there could be a close Source approach around it but this

is mostly from a focus of Open Source Code because it's easier to relate for masses so in a vetted software ecosystem you have volunteers or you have paid people who are basically looking at a specific set of softwares a very simple example of it would be the Debian ecosystem or a Linux destroy ecosystem for that matter any drro if you take up they maintain a list of officially supported libraries that they have any security bug that gets fixed released gets merged into the uh library and they maintain a feature release and they maintain a bug release the problem with this approach becomes that on one side it's a single entity who's taking care of things it's easier that way there is

one point you can deal with it on the other side because it's a single entity they cannot take care of the entire world so they'll have to put some restrictions one of the major restrictions that come is I will only maintain these 100 or these 400 or 500 entities and I'll not go beyond that so if you want to use the latest software or the latest third party module that came out just tomorrow you may not find that in your repositories so there are restrictions Focus towards the stability but it gives an advantage that you don't have to worry about things and there is a third party taking care of things on the other side isolate

software approach which you find an npm anyone here who is a nodejs user when you do a npm install go into that folder and look at a folder called node modules and do a right click on that folder and say tell me the size of this folder if it is less than a few hundred MBS you are in a very very restricted project node modules is a folder which basically just downloads all the dependencies that you have cascading down to every single entity that you may have you may have top level 10 dependencies which may result in if it's a smaller project about 500 dependencies in total on a nodejs module system so all of those modules would be

available in that nodes module folder but that what it gives you as a flexibility you can use an older version of module you can use the newer version of module you don't have to worry that if I upgrade this module I'm going to break every other nodejs software that I have in the system everyone is working in an isolated containerized environment in Python ecosystem you have Pip and V EnV VV is what does this kind of a job for you now again devs have control is a pro as well as a con now dev has control they need to know that there is a problem and then only they'll be able to fix it npm has been trying to do

something around it there's an npm audit command whenever you do an npm install it tells you how many vulnerabilities are there but that's about it I know my software stack has a vulnerability what do I do about it the most common response is remove the dependency yeah but if the dependency is a o library that I'm using for single sign on feature of my application maybe removing that dependency is not a good idea so with a lot of these problems that we've created for ourselves which we've been working on over a decade to try and smooth the whole process and bring more automation there is some good features that have also come up we now have infrastructure

as code or rather as a code feature everything is becoming as a code infrastructure is a code compliance is a code policy is a code anything that you could think of is now becoming as a code in software development environment we have better cryptographic standards obviously a general Evolution that has happened we now have Hardware software and storage capacities where we can maintain providences and maintain a third party storage which can give us some sort of an assurance now I used a term Provence it's a proof that whatever document you are looking at is an authentic document it's hard to explain Provence to you but is it is easier to tell you what it is not so if you have a if you

have ever downloaded a software from a website you go to a website you click on a button it downloads a binary for you maybe any XE maybe a DMG maybe a Dev file whatever and you see just below it there's a check sum listed there that checkum denotes that if you have downloaded this software do a check Su at your end and if the check sum matches with what we have listed there then you have a genuine artifact in your hands anyone here who is a pentester or a hacker or an attacker per se attacker Persona would say okay so if I compromise a website and if if I change that download link to my source and then

I change that check some there how would you know this is where if you have a independent third party who has signed a document and that document is now cryptographically temper proof and you host that document even on that same domain that document gets downloaded gets verified by the third party and now you know the check some value that's inside it is a valid artifact and that can be used to establish the authenticity authenticity of the artifact that's the the whole process could be termed as Provence now like I said idly it should be either the document should be stored at a third party place or you should be able to independently verify it without

involving the party that is providing the artifact to you there should be an independent verification capability now this comes closer towards the end of the uh talk so a lot of things I've talked about what do you do from here while you're leaving this room what are the things you should be looking at what are the references that you should be going for so there are some Frameworks that I'm going to talk about there are some tools that I'm going to refer again keeping things in the open source realm in the public run so you don't have to worry about purchasing a license to download a software per se in terms of Frameworks there are three

Frameworks that you should be looking at uh slsa framework which is by Google I'll give a very brief idea about it U cyber security framework version two which is right now in draft mode but that's the version that you should start looking at compared to uh CSF version 1.1 1.1 versus 2 there's a drastic difference anyone who has ever dealt with the upper management would appreciate that now CSF has a section called govern which actually talk about how the governance policies should be crafted for having better security in the organization ssdf is a guideline that is created by nist it's not actually a sort of document which describes the way to do things rather what they've done

intelligently is instead of creating yet another standard that you should follow they have line items and for each line item they refer hey you know what if you're following oast Sam these are the line items in Sam that are corresponding to this point or if you're using CSF these are the line items that correspond to this line item that we are asking you to do so you don't have to redo everything and say okay another framework another compliance another checklist that I need to follow a lot of it would basically become yeah I'm uh pcidss compliant I am done with about 20% or rather 30% of this particular framework so that kind of is a good

thing that they have now started doing so quickly covering these Frameworks slsa is a framework created by Google and the other parties different levels are created to denote the maturity level started very ambitiously with version1 where they claimed that hey we will have four layers the fourth level would be the highest tier possible in fourth layer the organization needs to have reproducible builds reprod ible builds is a concept where using a known compiler if you take the source code at your end and I take the source code at my end and run a common script the output of those two would be bit by bit identical they started with that as the larger ambition and then they realized

it's not that easy so version 1.0 that has come out has removed level four because it's not something that we want to do right now it's a future ambition to reach to that point but it's a good practical framework which has bunch of different uh layers to look at the whole chain So This Is How They Envision the chain very similar to the diagram that I created at the start of the session different end points or different interaction points that are there between each entity are the points where problems cannot happen so what problems can happen how do you try and mitigate them slsa framework tries to answer those questions primarily focused around producers and the consumers from

the four-party equation that we saw at the start this is the levels that I was talking about so level one is like yes I have documentation two I have built something which can be sort of temper resistant second more better layers are imported fourth is the level which was supposed to be there but right now if you go into the documents level four is not there at all they've said do three levels by the time time organizations reach first three levels we would figure out what to do about level four n ssdf so one thing that I hate about Nest they don't like doing diagrams so I have to share a wall of text with you I've tried to reduce it

but these are the four top level ingredients that are there in ssdf framework there is prepare the organization protect the software produce well secured software respond to vulnerability anyone who has ever dealt with cs F they would immediately recognize the kind of flow that is going on do the identification then do the protection then do the detection and then do the response and then recovery it's the same flow so you start by preparing the organization having people policy processes everything in place and then you get to writing good quality code then doing validation around that code having a process how to handle a security scenario so let's say a a dependency which is like three level

down to you has a vulnerability in it how do you handle it do you immediately go like okay I need to fix this so the dependency above it needs to fix it then the dependency above it needs to fix it or do you go and check okay yeah there is a bug does it even matters to me is it even something that I need to work for and then decide whether you want to take that decision or not now when it comes to tooling uh the top three tools that are there so ossf scorecard is a very good tool who if you are a software developer um and if you're using GitHub or gitlab kind of a

cicd system in place you can actually add it as a CI U sort of workflow what it does is it tries to create a health stat for your particular software so if you are doing say insecure practices in your code it'll try to highlight them it's not going to find bugs in your code itself it's going to find bugs in your configurations so if you have another workflow it is insecure it'll inform you if you're using dependencies which are way older it'll inform you if you do not do a code review so if there are five maintainers of the project and everyone just creates a pull request merges it manually without having any review that's a point that it'll try to raise

that hey at least get someone else to review Sig store is a Distributive uh distribution signing uh software which relies on cosign which is the second entity in that list uh cosign is a container signing process effectively they're trying to create prominence look at the container what are the ingredients what are the check sums create a report sign it seal it make it available to people what we are trying to establish is whatever you were supposed to get is what you got if that happens it's all good the uh two projects that I've mentioned in the bottom are the two projects two open source projects that are actually trying to solve this problem in a slightly

different tangential manner but are trying to help the ecosystem so on one side we have safe dep V which is a verification uh tool it can be integrated into cicd pipeline it could be integrated as a standalone tool that you want to use what it is trying to do is it goes through all of your dependencies and tells you what is the current state of your dependency tree and what could be the state what are the drifts in the system how many versions you behind are there any security bugs are there any U compliance uh related problems and the interesting feature in this is you can create a rule for your organization so you can have a rule for

your organization which says I don't want any third party dependency which is a GPL licensed dependency I don't want any third party dependency which is hosted on G GitHub and does not have any activity for past 6 months I don't want any dependency which is hosted on GitHub and has less than 100 Stars so these kind of granular capabilities is what you can Define as rules and when it'll run it'll show you violation of those rules other tools like dependency check also are adding these kind of features U stack loock is one tool that I very recently saw this is developed by the same people who wrote sigstore and what they're trying to do with this this is

going one step ahead on one side they're creating a visual studio plugin so as soon as you do that in a python code import and type the import module name it'll give you a squiggly line saying hey this may not be the best module that you use maybe you want to recheck but when you click on the link this is where the good part about stack loock comes into picture they give you a rating for that module and then below they list out hey instead of using this low rated module these are the alternative modules in the same sphere doing similar job but have higher rating available obviously that list is not going to be 100% that list is never

going to match every single scenario possible but it'll give you po where to go next it tries to answer the question what should I do yes I have a problem what should I do now so those are the to links that you should be looking at this is a very simple three questions that I want all of you to ask any vendor who is selling a s bomb solution to you what do I do with the s bomb ask them what are the next steps you have got me the s bomb what do I do with it what are the next steps if their answer is you don't need to do anything this is all you needed you know you need

to just find your shoes and run from that place second question if you are saying we will find vulnerability and all the dependencies that are listed in sbom which is what a large number of vendors would say ask them are you just spotting vulnerability based on version number or are you actually validating that my code has that vulnerability 99% of the times the answer would be no it's not an easy problem to solve many people have been trying not a 100% success rate I think not even a 50% success rate at this point on this particular track but don't just ask them test it also have a dependency which is old just for a sample testing purposes have a

vulnerable dependency in a sample project of yours Ure you never use the code path that the vulnerability requires and then run it against their system see if they give you that issue back if they do that's not a product you want three do you have alternative solutions to the libraries the stack loock project that I'm talking about gives you some solutions it does not have 100% coverage it does not have all ecosystem coverage when a proprietary solution company comes to you saying hey buy my product this is the least they can spend their money on help me find the Alternatives where do I go from here knowing that I have a vulnerable software so this is my uh request to all

of you when you go and talk with your uh vendors or people who are in charge of buying Solutions ask them to ask these questions and that's about it that's the email address the website and the name so this is where you can contact me and thanks for being a patient listener thank [Applause] [Music] [Applause] you and I think I have five minutes so if someone has a question they're going ask what on hi there Dave have you got any thoughts on Coe environments things like I know you've got all these tool chains that say buy one of my add-ons the modern equivalent of an Excel spreadsheet is a Coe small piece of code installed by the user we got any

thoughts on these for espo so let me repeat it so the question is yeah um the Coe environments most vendors have them and their user installed codebase modern equivalent of an XLS if you like piece of code so the the idea is that most vendors have little lumps of code that you can buy and they go do things in the larger uh way the the question is if there are user controlled environment where user can install whatever they want to install and there are pieces that they're installing what do you do about that or what can be done about it so there are two parts of it there's an open source angle around it and there's

a corporate angle around it the open source angle around it you can't do much but if it is a corporate environment if it's a corporate controlled device or corporate has some sort of a connection with the device there are solutions like osquery that can be installed on the system it's not going to be 100% solution that I can tell you right now it's not going to find most probably the exact thing that you asked Excel macro it's not going to spot that but it will spot softwares that are being installed on the environment most of the time when it comes to macros or programming within the um say office environment my suggestion is if you don't need it don't

enable it try and disable it at the say Ad level if possible but yeah it's not the Practical ground reality that you can have yeah um uh you know like lot of dependency scanners commercial and open source list out a lot of uh dependencies for the project team to address and the teams what they say is like hey can you give me just the top risk which is applicable to my my my product or my software so what what are the key par of prioritization see there are two parts of it one any vulnerability that is discovered idly and this is the big Idle Word idly the third party that is providing that library to you should

specify of all the bugs that are reported against my code or the downstreams these are the ones that are applicable to me because what you see in the report most of the bugs would not be in your direct dependencies the CVS that you will find will not be in the dependency that you imported it will be in the dependency that was imported by a dependency of yours or a second or a third level dependency of yours so someone in the middle would have to identify one we can't take that as the ownership per se but what you can do and this is where if you have time money resources available and especially if you're a security person in the company

what you should be doing is dig a bit deeper don't just look at the cve rather try to see what was the function called that is the problem and is that function actually in use make a note of it it is not in use right now if two months down the line it becomes something that is in use you need to spot that and report it so a tool that helps me it's semi commmercial semi open source called semrep it allows you to create structures around identifying such patterns so that can be used used totally disjoint no Cloud connection have a rule on your system have the binary in your system do a check within

the system itself so that can be done but the initial bit identifying whether the path has actually happened or not is the problem that you'll have to solve at your end you can't just tell the developer hey these are 2,000 vulnerabilities fix them all they will ask for top 10 because their entity or their say mandate is not to fix bugs their mandate is features so you tell them what do you need to be fixed so code coverage is going to be your first step Second Step would be the CVSs and epss scoring so CVSs scoring tells you what is the general score of the vulnerability how big of a problem it could be in a general generalistic

level epss tells you whether the vulnerability is right now being exped exploited and there is another scoring called ke Kev known exploited vulnerabilities if the vulnerability is part of Kev index that needs to be fixed immediately Kev that's a list being maintained by governmental agencies around what is actively being exploited so if they say this is actively exploited people are actively attacking we need to fix it right now the tool actually give us some tools claim some tools do not it's a bit of a gray area right now the reachability and the exploitability are the key factors exactly exactly and instead of just saying reachability exploitability epss is the word that you would find everywhere so epss score is what you

need to look for K yeah that was very useful there thanks you if there's no question let's appreciate Anna again thank you so much