ORT Server: An open source platform to automate CRA checks #FOSSBack

This talk introduces the OSS Review Toolkit (ORT), a platform designed for automating software compliance checks, including license and security compliance. The speaker explains the evolution of ORT, including its origins from internal scripts at HERE Technologies to a widely adopted open-source tool hosted under a neutral organization. The session highlights the ORT Server, which aims to simplify the usability of ORT by offering a web UI, REST API, and scalable architecture, making it suitable for both developers and project managers. The speaker discusses integration with existing tools, user management features, and the toolkit's ability to generate software Bill of Materials (SBOMs) in various formats, such as SPDX and CycloneDX. Lastly, the talk touches on future plans, including enhancing integrations, monitoring releases, and addressing broader compliance regulations like the Cyber Resilience Act.

Yeah, thank you and hello everybody. So while I don't want to talk too much about Martin and myself in the beginning, I think it's fair to say that we are both veterans of the or or OSS Review Toolkit ecosystem. So we've been there since the beginning more than 8 years. And also for those of you who attended Emily's talk two talks behind basically um I would say

the the company we're working for double open is yeah an open source company in Emily's definition. maybe for the fun of it who's already familiar with what the OSS Review Toolkit is. Who has been her yeah tried it out or worked with it already. Okay, quite a few people in the audience half maybe. So for those of you who are not aware about what the OSS Review

Toolkit is on a super super high level in a nutshell it's a platform to automate software compliance checks. So it's not strictly limited to license compliance checks, although that's where it's coming from. It also extends to security compliance by now and other things. Um I think it's fair to say that it comes with best in class software composition analysis for the supported build systems. So we do

some things quite differently than many of the other tools do in the market both commercial and open source. So if you think about Dependabot or whatever. So it's at least my personal strong belief that these tools are not doing it right and to some extent we can also prove it. But that's not part of the story here for today. and then uh in general we don't intend

to be uh a strict competitor to many of the other tools, but more integrate with existing tools. So, we have a very highly configurable and plug-in driven architecture with integrations and a lot of report formats that we can generate. And uh yeah, this picture on the bottom shows on a really high level. The idea is you put source code in, then the magic happens, and you get

compliance documents out. You can imagine it's way more complicated than that, but that's the rough idea. let's take a brief look at the history of ORD, the original OSS Review Toolkit, which is command-line based, so you better understand the motivation for us to create the ORD server. So, uh the project has been around since roughly uh 2017, where um I back then at a company called HERE

Technologies, which was somewhat a successor of Nokia, um was creating a bunch of internal scripts to analyze the code bases written in various different programming languages in in the company to fulfill uh license compliance uh checks. at the same time, we we basically rebuilt uh the HERE internal open source office, and we decided to develop everything fully in the open to begin with. So, about 3 months

later, we created the first public commit of uh then unified um project written in Kotlin, which was the original command-line interface uh to to ORD. Then some months later, um the name OSS Review Toolkit was first mentioned of the README that we committed there. By 2019, wider adoption um was was uh received um by companies like uh Bosch, for example and also the scope grew from the

original scope like I mentioned license compliance and then security compliance and and other stuff also general community health metrics. to have further help the the wider adoption we at some point transferred the GitHub repository to a neutral organization so it was not hosted anymore at the HERE Maps umbrella but in its own GitHub organization. And as further adoption grew we switched from a rolling release model to

Samver based releases because many of the commercial companies that were using our tooling to um assist with their compliance processes they they wanted to have releases that they can refer to with version numbers and so on. Fast forward yet again three years later today we did 153 releases we received around 2,000 GitHub stars which is not too much if you compare it to Open Claw or things

like that but for a niche project like this and for a project that is mostly used by proprietary commercial companies and not open source users it's it's quite okay. And we managed to at least attract 122 contributors which is which is not easy. Growing a community is not super easy. So in contrast the ORT Server then was basically created to make ORT easier to use because originally

it was a tool created by developers for developers to fulfill the requirements they were receiving from product owners or so on the ORT Server first started as a company internal project at at Bosch. It was actually my my former team at Bosch sort of that that started the project. And then it took quite a while to make a formal proposal to the Eclipse Foundation, um, to create

