Eclipse Apoapsis ORT server: An open source platform to automate CRA checks

This talk covers Oserver, a platform designed to automate software compliance checks, particularly in relation to the Cyber Resilience Act (CRA). The speaker introduces Oserver's capabilities, which include license compliance, security compliance, and vulnerability checks for both open-source and proprietary software. They explain Oserver's architecture and discuss its tooling, including the analyzer for software composition analysis, an advisor for vulnerability guidance, and a reporter for generating compliance documents. The session includes a live demo showcasing the Oserver user interface, illustrating how organizations can manage their compliance processes more effectively by grouping repositories and monitoring vulnerabilities in real time. The talk also emphasizes the project's history, audience expansion, and ongoing developments aimed at improving the platform's accessibility and functionality.

[music] Yeah, thank you everybody for joining our talk at this last day of the conference. Uh last talk before the lunch break. So uh let's see how it goes. So our talk is going to be about Oserver which is the technical part of Eclipse apps. So there's more to it and if you listen to Marcel's and Nicholas talk yesterday then you know there's a lot of work

going into guides and documentation and so on but today it's about how to uh use server leverage or server to highly automate um cyber resilience act related checks. Yeah. Oh yeah works. Okay great. Um before we start just quickly about ourselves. So uh next to myself there is uh Martin lead engineer at double open and also Eclipse apps project lead and um I'm CTO of double open

and the founder of the OSS review toolkit short overview over what we're going to address today. So a little bit of introduction in history. So if you also were present during the previous talk from Helio and Thomas there's maybe a little bit of overlap or complimentary information there. Uh then we're going to talk about obligations from the cyber resilience act CRA. Then we'll give you a live

demo of art server showing you around a little bit in the UI and giving an outlook in the end about what we're planning to do in the future. And then there is hopefully time for questions and answers. Okay, introduction. Let's see um what is Oserver in a nutshell? So this is a super duper simplistic highle view of uh what it is all about. In essence, it's a

platform to automate software compliance checks of all kinds. It started out with license compliance, but now there is way more than that. There's security compliance, vulnerability checks, software health checks, much more than that. And it's not limited to checks that are related to open source software. You can also do checks on your proprietary software using or and server. As or server is based on or we still

benefit from the same best-in-class software composition analysis, for example, and from the same um plug-and- driven integrations for all kinds of things, including report formats and so on. And in essence, it's like source code goes in, then the magic happens in the cloud and compliance documents come out. So let's zoom in a little bit into that cloud which is powered by or the different tools in or

um let's just go very quickly over this. So there is the analyzer which is the software compositioning uh an analysis engine. Um, I'll skip over the downloader, which is an internal component that's used by the scanner to download your project source code, but also the source code of all your dependencies that have not been scanned before. And then you can run any scanner of your choice on

the source code. The advisor is uh responsible for giving advice uh about vulnerabilities for example, but also software health and uh other kinds of things. And the evaluator uses the metadata that has been collected by the previous tools to feed the metadata into your own custom policy rules. So that's what Helio and Thomas presented u with their evaluator rules, KTS files and so on. And then the

reporter in the end can create a myriad of different kinds of reports, not limited to sbombs and sbombs in different formats and so on, but also attribution documents, nice company branded PDF documents that you can ship with your software, whatever. Yeah. Um, a little bit of history um um fun facts about or so. So, it all started in uh 2017 already. So we've been around for a

while in the compliance uh domain as uh um as an internal tool in in a company called here technologies uh which um yeah basically came out of Nokia when there was this split between Microsoft and and and here technologies and all of a sudden we were in a sort of vacuum about um um having no OSO having no policies having no tooling anymore to perform uh compliance

checks. So we somehow needed to stretch our itch own it um as developers um to report um things like the dependencies that we use and the license uh licenses of those dependencies to to product owners and management and after some evaluation we decided to write our own tooling because there was no good fit for uh for us to solve the problem. So after some internal experiments uh

