Right-size your open source compliance with ORT’s policy as code: balancing risks and efforts

This talk focuses on the integration of compliance in open source software projects, emphasizing the need for organizations to assess how much effort they should invest in open source. The speakers discuss automation's role in simplifying compliance processes and the importance of using a variety of tools tailored to specific tasks. They highlight the significance of contributions back to the open source community and maintaining sustainability within it, as well as the necessity for organizations to adapt their workflows for better compliance and collaboration with legal teams. The discussion also touches on the operational aspects of a tool called 'Or' that assists with orchestration between different tools and recommends using policy as code to automate license compliance and security checks.

Okay, good morning everyone. I'm Elio. >> This is Thomas. >> Yeah. >> So basically we are some guys working on compliance and using basically too lane for a long time. I came here as as basically as my addressing my open source hat as open chain board member and contributor and contributor several open source parts and basically responsible to doing some pipelines for tooling itself. >> Uh I

work as a private contractor basically independent contractor uh doing all kinds of uh helping companies with ospo work or or work. uh but again we have lots of to cover let's say let's uh let's move on. >> Yeah. So this this talk is mostly to tell how much effort your organization should invest in open source. Usually people say a lot this is this is very highly expensive

things in the if you're thinking in the old world that part that's involveing pushing things to creation several review times discussions about several teams of lawyers because it connection to This is what's was resource intensive, time intensive and cost extensive there and that's so the question is how much effort there that's different answers for each case but in this case we try to reduce this using automation

parts and how it can be done in software. So this is the actually idea of the original thing. Normally the people that decide for doing this this purchases part is the ones that B doesn't understand the entire pipeline and the whole process of this. So the choice for for a tool is like someone come to you and tell the tool do that it looks like they do

that. Someone says nice it do everything it buys it put in there and then you are everything okay and absolutely not because it's probably and as everyone we used to say that there's no two that do tool two that do everything today not at all if you someone comes to you and say that is existed no >> this is yeah this is really if you look at

what is kind of the the discussions in the officers community opos is basically the other way around. It basically says like hey um before you buy a tool first look at your processes and develop a riskdriven uh datadriven process and then start the mixing matching the tool. So what I commonly see is people rush to oh yeah we're just going to buy the marketing that they go

to Gartner and they see the the things and all the stuff and I can tell you that well most of the companies that I work with they don't look at gardener reports anymore because the open source solutions are are pretty much the leading ones uh and they don't pay gardener. Uh so um yeah it's really you Lauren the people that have really been doing this long time

they see they have different tools for different jobs. There's not one rule to roll them all. there's just like hey for this particular thing we're using this tool for that particular thing we're using that tool and you kind of have to mix match and also not every organization is the same um so you always see a slight uh deviation basically with what people are using um so

this is one of the things that I've been working on for for a long time like coming from an OSO background is basically say like hey not just looking at compliance but looking at the more bigger picture to say like okay so we want to not only use open source but also contribute open source back. So if you build a pipeline as an Ospo, you don't only

want to use it for compliance, but also think about your contribution use cases or your merchant acquisition use cases asly as an OSPO, you have to do all of that. Um so yeah, you of course want to be safe uh which actually is in not only means secure but also means safe from uh from from other um from basically how you use it in your organization. You

want to respect licenses. So not just to the uh the the letter what the law says um but actually most of my customers actually they they more worry about what this regulation says or what is written in the contract. Um and also you want to u help basically your upstream sustainability. So you don't want to just use open source and then figure out like oh crap the

open source community decided that this tool is no longer viable or it's it's there's like a single maintainer or they changed the technology stack. So when you basically including a tool shack, please stop doing this thing where you are patching it on your side and not doing any upstream you're in reality most organizations I work with run for the majority on open source. You need to learn

how to work with the open source community and actually be part of that and actually um give back uh in in in some forms. So it can be in monetary it can be in in the developer firing power but you really need to think about uh doing it absolutely and especially if you look in the context of compliance um I have had many teams where uh the