the App or Absis project under which the Ord server is now hosted. And then, yet, uh, a few months later, the first public code contribution was made in February, uh, 2024. And then only the UI development started. So, until that point, there was sort of only the back end and and the API. And then, uh, March 2025, there was the first, uh, 0.1.0 release. And again, fast

forward to today, we have 77 releases, only 50 GitHub stars, right? So, that's quite a different number. Uh, although the project is younger, of course, and 19 contributors. So, if you feel like Ord is being a good project, please, uh, visit the GitHub, uh, page and leave us a star. That's always, uh, motivating us developers. moving to a side-by-side comparison, um, to to give you a better

understanding of what those two projects are and what the target audience is. So, Ord, like I said, it was targeting mostly developers in the beginning. Um, of course, people started to pick it up and and, uh, created, uh, fancy and sometimes crazy workflows around Ord in their own CI/CD systems. And it's working okay for most, uh, of the people who are very deeply into the Ord, uh,

topic. But, the Ord server is really meant to be used for for everyone. So, including, let's say, low-level, uh, developers up whatever project owners, project managers, um, people working in OSPOs on policies, legal people, everyone. The interface, I've mentioned this multiple times, uh, for Ord is the command-line interface. And we follow paradigms like configuration as code. You write the YAML files to configure Ord and stuff like

that. And not everybody feels familiar or comfortable with writing YAML files. So, uh the Ort Server, it has a nice uh REST API um or a web UI that talks to the the the REST API and makes it really more visual and convenient to use. Scaling has historically been a problem with Ort because of of course you can call the Ort CLI in your whatever GitHub action

nodes and scale scale that way somehow, but it at the latest when it comes to the process scaling, so how do you curate package metadata at scale, how do you review um scanner false positives at scale and and stuff like you um there are some boundaries and um we are trying to solve these in Ort Server as well. On the technical side, scaling is is done by

a Kubernetes and uh the UI helps a lot with uh scaling the actual review work and implementing your processes. then finally something that Ort does not have at all. Um it's about uh access and user management. And on the Ort Server side uh it's sort of enterprise-ready. We have uh OIDC uh integration and um user management via Keycloak. How does that help you now with fulfilling obligations

from the Cyber Resilience Act, the CRA? So, the idea is um you can briefly again on a high level maybe separate CRA obligations and requirements or activities that you need to work on into those four uh phases. So, note by the way, this is not aiming to to map things to a software development life cycle. It's a it's a different view. It's more close to the original

regulation maybe. And there is a phase that we call initiation, and as part of that you have a product definition. So, everything that's written in pink on this page is something where we believe ORT Server can help you to highly or even fully automate your obligations. So, the product definition is something that we can depict in ORT Server uh in a hierarchy um because we have, as

you will soon see in the in the demo given by Martin, um organization, product, and repository levels, and you group repositories on the product level. That's your implicit product definition, sort of. For the risk assessment, that's um yeah, mostly still um human work that needs to be done and documented. That's not something we we cover yet. But, looking at the pre-launch activities, uh for example, development practices.

That's something that we implicitly check when analyzing the code base for dependencies um because it will work best if you follow certain best practices for dependency management and maintaining your build system. So, you implicitly get technical issues if you don't follow these best Similar for uh vulnerability uh handling. So, we have a lot of integrations in ORT that talk to vulnerability providers like uh Google OSV or

about code vulnerable code or um what's uh what's their Sonatype OSS index and other stuff. Uh dependency management is somewhat related to the development practices. So, um if you if you already do proper dependency management with a dedicated package manager in use, then uh this will make, of course, your life much easier and and the results better. And that's also something that we implicitly check for when

doing software composition analysis with with the ORT analyzer. And finally, SBOM generation is uh of course also built into ORT, so it's uh one of the many plugins we have for the reporter step. So, we can generate uh SPDX SBOMs, CycloneDX S-Bombs in whatever YAML, JSON, different schema formats. So, you're covered there as well. Then, when it comes to post-launch you also need to regularly monitor your