the whole uh P was basically combined into a Cotlin based project and made public um in March uh 2017 on uh GitHub and from then on it was fully developed in the open. It was always yeah there there was never code basically hidden uh behind and then only being published afterwards. It was always bleeding edge fully in the open. And um a little bit later uh the

project became popular and wider uh widely more widely adopted by by Bosch and others. And uh we have an adopters MD on on the GitHub project. So we can take a look who's officially admitting to use or and um with wider adoption also the scope grew from uh originally licensed compliance to yeah general software compliance checks including vulnerability handling and then in 2020 we transferred from the

um here technologies uh GitHub organization to a neutral um host um also in the context of becoming a Linux foundation project. So by now the project has about uh 160 releases because we usually do weekly releases uh about um 2,000 GitHub stars. Uh so please leave us a star if you uh enjoy the project and about uh 120 contributors. So compare that to server uh which is

the newer project to complement um or to make it more enterprise ready and scalable. So the project originally was um created by yeah sort of the team I was formally in uh at Bosch um somehow around yeah mid uh 2022 um and it the whole project was basically born out of the recognition that art is super powerful it's super configurable by but it's also complex um and

this whole configuration as code policy as code thing works well for developers and technical people. But there are also other ospo people, legal people, attorneys that are maybe feel not so comfortable with um writing YAML files or so. Um then we have a central web front end as part of O server which uh kind of solves the problem of works on my machine. So because ART is

so configurable, people tend to configure it differently and they get different results and then there is some hey I get this violation and you get that violation. So we solve this by having a common view for all people that work on the compliance process uh via a common web front end forward server. Yeah. Then sometime 2023 in November um the official proposal was handed over to Eclipse

Foundation for the Appapsis project and then a bit later in 2024 um the code was then uh made public um as part of that Eclipse project and UI development started from our company actually double open. Okay. Uh so then yeah uh 2025 we had the first real official release on GitHub and by now the project has about 80 releases uh 60 GitHub stars so way less than

or because it's younger but it's also yeah less popular maybe just yet and uh we only have around 20 contributors so please um again uh leave us a star and consider to contribute if if you feel like taking a look at the in a nutshell um here again a short side-by-side comparison of or versus server. So target audience originally in or was mostly developers technical people. For

server our aim is to target everyone everyone involved in the process. Uh the interface in or it's uh primary command line interface and configuration is code. In or server we have a web UI and a rest API. So it's API first design. So there is no functionality in the web UI that would not go via the rest API. So everything that you can do via the web

UI you can also do via the companion command line tool for or servers rest API. Um scaling an or is sort of manual. So you can very well integrate it into various CI/CD systems but it's a manual process. We do have some templates for GitHub actions and stuff. Um but in order server it works differently. We have helm charts and you deploy either to your to your

own cloud basically uh to kubernates or you can ping us for our SAS offering uh at double open where you get everything readily configured out of the box. Um when it comes to access and user management there is basically none natively integrated into or um but in or server you have enterprise ready integration uh with OICD providers and and um key clock how does that all relate

to the cyber resilience act now and how does o server help here so for the for the purpose of this talk we've um split CRA sort of into kind of phase is so uh if you have been following one of the other CRA related talks during the conference then you know it's it's not like a strict to-do list that you can take off and then you're done

with with uh CRA um it's more like a process description or requirements for processes and it's also an ongoing thing right so you need to monitor releases regularly for vulnerabilities to become known and stuff like that so it all starts in the initiation phase basically with with something like a product definition what is your product and um this is something where Oserver can help already because we

have a sort of hierarchy how we organize things uh we have an organization level we have a product level we have a repository level and Martin will show in the in the demo section how that's all looking like so everything that's orange basically on this slide is stuff where we can help you with server to automate your CRA process uh so let's focus on on the orange

things maybe um and skip the risk assessment for a bit because there there is of course a lot of manual um assessment and work involved in into the risk assessment. But when it comes to pre-launch activities like following best practices for dependency uh management for example that's something that touches up to what what Helio said. So um we implicitly check for best practices in dependency management because