compliance department is called the department of no um so whilst you're doing this try we're trying to figure out how can we make the life easier for developers. Yes, complying with licenses, complying with regulation and with customer contracts is a very very complex picture. Uh but we believe that we are finally getting to a point in the oper community that we actually handle this kind of stuff.

solving the challenges on the industry this is mostly things that is the open chain group that is we are mostly parts are doing. We are trying to connected every single open-source let's say entity around us to actually work together to get a single only way to produce the results. We are not advocating for a single product or a single open source solution but actually in a completely

ecosystem that we can be choosy inside the company. So in this way everyone can we are trying to put an everyone together that we can talk to each other and then the products or even the solutions can talk to each other and then it makes easy the solutions being used in the company is there at all because basically this is a company based thing that we not

obvious thing. So you can see that we're trying to together all the foundations and in two lanes connect everyone. It's it's a really really hard job right now because it's every foundation and every single project has different goals and agendas and then to make it things work together. This is the job of the open chain that we are trying to reunite as once. Yeah. So this is

Thomas. So you might wonder okay so to answer the the question uh what we're actually getting into the community with is well the obvious one is first talk to your legal council because again it's about your company's organization's contracts uh and your obligations but also more importantly work together with your uh in in the op and foss community to basically learn how to do it. there is

not a guide that works but especially surprisingly is that when we started out and and like Marcel and I we started been doing this for close to 10 years in the beginning was all like compliance we can talk about it now there's for a lot of things basically a lot of we can talk about things like okay how do you do this how do you do that

there are recipes ava a available so it's much more easier instead of basically trying to do just yes listen to your legal council but also basically work in the community to basically say like hey how are you doing this work with your supply chain work with others to basically learn how to how how they are doing it and try to balance so in your industry. So talking

about OSS review tokit this is for mostly to us one of the key parts of the can do orchestration of the whole to part and people has this strange concept that is the thing that do everything which is completely not true is the thing that controls everything this is the most important thing so we living in a world that we need different tools for different setting parts

we started with compliance in the beginning But then in the end we end up now dealing with vulnerabilities we need to connect to multiple type of services to get in whatever necessity data to guarantee the compliance CRA other things there just before or we didn't have any possible solution that to do in the simple orchestration there so today or is becoming one of the most easy ways

to do it orchestration between multiple tools and multiple services. Yeah. So the capabilities there's dependency analysis basically look try to look on every single package manager in the world and try to find the dependencies with there which basically is very difficult thing because people decide to create a new package manager every five minutes and then after that we can go to talking about how to do the

compliance scanning that is doing vulnerability assessment which connecting to different services there we're doing reporting for multiple formats that is exactly like people request cyclone DX spdx vex whatever there so it's always different thing or different necessities for different companies there and always new tools that was offered on pop up in the open source and very difficult and costly to connect everything there so using art we

can diminish this cost for this and control and actually doing the process there. Yeah. >> Okay. Go. >> So maybe some um some unique features. Again, there's many other open source solutions. I think one of the things that makes or unique it's really driven by actual users. So we're actually original that are kind of familiar with the problem that have lots of we have also lots of

connections with lawyers that are use that are using it. It's our most was born in Germany. So you have a lot of German automotive companies using it. Um and that basically means that basically it's gone to many many different companies and it's not a single vendor controlling the project. It's it's neutally hosted. Um it's also one of the few tools that actually you can use to actually

obtain sources. So a lot of things for your license compliance you have to do so-called complete corresponding source bundle for your for your code. This is just a built-in standard feature >> because guess what? It's being developed by OPOS and legal departments that are like we just need a tool to do this for us. Um, so the other kind of unique feature is basically correct findings. So

one of the things we got really annoyed by where previous tooling was, oh, a finding a license finding is incorrect. Oh, I have to file a support ticket with the vendor to try to fix this. Yeah, tomorrow is my release. I cannot wait for the vendor for the vendor support team to fix this. I need to be have the independence, the data sovereignty to basically be able