product for vulnerabilities, even if you don't have any code changes. It could be that vulnerabilities are only discovered after some time into the market. This is also something that we can help with scheduled jobs that will come at some point to regularly creating analysis runs on on the product not triggered by code changes like pull requests or whatever. And also on the side of archiving the software

that belongs to your product, we can assist with the source code bundle that we have and yeah, create archives for maintaining your code base and the dependencies for whatever years you need to keep them in order to build them also when open source projects disappear, maybe. Okay. Yeah, finally it's demo time, so I'll hand over to Martin so you get a glimpse of the odd server UI.

Okay, thank you. Oh, my mic is working. Okay, so I just walked you through the UI. Um So, this was mainly built at Bosch as you heard already. So, as an internal tool mainly to replace the Azure-based pipeline that we had for running odd because it just didn't keep up with the scalability requirements we had back then. So, and because of that also the structure is a

bit tailored around this use cases we had there, but we we believe that works well for others as well. So, the basic structure is that on the top level, you have organizations by which the yeah, the whole content is structured. So, for this case here I created in Foss Backstage organization. And within one organization you can group repositories, so code repositories into different products. So, for the

example case I made here one for Eclipse over for the old server project, one for the old S3 view toolkit and sample repositories, which is what I will use for the demo now. So, this is already one feature that you couldn't have with old. With old you just got a lot of YAML output files and you would have to manually collect the data somehow group it. And

with the server you have here a complete overview of the organization. You can see a summary of all the vulnerabilities that were found during scans in this organization across all repositories and the same for issues and rule violations So, if I go now to the sample repository So, I used for this test small Java library called SemVer4j. So, just a library to work with semantic versioning in

Java and used it just to have some small sets of sample data. So, if I go into here and just show some runs. can see here I first did a scan of the current main branch of that library. So, you can see the revision down here. And it actually did not find any issues here. So, you can see here a quick summary which shows the number of

technical issues found, vulnerabilities and rule violations found. So, that already shows So, from that perspective everything is fine. But because I needed some problems for the demo I scanned a pretty old version version 5.0 from sometime in 2023. And here we could actually find two vulnerabilities. So, I can now have a look at that. And I see that there were two vulnerabilities found for some test dependency

of the project to assertj-core. And then basically if there is a vulnerability found in a dependency there's just a few things that could be done. The first thing should of course checking is there a new version available which doesn't have the vulnerability anymore. But let's assume in this case this is not possible. So then you could either just somehow try to get rid of the dependency, or

you could try and check if this vulnerability does actually affect your And for that case we show also all the vulnerability details here. So you have a You first that um CVSS radar which shows a bit um the severity of the vulnerability. We have the description and also a long list of all the references that we got related to that vulnerability. So we can do the research

on your own. You could click on those links and check check what is actually behind that in detail. You also have this here. If I collapse it again, you can see we have two vulnerabilities here which are actually just coming from two different providers because the whole thing is not a rewrite of all that's all completely based on the odd code. It's just a new way to

run odd. And of course that means it also supports all odd plugins. So in this case for example, we have two advice providers that can retrieve vulnerabilities and one is valuable code and the other one is OSV. So both actually reported the same vulnerability here but just with different identifiers. One had a CVE, the other one some I think that's some GitHub ID. I don't even know.

as if this is just um if you look at the description, this is just some it even says here um the application is vulnerable only when it uses untrusted XML input. So let's assume we do not use those functions. So we want do not want this vulnerability reported again in the next run and we want to show that this is fine. So that's when I could create

a resolution and I would select a reason. In this case for example, I could say that's ineffective here. And I could say yeah, let's give some reason. Because later you would I would like to understand why it was uh marked as ineffective, of course. So, you would have to give a proper reason here. Then I can create a resolution. And then it will show here already that

this resolution will be effective in the next run when I do a rerun because that's a pipeline based approach. So, in the next run it would recognize that resolution and not report that vulnerability again. So, because the run takes a few minutes and we don't have don't want to wait here now for 5 minutes until the run finishes, I have already prepared a follow-up run where I