only if you follow these we can really fully automate the software composition analysis and there are a few things special about how we do software composition analysis and others do it Just saying that for example many of the tools out there just do static analysis and don't take things like dynamic version conflict resolution in the transitive dependency tree into account. we do for all the languages that

we support. Um yeah, vulnerability handling uh via OS advisor is something that we cover also dependency management uh uh and asbomb generation, but we will see in in the in the demo later. Plus continuous vulnerability monitoring uh by rerunning compliance runs or checks uh on on the products that you defined. plus archiving functionality like uh sbomb uh sorry not sbomb source code bundles and uh yeah archiving

of reports like we still generate for example the web app report that was shown earlier um for for archiving purposes um yeah then there is uh one more project to mention here uh which is the octed project it's a EU funded uh project that complements ments the fantastic work of the OC working group from Eclipse. So I hope you attended one of the OC related talks uh

because these guys are really doing an awesome job at um creating an FAQ and in general documentation and clarifications uh about all things CRA. So these guys are more on the let's say documentation side of things and the octed project is more on the tooling side of things. So we now try to concretely create the tooling that uh implements the right things uh and the right checks

um to get you started with automating your compliance checks uh especially for small to medium enterprises. So everything we produce as part of octed is open source and the the workhorse of octed is or server. Um but there is not only server we just like or of course we do integrate with a lot of tools from the ecosystem for querying vulnerabilities for running compliance scans and if

you're interested in the octed project and how we could helpmemes in Europe to automate your CR checks please uh reach out to us because we're actively looking for testers. >> Okay now finally it's uh demo time over to Martin. Yeah, thank you. [clears throat] Okay, so let me take over. So I was just switching recently to double open at the beginning of this year. So I was

working still at Bosch when all the odds server development started and um at that time we were using an Azure pipelines based approach to scale. So we were building a custom Azure pipeline to run the old CLI tools, but we were hitting kind of a dead end because the amount of scans we were running every day um somehow became unmanageable. So it was about 400 runs that

we were running every day, 400 different scans and we wanted to have some tooling to have a better overview about what's happening. We wanted to have more functionality to also aggregate data from different scans and to just enable use cases that were not easily possible by just using the O CLI which basically just um creates files as output and you would have to take those files and

some manually put the data somewhere where you could aggregate it. Also, we wanted to have a better overview about the different clients within Bosch that were using our system. And out of that the decision came to build the odds server project. So what you can see here that's the basically the initial view of the odds server UI which shows you an overview of the different organizations and

that what we use to organize the clients. So basically every client or every user every team would get their own organization and within that organization they could organize their repositories. So for the purpose of this um demo I created one example repos organization for the OCX um and you can immediately see one thing that o itself does not provide out of the box which is an overview

of all the data that is um [clears throat] yeah uh uh coming out of the scans within that organization. So you get an [clears throat] overview about the amount of vulnerabilities that are found, the amount of issues, um the rule violations which is also if you have seen the previous talk from Helio and Thomas um are these rule violations based on your custom compliance rules and you

can also get an over overview about all the different dependencies that all your uh projects have. So you could also hover about over one of those graphs. So you could see in this example for here I have about 1,300 Maven packages and uh one and a half thousand npm packages as dependencies and I can also check the severity of of the vulnerabilities which I found and get

a very quick overview about yeah everything within my organization. so let's look at the one of the products. So repositories are grouped within products because very often you have multiple git repositories which make up one product. You might have different repositories for front end for back end and and for other stuff. So but still these [clears throat] things are often released together. So you also want to

um group them in some way that you can have a good overview about the individual projects uh products that you are releasing. So in this case I just made a sample repository which contains one um I mean a sample product with one sample and you have the same view here that you had before for the organization. So you can also just go into one of the products

and get an overview about all the different repositories that make up your product. so let's go into the serj example I made. The SEJ is just a Java library for yeah for [clears throat] men for semantic versions. I use that because it's a small project and it's very easy to do test runs and it's a a good example for for testing if everything is working correctly. [clears

throat] you have again the same views that you had before but now just for that single repository. Um and that here shows you basically the view of of your last run that you did. So you see the last run created two vulnerabilities. It did not have any technical issues, no rule violations. And you can see this one has just 13 Maven dependencies. you can also see here