to do this myself. Um and and that that's really where we're like no we we can't wait also I don't want to share certain opinions in data um policy as code we'll go later on and how that how that how how that kind of works but it's very powerful uh end to end traceability so this was also um kind of maybe built in by accident purely when

we're developing or we needed certain things where bugs are coming from so when there is a problem uh reported by a customer we can actually trace back where that thing actually comes from we and completely go to the entire pipeline uh and figure out uh where it comes from. And the last bit which is especially um where orch kind of shines is in um in the high

compliance industry. Um, when you deliver a car, uh, the the law says you have to support it within 15 to 25 years, which basically means we're using the tooling right now, but my successor or success successor still needs to be able to use that, be able to reproduce exactly the same, figure these things out because guess what? That's what the law requires. And then people are like,

"Oh, we have an SBOM." Yeah, that's that's neat. Uh, very very useful, but the sbomb cannot capture the complete uh everything that you're doing. So this is where we're basically really architected for that like no you have you can run it it's uh it's it's cotling based JVM based you're probably going to run it uh in in 10 years 20 years it probably will still work and

you have complete access to the source code okay let's talk in the whole entire process there and the way that the or architecture works today we have several steps that can be done so you can see that in this example that there's multiple tools that assign it there and even if you look in there in every stage every single step is done is done differently individually. So

this means that you can actually orchestrate this in the way to do every steps intermediate with several other possibilities in the middle. From here we going from the beginning up there. So it's basically source code analyzing to actually doing download the source code. That's actually very useful for every company that needs to retrieve the source code and keep in the house thinking about that this is a

mandatory thing for CRA or UNCC55 and then you can go to these multiple scanners that up to your choice there and going there and then this is one of the most important features for N that is the policy based the whole violation there and then there comes to report as a notifiers that you can deploy everywhere even of your internal part of your company there. So you

see that is up to your choice is not what the tooling telling to you but the tooling providing to you that is completely one thing that is free you of the possibilities. >> So the other nice thing um the tool chain basically produces all the results in a single HTML file. uh that has a man benefit. Think about if on the basic uh we have different users

using or so. So on one side we have the smallest uh independent legal council or independent opensource developer to major companies running on it. Uh the beauty of it is they they get all the results in single HTML file. So if you're in a large company and you need to basically where I typically see they're separated, you need to send the results to another. You can send

the sbomb which is hard to figure out sometimes it's a big delayed file or you can just send all the results in a single HML file. So you can just email it. There's no on the bottom. You can just email it. Also if you think about this uh longevity in 10 20 years somebody has to be able to look at it. Can you guarantee that your web

server and all infrastructure you got from your commercial vendor will still be up and running in 20 20 25 years? >> No. But now you have your results in a single HTML file. Is it perfect? Maybe not. But the majority of the results that you need is in this file and you can easily browse it. You can as I said you can easily zip it up, email

it or post it on your artifactory. You can keep this real easy, very very very long So I have tons of customers that just put it in in in in Glacier for instance and yeah done they have the sbombs they have the report they can see what has happened what is in there and you can easily browse this and then even if you don't want to go

before to the web report we always have the raw results available that that can generate this web report. It means that you can even create your own output from the original whole data. So all the data is available forever and not fixed and hidden inside some weird database or something. Yeah. >> So maybe to go make it some a little simpler, I I actually wrote down the

kind of standard conversation that you kind of normally see between a legal council and engineer when they have to do a product review. Um and we were really like how can we automate this? Like how can we take care how can we make this conversation? How can we eliminate it? >> And not because we want to separate the legal councils from the developers. know both sides the

base data you don't want to base information you just want to automate if there are special cases that need handling where a legal council likely that's the interesting thing for a legal council that really a legal council is interested in um that's where you have the conversation for but basically what we're trying to do is automate the handshake between like uh uh developers and legal councils or

developers and security team developers and opo really try to uh to automate this so we basically can feed this kind of formula uh to our evaluator that looks like like hey what we're doing in the code and what are we doing in a legal context what we're doing in a in a product and what are we doing in a in a in in a in a security