did this already for the other So, you see here that in this vulnerability let me collapse it again quickly. I now have one which is marked as resolved and the other one is marked as unresolved. So, if I would run again, this is the one I just resolved, this would also be marked as unresolved then. And then I would get a green light basically saying no critical

vulnerabilities found in that So, that's the part mainly about yeah, CA CRA related vulnerability management. But, I also want to show what else we got here. now I just want to have a quick look at how do you start a run here? So, there's the UI that was added actually a bit later to the project. Maybe you remember from the remember from the timeline that was started

sometime in 2024 the UI development. In the beginning that was mainly about automation via CI integration. the the whole purpose was that we have an REST API that you could easily trigger from a GitHub action, from Jenkins, from whatever environment you want to start a scan. Uh um you could select exactly what scans do you want to run? Do you need vulnerability information, license checks? And then

you could get the result later And you will if you look at the form to create a run, you have of course a way to enter the revision that you want to scan and some detailed configuration. For example, here we have labels for the distribution type which influence what actual compliance rules will be applied in the end. So, this is here for the open source compliance rule

set. And you will now also resemble the ORT tools because I think at least half of you put your hands up that you know ORT. So, you will recognize those tools again. There's the analyzer, advisor, scanner, evaluator, and reporter. And we can configure here also in detail which of those tools we want to configure how. So, for example, you see here the complete list of package managers

is that is supported by ORT. You can select which of those you want to run and you can also further configure configure them. And it's the same for the other plugins. also if you I'll let me collapse the analyzer again. If you want to run the advisor for example, you also see a list of all the different advisors that ORT supports. So, we have currently here Black

Duck if you are customer of them, OSS Index from Sonatype, OSV, and Vulnerable Code where Vulnerable Code is itself an aggregator that gets vulnerabilities from a large variety of different sources. the scanner then of course is running uh the license and copyright scan. Currently, we have just ScanCode integrated here this step or Foss, but that's currently an admin configuration so users cannot choose. evaluator is our custom

compliance rule engine from ORT. So, that allows you to basically write any kind of of compliance rule that works on all of the data that was collected previously. So, you can write custom Kotlin script yeah, basically implement all kinds of rules from certain licenses are not allowed to certain packages are forbidden or whatever you could imagine based on that a data set. And the last step is

a reporter. So, odd also has like Sebastian said a lot of different reporters that you can enable and here most importantly in the CIA context is probably the Cyclone SPDX Cyclone DXS bomb and the SPDX best bombs But we also have uh many many others for integration with other systems. And maybe pretty important is also these template reports where you can also create custom templates based on

um what was it? Apache FreeMarker template language. So, you could also turn the data into any kind of PDF or textual report as you as you like. Okay, so once this fun run has finished, I also collect a lot of data and not just vulnerabilities, but I can see here that's me. Let me select the last run. So, I got a list of projects that were found

here. So, in this case there's just one Java project, a Maven project in this case, the timber for J itself. And I can also get metadata that we could capture from it, which is um yeah, quite a lot compared to other uh similar SCA tools. In addition to projects, I get the complete list of dependencies that was So, these are all the different dependencies that we got.

And timber for J is a small library, so I only got some testing stuff. I got the S-bombs that I could download here, Cyclone DX in XML and JSON format or SPDX in JSON or YAML format. And I also got the optional other reports. So. maybe to show you also how what it looks like for a bit larger project, could just quickly go through back to the

first backstage org. Let's select here the odd server So here it gets becomes a bit more interesting because you see there now on this project we actually have you over 1,000 different dependencies, 800 of them being Maven packages and about 250 of them being NPM packages. And therefore also you'll see a lot more and that needs to be handled. Yeah. Did I forget to show something? Not

from my point of view. Maybe just yeah, we don't have too much time left, one thing that I usually try to show or you need to help me with your touch but is the admin view of the plugins that we have. So just to give um an idea of the number of integrations that we have in here. So these this is the admin view of the plugins