um that the O server is a bit more opinionated. So by itself tries to be unopinionated um and be as flexible as possible. So you can configure odd in whatever way you want and use the tools to build your own pipelines. Oserver basically [clears throat] already runs the tools in a defined order and also decides a bit how they are orchestrated and that was also done for

performance reasons. So you see here these traffic lights show the different tools you have seen before. So the first one is for the analyzer and you can see immediately from the color was there some issue with running the analyzer then it would be yellow. Did the analyzer fail completely? It would be red or did it pass like here then it becomes green. And the subsequent steps are

the advisor tool, the scanner tool, the evaluator and finally the reporter tool. So this allows you also very quickly to get an overview. So if we would go back to OCX here, I could quickly just if I look for example this this odd test organization, if you have multiple repositories, you can at a very quick glance you can see here, okay, these repositories have issues with the

scanner. This other one has an evaluator error and so on. So it allows you to yeah just very quickly see what is the status of my compliance [snorts] Okay, let's go back to the sample So like Sebastian said, um configuration as code is very nice for developers, but there's other people involved in the process who might not be comfortable with writing YAML files. So that's one thing

we also want to do is to um add UI which makes it easier for lawyers or other people in the process to create this configuration without having to manually write YAML files or to copy paste uh code from some report over to some other file. So I want to show you the uh how you could also resolve vulnerabilities in your project just via the UI. So you

see can see I have here four runs for this repository. So it shows you also initially here this nice graphs which show um how long did the pipeline run. You can see here the red is for the scanner. So usually with odd if you run use scan code scan code is finding a lot of licenses but it's also taking its time but of course we are caching

results. So you can see the first two runs with a different version. So the scan code took about three minutes to scan all the dependencies to get the licenses. But on the subsequent runs all these results were cached. So the scanner suddenly became a lot faster. This also allows you to quickly see do I have any performance bottlenecks. So you can see why did my scan or

my analysis take an hour or so. So you could very easily see okay it was an analyzer issue or it was a scanner issue. So I made four test runs here for that repository. The first one was for a recent revision of the symbol forj project and you can see it did not find any issues, no vulnerabilities, no rule violations. So everything is fine with that project.

So not not good for the demo. So I decided to scan an earlier version which is version five from a a few years ago. And here we found two vulnerabilities in the dependencies of So if I go now to that run, I can go to the vulnerabilities overview and I see there's two vulnerabilities found in the assert J core uh dependency of the project. So what we

show here is um also all the details of the vulnerability. So you get the full description. You get this nice radar view to show the different um aspects of the vulnerability [clears throat] and after the description you get also all the references that the providers u um um gave for that vulnerability. So we fully embrace the plug-in architecture of O which means um you can use so

does not implement all the tooling itself like was also shown in the previous talk but we are basically orchestrating and integrating other tools which already do what we want. So for vulnerabilities for example we have OSV vulnerable code and a few other tools which you can select which one do you want to get the vulnerabilities and it's the same also for the scanner and and the other

parts. in this case [clears throat] these references are coming from um I think it was either o OV or vulnerable code which I did select and you could go also to the links to check what does the reference actually say about the vulnerability and what is the score and So if you decide this vulnerability is not relevant in my case. So let's say this one here is

about some specific function which I think yeah if some specific specific functions are used then you might be affected by the vulnerability. If you say that's not the case here you could simply go here and do what you could also with do in the YAML file. So with you would write some entry in your oyl file to say this vulnerability doesn't affect us with the odd server

the you can also go here and say for example this is is an ineffective vulnerability. it doesn't apply to me. Provide an explanation why it doesn't apply and then create the resolution. Because doing a run takes a few minutes, I won't start a run now. So I have prepared this already. So you can see here on the second run, I still had to vulnerabilities, but I have

created a resolution. Oh, did I? Or maybe not. >> I I think you selected the wrong run. Maybe I selected the wrong one. Let's go to the next one. So I see here the first one is marked as resolved. So I could also just filter here by status and say I only want to see unresolved vulnerabilities. In this case um I'm showing all. So this one was