side and you can actually make it as crazy as you want because you can add more and more what whatever you want to so if we start translating now we're going to go a little bit more in deep and um or has different files to configure these things as Helio already showed we have an or file that's kind of where the developer encodes their like what they

know about the repository Then we have uh policy rules that basically you can really write to for your legal product and security context and um I'll go in a minute to show how how how powerful they are. And finally to you can also fix things up. So we have concept like package curations and package configurations that really allows you to fix up the metadata or fix up

scan uh findings. Uh and these are just uh either a simple YAML file or you can actually also program them in via what we call a provider. So you can actually really automate fixes uh to the data on mass which really helps basically on on getting the data quality up. Um then for the product or or business context we support something called labels you know like what

why you do labels. So >> we want think of that conversation with your lawyer we they need to know like what are we doing? Where are we shipping this product to? Um what is this type of product? Is this an SDK? Is this a um a REST API? So all of this kind of business context basically I normally I help organizations develop a kind of label structure

um for this uh and then they can basically encode all of this stuff. These are just things normally we put a little wrapper around it so they just fill in some questionnaires and fill it in. And the nice thing is labels are supported in many many different systems. So for instance Java supports it, Confluence supports it but also your Kubernetes stuff supports it. So what you can

do is for instance if you deploy say to a kubernetes instance you can take your labels that you have on your kubernetes instance and pass them on to or so. So then you can basically from say you're developing in java and you're deploying on kubernetes you have an endto-end trail where you can see like oh so one of the things for instance that I recently did for

a customer they wanted to know they want to have a different policy for things that were internal or external. So how do you figure this out? Well, they were deploying on Kubernetes and guess what? In Kubernetes, when a DNS gets assigned to so public IP gets assigned, the Kubernetes platform knew it. So they just added a label there whenever Kubernetes did it and pass it over to

or basically so when a team internally says like hey we're internal well if they're internal that it shouldn't have a public IP and so this way they're basically the local or instance can talk all the way to the Kubernetes cluster and end to end they can make sure that when somebody says it's internal and therefore certain policy rules apply it's really internal. So this is the the

beauty of what the label system. It's incredibly powerful when set up well and you can this really allows you to write policy rules for particular units for teams for products. Literally you can do crazy things with Uh let's go look at the the policy rules. So what you can do um so you can write policy rules on pretty much all the data that or captures. Um and

so this can be package metadata, it can be the licenses, it can be is a file present or not. We already showed the labels. You can do sec security vulnerabilities. Uh it's really really powerful. You can also hook it up to uh to other systems uh because the rules is basically uh written as a cotlin script. So you basically have full access to not only the or

data but you can also write basically network extensions where you can call a rest API uh to get other data from your internal systems and and so that really sets it apart from a lot of other solutions where either you do have to do things for the UI or if they say they have policies code it's kind of a YAML file. So don't get me wrong, the

the YAML file option is rules is also a good way, but really if you're thinking about, hey, I want to take my organization's policy and I want to automate it. You want to have that full flexibility. So yes, it does require some programming, but once you set it up, actually you you're you're not limited by what the tool can do. It's limited what you can implement. Basically,

um we did have in the rules we have several uh kind of helper things on how we set it up. So it's not like we we tried to make it easy. The idea is basically that um you can write your policy rules and that they're easy enough that a legal council and a developer can also understand them. So we're trying to hide some of the the for

loops, the while loops and how you want the tree. We try to basically hide that away. Um so that you basically can really easily understand rules. So you can write multiple types of rules as you can see here. I will not go uh over all of them but I just wanted to highlight one to kind of show how how this kind of works. So here you see

a so-called package rule. So this runs on every package. Uh we have it give you give it the name. So this is copy left in in in sources. I do not want to trigger it on um on excluded. So when you mean excluded this is a mechanism in or when you can indicate the developer can indicate hey does this file end up in my build or release