that are enabled in the instance and they are grouped by type and if if we scroll down here you see it's it's it's quite a lot, right? And these can be managed on an admin level so that you enable certain plugins for some of the organizations and for others not and and so on. So it has a quite sophisticated yeah, template based plugin preset mechanism so to

say. Yeah, back to the slides I would say. Yeah, we just got 5 minutes left. >> Yep. what's up for the future? So maybe you recall one of the first slides said input is source code and then the magic happens and so on. One thing that we definitely want to do is to allow different kinds of input than the source code. For example, other S-bombs. So sometimes

you get supplier provided S-bombs that you want to import or you have for some other reasons existing S-bombs. And these usually do at least have enough information to check for vulnerabilities, for example. So, this is something we're going to implement quite soon. Um and also, in general, we want to bring all ORT core or ORT CLI functionality to the UI to really make it fully accessible and

on par feature-wise with with the ORT command line tool, but we would still respect your existing, if you are an existing ORT user, configuration as code. So, don't worry. There is a smooth migration path. You don't need to reconfigure everything and throw your YAML files away. They will continue to work, but going forward, you will be able to make, for example, issue and vulnerability resolutions via the

We will add release monitoring. In the context of CRA, that's important because you need to somehow track what has been delivered and released and do vulnerability checkups for your releases, for example. And we also do want to cover other regulations than the CRA, thinking of DORA maybe and other stuff, including the paperwork. So, while this is mostly not automatable, probably want to have a holistic solution where

you can track everything in one place. Just putting some check marks on your to-do list whether, yeah, you fully comply or not. And one thing that we always do and aim for is to improve our integrations and also notifications that we have. So, we can already notify via emails, via issue tracker integration, and other stuff, but there will be coming more, right? That's it. So, we have

some minutes left for questions and answers. Yeah, thanks a lot for your talk. I WAS JUST ABOUT TO SAY THAT IT'S NOW 52 stars, but I was correct, it's now 53. Maybe Yeah, yeah, keep up going, yeah, please. Good question. Uh thanks for your talk. Um I have a question regarding some security-related metrics. Is it possible, for example, to get some metrics which I can show or

analyze in Grafana dashboards and something else? Technically, absolutely, I would say. So, we we we're as a community also open for suggestions. If you have certain metrics in mind, this dashboard view that you saw, it's it's just in the making. It's stuff that we found useful, but we are also working together with um Fraunhofer, for example, who have developed some metrics about uh software health. Um and

and we're totally open to suggestions. So, if you feel that this or that metric would be useful, and please display it as a pie chart and not as a bar diagram, whatever, yeah, talk to us. For example, this vulnerability diagram that you saw, that's that's uh bar chart, that's just an endpoint call to the REST API. So, you could already fetch this with Prometheus, for example, and

then show it in Grafana as well. Yeah, that's a good point, by the way. So, the the the UI does nothing which is not accessible via the REST API. So, there is no logic or hidden features in in in the UI. Everything you see in the UI is fetchable or controllable via the REST API. So, it's an API-first design, basically. Uh another question. Um you already mentioned

the policy as code. So, is this still the concept for the ORT server? So, ORT generally was very um great in keeping track of things, so have a traceability, because every decision was a Git commit, for example. So, if I now have a resolution and do this via the UI, does this still make a Git commit in the background, and is this traceable, or how is this

handled with ORT server? Do you want to answer, because Um no, it's not it's not it's creating a Git commit in the background because that's actually thought for the audience which is not so technical. Um, so I would say for developers doing config as code would should still be the the way to go because you can have the config directly associated with every commit in your repository.

Um, what we do is of course that we have an audit log for everything that's created on the server. So, in the it will be recorded what resolution was applied, what was the reason, and who created the resolution. So, it's not on the Git commit level, but at least the information will still be there. And the data is not stored in Git anymore, but in a database.

But, the idea is the same. So, if you created a server a resolution from the server UI, then it will be applied to future runs on the on the repository just as if it was committed to a .org.yaml file in the repository. But, no Git commits made in the background. Yeah. Thanks a lot, guys. Thank you.