And I made a resolution uh explaining none of the vulnerable methods is used in this project. And then this will not make the um um the vulner [clears throat] uh uh what is it the advisor step not report vulnerability in this case. And also your evaluator rules can respond to that and say that vulnerability was resolved. I do not need to to fail the scan. [clears throat]

um the way works is always so that you have to do another run. So you see here that's already deleted pending rerun because I um created the vulnerability. It applied to the next following run and then afterwards I deleted it again. So if I go to the next run the resolution will be gone again. So you see here that everything is marked as unresolved again. You can

of course still use the config code appro approach. So we do not want to force people to use this. We we think that's easier for many users to use a UI to manage all that stuff. But still a server allows to configure everything in the OTML file or [clears throat] um yeah whatever other config files we have for so it's fully compatible but a bit more opinionated.

Yeah. What else can you see here? So basically it's a bit like this web app report Thomas has also shown. So where the web app report is just a single HTML file or creates at the end where you have all the results in this server use case it of course makes a lot of sense that the UI shows all the data as well. So you can also

go here and see what projects did it find. So you see forj has just one maven project in its own and you have also a view for all the packages that were found. So packages are dependencies in this case. So you can easily see what dependencies do I have from what ecosystem are they coming from. You can filter by different types. You can say show me only

direct or transitive dependencies. You could filter by package ID or by declared [clears throat] license and so on. And you can also if you prefer right now we show the pearl because that's I think the future for package IDs. But if you still prefer to use the old o internal identifiers, you could also configure to show ids here. yeah, what else? So of course you have a

view for rule violations which we don't have here in this project but you can also show detected licenses. So you could see okay I have some Apache license found somewhere in my dependencies. You can show which packages did contain it if it is loading. Maybe I should Yeah. Okay. So then you can see all these packages from my dependencies have an Apache license detected within them by

scan code in this case. And then you can also go further down and show exactly in which files of that dependency did the scanner find the um Apache 2 license and UI is still a work in progress. So of course the plan is that you can also address um um false positive license findings here in this case. So O already provides the capabilities for that. You could

in your YAML file you could put um license finding curations. You could say here the scanner had a false positive for example to detect a license which isn't really there or doesn't really apply to the project and in the near future this these features will also become available in the UI yeah for the last step reporter of course we also support generating all the different reports that

creates so we have put the sbombs in a bit more prominent place so you can directly see the cyclonx and spdx reports and download them from here but we also generate all the other reports that o generates on demand. so in this case the only thing I created was a scan report web app which Thomas has shown in the previous talk. So you can also for example

generate an o result file as output and then you could hand over the o result from the server and still processes manually locally with the CLI tool. Let's say you just want to do some debugging some testing. You want to change evaluator rules. You don't want to to deploy them somewhere. You just want to see locally as a developer or maintainer of an Oserver instance. What would

be the effect of changing this configuration? You could just do it locally with the OT CLI. So it's in this regard fully compatible. Doesn't force you to do everything on the server. Yeah. So last thing I want to show is um how do you actually start a run? just to show that we [clears throat] fully com uh support also all odd plugins which are available. So you

usually have to select of course a revision of the repository you want to scan. In this case I selected the tech for version five. You could configure some other stuff like uh scanning only a subdirectory of the repository which is something you might want to do in the case of monor repos. So if you have a repository with a lot of projects and different subdirectories, you can

limit the analysis to just this subdirectory. Otherwise, it might create far too much data to process or it might not yeah just not make sense to scan everything at once. Um the server also supports configuring different different rule sets for different clients. So in this case for example at Bosch we had different um departments which might use different compliance rules based on their own lawyers or their

own interpretation and the odd server allows to configure this. So you could have different rule sets which would be selectable here and then you can also see the labels again which are used to configure stuff uh just provide additional information to the reporters and mainly the evaluator to decide which compliance rules do apply to this project. Um yeah and you can of course select which steps do