artifact? Yes or no. It's like why do you want to do this? Well, you as part of your effort you might make a risk decision say like look anything that my devs are using for development or for documentation or for testing we are could put more relaxed regime on license compliance because guess what this is not being shipped to our customers. So that's why you have this

minus excluded. Um you see here also the the the the label functions uh and you see the license rule interesting it's called the license view. So you can decide where you run your rules on. So you can basically say like hey I want to mimic some of the commercial tools that only run on like the declared the licenses and package metadata or I say like look I

I want to do look the scanner findings really you can do whatever you want and there's some standard built-in functions in our in our example rules where you can just say like hey plus copy left. So you see the the license rule is relatively easy to understand for most developers and they kind of it's no longer like a black box. Oh I need to talk to a

lawyer. you can just actually look at the rules and you can kind of understand it. And finally, we have this mechanism on the end which you can basically troll uh an error. Um you can actually throw an error, a warning or a hint. So you can decide like hey is this um we always say errors are must fix. Um warnings are should fix and uh uh um

hints are basically nice nice to fix. So you basically can really decide what you want to do and you have the option to put a markdown text uh in there um to basically fix the the things. Um just for give you an idea of what all is possible I listed most of the uh the the the helper functions as we call them uh for the various rules.

So again there's lots of things like kind of like really giving you kind of a tool set to to kind of build your own uh your own rules. Um also uh we have something called the or config repository uh where we share some uh of the rules and and all the configuration files. So you basically you don't have to start from scratch. You can actually uh uh

pick this up and basically use it as your basis. Of course do talk to your own legal council uh because again this is kind of like it gives you an idea of how rules could work. You need to talk to your own legal council and your own uh business owners to decide like how those rules should work in your organization. This is more uh basically to get

you going and as a as a kind of a reference. Um and this is kind of how you get this. So you see this copy left. This is actually the copy left independency rule that comes standard from the rules. Um in the beginning it will be really really really really scary. Um because you will uh get tons and tons of violations because guess what open source is

not perfect. Um the scanners are also not perfect that that we use. Um but again you're using stuff for free. Now the good thing is most of the time if you follow kind of in the our how to fix me text we have kind of a recipe on how you need to do clearance most of them can are relatively easily fixed um especially if you basically decide

that basically hey we're going to do excludes so most of the open source dependencies again because the licenses and copyrights are in the sources so we either scan the source artifact or the source code repository but of course in most open source projects there will be more stuff in the code repository aka test code development code that is actually not in the build artifact or release artifact

that you are using. So then we have to um you can mark it up and you basically can substract that say like hey what we are actually using from this open source package is this um it's also powerful enough that uh for instance if you're using say the Amazon um Java SDK where you maybe have a mono repository with like 500 packages in one code repository you

can also say like no no no we're only using this directory that's the package that we are using it's all uh capable of of handling that um so yeah this is kind of how you how that looks like uh you this is custom. You can do whatever you want. So the nice thing is when you write your policy rules, you can link to your own wiki if

you want to. This is just markdown text that you just defined in the policy rules. So this basically gets rid of what I see a lot where people run a scanner and they have a separate wiki and then people have to switch look the wiki things. No, all of it is in one >> and it's context aware. >> Yeah. And this this is interesting because with the

moment that this is created and then during the flexibility of the rules there's we are able for one of the the usage that is done internally for for my team there is that we are able to pick exactly this message and sending to the the other two that was visible to management and visible to developers at the same time and exactly the same message that represented here

is going there and then the same markdown. So we don't need to need to show to managers that want to see a specific ticket to understand that the issue is open and see what is happening but they don't need to go to a specific server download report try to understand the report that usually is not easy to them to understand. So this is basically pure data distribution

that can show to you easy to way to push in there >> and and the nice thing is so for uh one of my other customers I'm working for actually um they're doing a migration um so they're moving source code repositories uh at at the moment they're they decided to do uh to do a migration to forjo. Um the nice thing is they can just write a

policy rule and whenever they do the packages and they see it's in company owned packages and they see it's hosted on the previous system. They can just write a rule and it says like hey we see that you're hosting on the previous system please the this system is going to be shut down in x amount of days. So the nice thing is you can even write time

reports in it. So you can literally say, so instead of doing this blast announcement for like, hey everybody, this system is going to be shouted down, you have to move there, you can literally put it inside your policy rules where you can just flag and basically like, okay, this unit we're going to shut it down at this moment, that unit, we're going to shut it down this

moment. So instead of doing this blast announcement where everybody gets too many emails, just stick it in the regular thing in the order script and they will know. So again, you can do license scans, security scans, engineering, uh, um, engineering standards checks, you literally can do whatever you want in it in order. That's the the nice thing about it. Um so how much effort I said use

or policies code um to automate things that are context aware. So then you can really shape down the effort. So one thing that you have to get used to when people use or that people like oh without the policy rules and we're done. No you actually will be continuously tweaking policy rules. Not that you change the big lines but you're figuring out like okay in this unit

they're doing this and this in this case maybe we are choosing this balance between risk and effort and you can really really decide. So you don't have a one size fits all. You can do everything context aware. So you can really decide hey in this unit they're doing mostly things in that that's internal that we we consider this low risk. Okay we're doing that in that other

unit where they might deliver to automotive where if we f up we have to pay millions in penalties. Hm, we're going to have that policy and you can said you can do whatever you want uh with using or policy as code. Um so how can you basically scale this up? Because again you want to use this in a in a large uh organization. Um so the nice

thing is or compat uh standard uh um integrations for most of the CI/CD systems. Um most organizations that I know actually customize these. Again, for us it's kind of like we give you the reference. Yes, they work. But most organizations actually look at them and basically build their own versions out of them because guess what? Every organization is slightly different. So they want to build their own

uh their own pipelines, their own ways of working again because Ort has a plug-in architecture. You can actually make your own extensions on top of it. So this is why yes I know some companies that run as vanilla on on orci inducation but there are also several ones that build entire stacks on top uh and basically do their own thing completely on top. Um so one of

the things that I just wanted to give uh for for reference um again you see a lot of things where uh people are like oh we have to do everything uh this is a slide that I had we did for here where where we did everything uh in CI/CD. Uh you don't have to uh you can also decide look inside I'm going to be a little bit

more relaxed but I'm going to run or for instance um uh when we import we mirror open source artifactory. So when basically we pull in open source from from the public package repositories we run or there as well. So on import of open source into your organization we run checks there and we have an audit process there that basically checks it. So before it even gets used

by our developers, we can already uh uh check it. And so you can really decide when do you want to run your check, how, what, why. You don't have to do everything shift left. Uh personally, shift left is nice, but I really believe that there are certain checks that you should do in shift left with the developers and there's other checks that you should probably do centrally

because they just require um more in-depth knowledge. For instance, pattern checks are in my view better done centrally than in the uh in the ICD because most of them also snippet scanning. I'm still not convinced of doing it in ICD because there's lots and lots of false positives that can come out of it. It's sometimes more easier to do this centrally with a centrally supported team. But

again in or you decide how do you want to set up the process? How do you want to build it? It's basically how you want to work. We don't force you. Um >> yeah. So basically you can see that the process is pretty much simple there in the way that if you look at it can be simply distributed like under size this fully automated it maybe passed

to the necessity of the legal security and then you transmit everything that goes to the people that do the cation and parts and this is completely different uh processes there. It can be treated even in a way that you can simply deploy the result of the site for one team that is really doing one part that's deploying cycling in artifactory and then from there trigger a second

process. This is completely disconnected from the previous team and it's connected for the CI but at the same time everyone is doing their job using the same set of data using the same tooling behind but not necessarily in the same team same area same department and even dependency of learning different parts of this. So this mostly proves that how we actually can do it this in a

separate way. So the the other nice thing is um because order is open source and you can publish your policy for instance to your suppliers and you can collaborate with your suppliers. So you can say instead of giving them a paper document you can say like hey here's my or policies code there you have the tool that you can download from from from GitHub you can run