you want to run. So not in all cases you want to run all the or tools. Sometimes you might only be interested in the SCA result and you might want to get the vulnerabilities but you're not interested in license scans or you do not even want to run the evaluator and reporter tools because you're just testing if everything works. So you can easily select here which steps

of the tool chain should be active and then you could also configure which of the odd plugins do I want to use. So let's take the example of the advisor. You can then go here and just see the different advisor plugins or test. So in this case black duck os index ov and vulnerable code. You can select which one do I want to run and then these

will be executed during the pipeline execution. Um this is also not uh hardcoded but you can actually also write your own odd plugins. You might open source them, but you might want to write some plug-in which is only company internal and then you could inject that plugin into the um Docker container and it would automatically appear here and also all the config options of your own internal

plug-in would be um visible in the UI for the for the users. >> Yeah, I think that's everything I wanted to show for the UI. I think we have still enough time left. Was there something for after the demo? I think >> um maybe one thing to still show in the UI uh just to give people uh better understanding of the amount of plugins that we support

we could briefly go to the admin page and browse to through the installed plugins because um that's >> I would have to log out and log in again user then maybe let's not do that >> but I could show for the analyzer for example uh we have these so this is currently the list of all the different package manager ecosystems that supports [applause] >> yeah yeah yeah

may maybe one thing that uh was worth uh or is worth highlighting is you probably saw black duck as an adviser there. So we we do not stop at integrating with open source tools. We also have no problem basically with integrating with commercial tools as long as the API is open and there is some library we can link against and that opens for example migration paths for

companies right so if if for some reason you want to compare how good are the results from my commercial scanner or commercial vulnerability source compared to an open source source then you would want to integrate both into or server enable both at the same time and then compare the results And if you're happy with the results of your your alternative solution, you just switch and migrate. So

the the whole point of or is yeah, not only to orchestrate things but also to abstract the details of the data providers away so that your users don't actually have to care uh what tool you're using underneath creating a smoother user experience. Yeah, maybe that page also shows that we have some unique um uh features. I think I'm not aware of any other SCA tools which would

support some of those uh uh ecosystems. For example, we have Tao support which means um Eclipse Tao [clears throat] project could actually use all for their analysis and during our experiments we haven't found any other commercial tool or so which properly reported these kind of dependencies and also we have for example support for stuff from the Erlong ecosystem which was built by the people from the alloc

foundation themselves to integrate with and that's also something where I'm not aware of any other proper integration into SCAS if you are using any language from the along uh uh ecosystem. >> Okay. Yeah, our timer here says we have still 10 more minutes, but um to not overrun our regular schedule for too much, let's um switch over [applause] to the outlook. So what else is in there

for um the next steps? So um of course we aim to bring all remaining or functionality to the UI to make it more accessible which includes um showing the dependency graphs on not only a flat list of packages but really the hierarchy of dependencies which is important in some cases plus um integration of snippet findings. So there are these so-called snippet scanners that are able to detect

copied code snippets and not just license and copyright statements. uh instead of producing sbombs, we would also like to be able to import them in a similar way like dependency track does it um plus uh more sophisticated release monitoring um to make it easier for people to track their releases and any new known vulnerabilities that uh may occur. Uh another topic where we are collaborating with uh

other Eclipse projects as well is uh general dependency health metrics. So we would like to give people advice via the advisor component about their choice of dependencies. Not only about how many open issues are there or how many vulnerabilities are there but also um about how popular is the dependency, how well is it maintained, how often do these people do releases. So there is a ton of

metrics that we can talk about with respect to um software health or or dependency health uh metrics. Um then we aim to cover not only CRA requirements but also Doron is two requirements including the paperwork at some point in time because there is still a lot of work that you just cannot automate away. Uh but you still would want to store all information related to the process

in one place. Uh so that's also something we're looking into. Plus in general that's an ongoing topic. uh improved integrations and notifications like whatever getting a push uh notification to your Slack channel if uh compliance run finished with issues or something like this. And that concludes the talk. So thanks for listening. Uh we are still around for a bit but not until uh tonight. So uh feel