it and you can collaborate on fixing up the open source together because in the end what how or is set up is basically what we usually do with or config repository is just a git repository. you can just give people access to it and they can just work together on it. So this allows you to b not only work basically via inner sort within your organization where

the de developers on various teams can basically commit corrections to the open source but you can also do this with your suppliers together and you can really clean up your whole supply chain because normally you cannot say basically go to your suppliers and say like hey we are all going to use and insert commercial tool X you really will get into trouble with EU law and if

you do that it's not possible but in this way if you basically say like yeah we have an open source tool we recommend you using it and if you're using it you don't have to read our paper policy to you actually get our polices code. Here are some CIC integrations. So what we see generally is for suppliers this makes it a lot of easier because they get

the policies code they get a tool that they don't have to pay for. The only thing that you have to invest is basically clearing up the results but that you can also negotiate with your uh um with with your suppliers um to work this. And finally you can also work with the open source community because again you're working on the standard open source tools. So you can

also take for instance uh uh data that comes from uh from a project called clearly defined or from ocelot where we're working in. So you can take other data that come from different sources and help that to basically help with your license compliance. So in the end what we are looking at is basically see look instead of you having to do all the work yourself. It's kind

of stupid. I remember we were in to lose in an open chain meeting and we were all asking I think it was the Linux kernel who's currently doing the license compliance for the Linux kernel and like I think there were like 35 people and like 27 of them are raising their hands. We are not competing in this thing. Why are we doing this? We have tons of

if I look at the technology stack of tons of companies it's pretty much exactly the same. You are not competing on what open source you're using. Why can we not work together as a community to basically say like let's clear this up from a license perspective but then also from a security perspective let's just work together on actually fixing this up and basically or is one of

the tools that tries to make this more easier by providing a standard kind of framework and basically by trying you to give you something that you don't have to reinvent the wheel you can basically say like look you can you can look on our website uh sorry on our GitHub repository there's a list of adopters we have some major companies that that basically are using it so

it's not like a small little project anymore more. People are using this in production every day. There are thousands of scans being made with this tool. Is it perfect? No. But instead of you trying to reinvent the wheel, it might be easier to just basically ask. The tool might not be exactly what you need. And there's other tools. But then we'll literally point you like, hey, maybe

try this other open source tools. We know most of the other uh tool creators in the space. We can happily point you like, hey, maybe this is not for you. Maybe you want to have something else. Again, there's not one silver bullet for everybody. Yeah. So again going back to the beginning of everything that how much effort there's it's basically the decision of how much effort is

yours there you can actually always go to the easy solution and buy something that tells to you that doing anything and then end up in the but question there oh I have my things but but now what I do with that and then it's you have a problem in the deports or you can decide it to actually work in an with the community in general and ask

what we are using, what we have available and how actually we can use it. Maybe this will be less effort. You can think about that. So just contact exactly the ones that completed the groups that correct for this. If you needed to to talk go to to-do group, go to open chain depending on your necessity. We can guide you to direction that you needed and then you

can decide by yourself that this is much effort that I want to do it and afford to do it. That's the goal. >> Yeah. I said what we generally see is is people are used to buying a tool and calling it done. But in reality with all the regulatory framework changing um buying the most expensive tool in the market is is basically not and you're calling it

done. It it it no it doesn't work anymore. The regulators are asking more and more from you. And the good thing is for like since the open source side, it's not like look, we have not everything supported, but I don't have to go to a commercial vendor where they say like, oh yeah, you'll get a next release and the next release happens and say, oh, it's going

to go in the next release and and like no, no, if we need a feature now, um, if I want, I can implement myself. If I don't have the development skills, we have commercial support providers in our in our ecosystem that can implement it for you. We also have uh commercial creation providers for you. So basically it it's changes from a I don't have this feature and

I'm waiting to like no no no stop complaining start doing it's on you to actually get this done you you are releasing a product in the market you have to do uh compliance but the good thing is you don't have to do compliance alone anymore you can do it together uh in your company you can do it with suppliers you can do it with your customers and

you can do it with false community so if you want to balance how much effort is again talk to the community talk to your suppliers talk to your customers you'll be surprised actually say like actually Yeah. Well, I know the legal text says this, but in reality, we are fine with this and this and this. That's it. Any questions? >> We have to get a microphone, I

think, or for the for the audience online so they >> Yeah. Hi, thanks for the presentation quite uh interesting and I just want to call my colleague that is doing all the stuff on in our company but I wonder you all you said doing crazy stuff doing what you want feels like a lot of effort to configure and and bring that system into production. Do you have

any concrete examples how much effort and how long it would take to >> to yeah set things up for a I don't know midsize project whatever >> so I have done so good thing is if you basically just run on the standard rules so if your lawyer basically looks the rules that basically we have us out of the box I've had open source projects operational within 4

days but look if you're like a a small startup and all the other stuff it takes a little bit longer because you have multiple teams the the the main thing that I actually look at is not necessarily so much the open source clear and stuff. What we mainly figured out is that a lot of problems are actually in how developers set up their own projects because you

kind of need to for for instance your source code bundles to work um your developers need to for instance put the ideally the source code location in the packages that they publish. So or can basically the way how or works it just follows your package manager's regular uh um dependency graph and macad to find out what the sources are. So what we typically see um one of

the my customers that I now have has an issue with is like they publish their internal packages with the same name as an open source package. I'm like, "No, that's not smart." When you build your own so own packages, put it in your own namespace because guess what? You're looking at things at scale and you're automating things. The tooling for to operate if you want to write

rules on your software versus what is open source software. Well, the tooling needs to be able to to differentiate and one of the things we do that is you can for instance look at the namespace or you can look at the code repository. So yes, there are some things. So most of the time actually the most effort in my view yes we have to clear the open

source that's relatively straightforward is actually getting the developers to work in a particular manner >> and and that's that's an unintended behavior of arts it was never intended to actually do that but from time to time I I work now with in project a huge company that doing more than thousand different projects we get all the possible animals that you can imagine there and at some point

one thing that art was never intended to to be But it's kind of working. It's like a quality management tool. It's because we starting to see problems on the origins of the build systems of the developers that was triggering like looks like a defect when we are doing the analysis there. Then we tracing back and discover that actually the project was not using correctly. They're even on

good system. So the effort is really directly related to the how the good the quality of the code is there. So you can use the tool even to see that how the output coming from out there to two. So if you imagine even a small easy uh let's let's say you choose one single package manager in JavaScript world you can have at least 10 ways differently to

to get the dependency with one single package manager. So if you have consistency things the effort is really slow and then you can go very easy maybe in one day you can have some results but if you if you had this background that coming legacy then it will take a little bit more effort on that. >> Yeah. So that's really we're said we're not doing special all

we're trying to do get our engineering stand like follow basically what is our open source best practice. So we don't have our own like set of things that we sell. We say like look this is how your build tool says you should be doing things from a security from a license perspective. All we're doing is do that and that's basically like literally that's all that or tries

to kind of enforce but it's like hey these are best practices that you find over and so that's where yeah it's kind of tricky um that's usually the hurdle where people struggle on but it's like it just makes sure that your company is and in the context of the CRA that's actually very useful that your development teams are actually following what is kind of the the standard.

So most of the time when I scan open source projects just on GitHub, it usually works out of the box because they follow these practices. But when I go into commercial organizations and they do closed source, they don't follow these kind of standards. Common things like this might stupid. They don't properly do git tagging of releases. So how are you supposed to find a release if they

don't actually make a tag for a release properly? >> Okay, we have time for one more question. One more question. >> Questions. You will be around for a while. I hope >> we are around till uh till till closing. >> Thank you very much for a good talk. You caused me a lot of problems because now I have to look into much deeper. Thank you. Yeah, good

applause.