free to approach us soonish after the talk and we have some time for questions I hope. >> Absolutely. Thank you for a really good talk. I'm amazed by your work and also think you're very brave. Right. First, they had a live demo. Secondly, they try to write and be friendly with people that doesn't love writing jaml files. You're very brave. A big applause for these SPEAKERS and

questions. Hands up. Of course, you have questions to these brave speakers. Yes. Hang on. >> Yeah. Thank you for the presentation and I wanted to ask you how does this tool compare to the penacy track for instance which I recognize is is doing something similar. >> Yeah. So there's certainly some overlap. I'm not an expert on dependency track but um so we know that some in some

settings the goal is actually use the parts of the tool which dependency track does not provide like the SCA part or so but upload the sbombs created by by the odds server to dependency track because some people's already have an existing workflow for vulnerability management based on dependency track and we're actually aiming there was one point in this outlooks uh uh uh to improve integrations so having

some integration dependency track to upload sbonds automatically for example that's certainly not something we so it's something we would like to do but um at the same time we also want to provide the functionalities to properly do a vulnerability management so so there will be some overlap >> yeah may just shortly too I meant to that um historically dependency track came more from the security side of

things and we came more from the from the license compliance side of things but over the time we converged a little bit so by now you can also do some license compliance stuff in dependency track and we have these advisor for So I would say yeah there is some overlap but the most distinguishing factor is probably our um SCA analysis which dependency track does not have. >>

Yeah and probably also the customizable um compliance rules. I'm not sure what uh dependency track allows uh there. uh and as a member of OVASP uh I can add that you have support for more I would say espe file formats uh dependency track is has a data model uh that is developed I mean cyclone DX came out of dependency track dependency track was first so that's why

it's very tied to the cyclone DX format but you could of course hook in dependency track through the API engine into or server if you >> Um, dependency track uh continually scans sbombs to search for new vulner vulnerabilities. Uh, does server do the same or does it just run it once or uh on demand? >> Um, not yet automatically. So you could configure um triggers on your

own CI for example to to automatically rerun uh um the the advisor tool. But that's on the road map to to do the same thing. So we definitely want to have an automatic reporting of newly found vulnerabilities for projects you scanned in the past. So it's a road map item so far. >> Okay. One more question, a repeat one. >> Okay. A very technical one. Um you

say that you also check out the source code of dependencies and buildings these things. Is that right? >> Not building. Not quite. Oh. >> Oh. Quite. Okay. All right. So that was >> so maybe you want to >> give a bit more detail. >> So we are hooking into the build system to ensure that we are getting exactly the same dependencies that the build system defines including

dynamic things like version conflict resolution, version constraints and stuff like that. But we don't build the actual project. So that's difficult to do for many build systems that don't really support that. But that's exactly one unique thing that we managed to do. >> Another question, have you looked into producing in totalto at the stations as part of the or process? >> That's another roadmap item. So we

haven't closely looked into it, but we are well aware that um signing as bombs in to attestations and stuff related to that is certainly something we need to address and and uh add support for. >> A bonus question. Uh yes, one more question. Do you also have support for full OS distribution tracking of the possible CDs? So YTO base embedded Linux or Debian and things like that.

And how would you integrate them otherwise? >> Yeah. So historically or was not built for distribution compliance. It was built for application compliance. But we do have workarounds. Um so um for example YTO bitbake can already generate spdx uh files and I've mentioned asbomb import uh at some point in time. So via that mechanism we will be able to uh import as bbombs and then do checks

on on on the stuff mentioned in the asbombs but we run into different problems than for example naming of packages right so it's super hard to map vulnerabilities and do queries by pearl for example because opensl and yto is not the same packaging as opensl in the same version in debian so there are some difficulties okay and with that we have to apolog apologize to all of

you because that room is already ahead in the breakfast uh lunch buffet out in the big room with the exhibition. We expect to see you here uh in exactly 55 mission minutes because we have an important mission then mission Cray. So make sure you come here and that you get a seat because it's going to be filled with agents agents. A big applause and thank you again

to Sebastian and Martin.