 Hello, hello. Thank you for joining our session. Today we would like to do the presentation about the sort of S-Born automation making comprehensive photographs by consuming and leasing and managing a sort of a bit of materials. Okay, so I am Kokihama. I'm from Toshiba Corporation and my main job is starting S-Born for our comprise and license and Yeah, my name is Arun. I'm leading the open source compliance activities at Siemens Healthineers based out of Bangalore, India. So today we would like to do the presentation. Okay, let's start. From at first I would like to do the explain general topic for the S-Borns. This is today's content that first I'd like to explain challenges in management software dependencies and so then talk about the consuming and leasing and managing software build of materials in the SW360 and first I would like to describe the automated dependence management with S-Borns. Okay, so first one is the training managing software dependencies. So maybe so if you develop some software, you have some programs about the dependencies for example, so if you use their big proof, if you develop the very big projects, you have several issues such as the bound software used for leading on numerous dependencies and their type is very different. So sometimes using C-Rangages sometimes you can use a completely different computer languages. It is difficult to manage all and of course if you develop the big software products, you need to check every vulnerability or license issues. However, so recently many people talked about the S-Borns and so I also think S-Borns is very important because if you develop your software with S-Borns, you can check many information with your products. Without the S-Borns, you can check only a very limited information. However, if you use S-Borns, you can check almost all information for your products. So S-Borns is very useful for verifying vulnerability and licenses. Okay, so and I would like to how to manage S-Borns. Yeah, so if you manage S-Borns in your organizations, it is difficult to manage them because due to the potential use of different management methods or tools by each different products. So if you have the problems about the Log ProJ, that's different product, a different department, manage different S-Borns tools. You cannot find which software or its product use a Log ProJ. Second difficulty is the S-Borns format. Yeah, I like the S-Borns format. However, many people need to use S-Borns like a legal department people. In this case, if you use S-Borns for managing your software product, you need to check Json itself. Is it really good for everyone? And so the other different problem is that in these times, many, many S-Borns tools exist. However, different returns, different results. So you need to consider which result is better for you. So it's a very difficult point in management S-Borns in your organizations. However, so to address these challenges, F-Borns needed to promote and centralize management across their organization, introduce tools to improve rigidity of S-Borns and ensure compatibility across tools. So I would like to say S-Borns 360 is very helpful to solve these problems. Okay, so what is S-Borns 360? S-Borns 360 is an open source software by the Greek Foundation. It is licensed under the EPL2 license that provides both a web application and repository to correct, organize, and make a viable information about software components. It's a sample issue a central hub for software components in organizations. S-Borns 360 allows for S-Born import, export, and tracking components used by a project or product and integrates security vulnerability tools, such as variable code, and maintaining a license obligations, enforcing a policy in your company, and so generating legal documentations. So the basic concept of the S-Borns 360 is centraling maps. So if you register the different information related to the S-Borns on the different tools, you may not find the good results. However, if your data centralized into the one repository or one database, you can manage it easily. So this is an example data of the S-Borns 360 which can manage. Now S-Borns 360 manage the component name or categories and types like the open-source codes or languages like C languages, Rust or Python, and software platform, and operating system, and main run sciences, and operating system or CPID. Like this, you can centralize the register S-Borns data, both GUI, and of course you can register data by the API which is the S-Borns 360 officially supported. So before I would like to do the demo about the S-Borns 360, I would like to mention the S-Borns 360 news. Last month, the S-Borns 360 released version 18. So from this version, officially S-Borns import and export and view function are supported. And so from this version, you can also build the S-Borns 360 by Docker Compos, like it's very helpful. So sometimes people don't want to install it with many times, but so if you can use Docker Compos, you can set S-Borns 360 on your server very quickly. It's not all an additional feature also included for a version 18s. And now we are ongoing development, so we are classic to new GUI frameworks. Now we are using a live play for the frameworks, the frameworks, but we are completely, we try to completely change the react from the live play to the react.js for frameworks. So if you are familiar with React, please join our community. We are always supported. Welcome your contributions for the new GUI frameworks. Okay, from now, I would like to do the demo, how to manage S-Borns in SPDX case. So today I would like to use import S-Borns about the official examples. So if you go to this page on the S-Borns 360, which you manage, so from you can find these pages, upload S-Borns. And so for explanation, I would like to use the official S-BDX example on the S-BDX website. So this includes a lot of information already. So I think it is very good for doing a demo. So after if you set the upload S-Borns, you can get this kind of result. And so if you go to the S-BDX 360, you can get the result on this GUI. Now support it S-BDX 2.2 and the S-BDX write format for managing S-Borns. So almost all data, S-BDX example are registered like this. So like snippet information or the other information related to the S-BDX. And at the same time, S-W360 support it S-BDX write. If you cannot manage all the information, you can just register S-BDX write information. Okay, and after my course speaker do the demo about the Cyclone DX. So I skipped out this time several this demo. Okay, so after that, I would like to do explain about automated dependency management. So generating S-Borns is very important. However, at the same time, you need to automate it these procedures for five reasons. First is efficiency. Automation significantly reduce the time and effort required to generate and manage S-Borns. It eliminate the manual errors and include the speed of operations. Second, accuracy. Automated tools can create a story, identify software components and their associated vulnerabilities. This leads to more accurate risk assessments. Third one is the security scalability. The number of software components include these manual S-Borns generation and management became impractical. Automation allows for security. Fourth, compliance. Automated tools can help ensure compliance with the barriers of their license and regulations. So fifth is the security. Timely identification and resolution of security vulnerability is crucial. Automation helps in early detection and migration of these vulnerabilities. So for solving these problems, I propose to combinational use as SW360 and ORT open source level tool kits. If you use both, the systems allows for the automation of the S-Borns. So what is ORT? I would like to explain. ORT is a force of policy automation and orchestration tool kits, which you can use to manage your open source software dependency. And so you can find some strategies safe and efficient models. And now, ORT has an integration feature for SW360 already. So through the open source review tool kits, you can upload ORT analyzer results to your SW360. And so use SW360 metadata as input for ORT analyzers. And starstores ORT scanner leaders in SW360 for reuse in future scans. This is the basic images for the S-Born automation systems. From your source code repositories, you can get the license or any kind of dependency result which ORT returns. So from ORT, you can find some license information or files or dependencies. And so at the same time, using the ORT integration feature, you can set the SW360. You can set the data to SW360 automatically. Then if the data already exists in SW360, you can use some curation data for reducing the time or reducing the registration times. And so of course, sometimes you need to add some information to SW360. For example, if you want to add your own system source code information to the SW360, you can add it by manually. And of course, if you have the codes and data for SW360, you can also use data to SW360. Laterally, if for protecting supply chains and if you want to deliver S-Bombs, you can select Cyclone DX or SPDX. So you made the S-Bombs for your customers with SW360. And so yeah, it's almost all, but so I think just in my idea that if we add some vulnerability system to add this, it is better to manage for S-Bombs. So in the near future, I would like to collaborate other vulnerability systems like vulnerability codes. Okay, that's all from me. Am I audible at the back? If you have any questions on this part of the session, maybe you can go now. Or if it is fine, I'll proceed with mine. Okay, I'll proceed with mine. So just introducing myself again for the people who joined late, my name is Arun. I work for Siemens Healthineers out of Bangalore, India. And I lead the software, secure development and compliance activities at Healthineers. So you have heard about what software 360 is. And to go a little bit back on the history, it was created around 2014 at Siemens. And initially Bosch and Siemens were collaborating on this tool. And later during the time, Bosch had other plans and we gave some part of the code to ORT and some part of the code to software 360. And right now the major contributors or maintenance are Siemens and Siemens Healthineers, Toshiba, Karyad. And we have a few other contributors also. So how many of you in this crowd have used or is using software 360? Okay, so I understand the household is for the curious minds. I hope you would test this application quite soon. So in the recent times, all of you are aware about the SBOM requirements that came in. And this brought in a bigger challenge at Siemens because historically our policy was to clear the source code of all the components that was being used. And at the time of implementing this tool, it was implemented for more of a waterfall model of engineering. And it was working fine. People used to end manually the components that they could identify. And in recent times, you know how fast the development world have changed. And the system was not built to scale up to its current requirements in the DevOps. So this new challenge of identifying the consumption model through package managers. And Siemens being an old company, we have a lot of old code in CC++. And a lot of the package managers were not used historically, but now the shift is happening. And we have new requirements. And it's all coming together with the new regulations also. So we had to devise a new approach where we wanted to capture the package information and the source information and how it was related to the project that we are building in health news. So just to go through the compliance workflow, this is the internal compliance workflow, which is modeled based on the open chain compliance workflow, where identification, registration, review assessment, verification and documentation are the core parts of the workflow. So today, I would be focusing on the registration and review assessment part. Because that is where the software 360 is used in conjunction with phasology. So earlier you have heard about integrating ORT into the pipeline. So in Siemens, we have a slightly different approach. I mean, we don't use ORT right now. But we are kind of liberal in terms of the SCA tools that can be used for identification or analysis of your code base. And the small part that we introduce there is right now it is an internal tool which we plan to open source. Sometimes in the future is an S-bomb enricher. So we have allowed like anybody is free to use any tools that they feel capable of analyzing their rapport and creating an S-bomb. And we have a Siemens standard bomb which is based on Cyclone DX format. So that is like 100% Cyclone DX plus some customizations for Siemens requirements. So the only requirement we have placed on the development teams is that whatever tool you use as long as your generated S-bomb adheres to the standard S-bomb format, then it can be imported into software 360 without any issues. So we do have the use case for both formats, but currently the priority is given for Cyclone DX because our standard bomb is based on Cyclone DX. But in our use case, SPDX would also be later brought in. And for this matter, we had to slightly change the current architecture or the data structure of software 360. So we introduced something called package portlet. I would talk about it in a minute. And all of these integrations of for review and assessment, we do it with Phosology. And both in Phosology, we also support both the formats for the certain output documents that we require. So internal compliance policy requirements. So we have set up these three points like source repositories should be identified for all OSS binary packages consumed. And all open source software components is to be subjected to a license clearing at file level. And packages should be automatically mapped to the corresponding release version of the component. So this is not always possible. Not all the open source communities or repositories maintain a release structure. Sometimes it is just the master branch and they only change the versions for the packages that generate out of it. But generally, if there is a version, we want to clear the source of that corresponding version. So this is the basic compliance requirements from our organization. And to meet that, we have defined these three aspects in the business context or in software 360 conduct. So what is a component? So component is the top hierarchical structure, top element in the hierarchical structure. And which is usually mapped to the source repository. And we treat the VCS URL version control system URL as the unique identifier for a component. So and then there is a reason for we using that because two components can have the same name. And then we want to identify if two components have a same name. The next check that we do is who is a manufacturer or who is the vendor. So based on that, a new component would be created. And even if it is the same manufacturer and same component, there could be a difference in terms of licenses. For example, OpenSSL, they change licenses from OpenSSL to Apache. So in that case, we would have one component with the OpenSSL license until version 1.xr and then another new component with the changed license information. So that is the top level of the hierarchy. Coming next is, as I told earlier, where there is a release properly maintained, this would be the component release. So we create a component and if there is a release available, we nest it under that component release. So this was the current structure or until now. So in the new model, we have introduced the package level which is always linked to a component release. So this is mostly used when there is a non-modified consumption model directly from the package repositories. So as an example here, I have given Angular. So you can see the GitHub repo Angular as the component and its particular version, 16.2.3 as a package. And when it comes to the NPM repository, you see Angular slash core where they have pointed to the repository Angular. So this would be the structure in how software 360, it would be modeled in the three hierarchical structure. So I mean, this is just a pictorial representation of what I just explained. It's just how a component and a component release is mapped. And this is a top-down approach where a component is created first, then a release is created. And the new model, we have the releases, the component, and the packages coming in. So the difference is the creation is kind of bottoms up. So first, a package is created during the import of a Cyclone DX S-bomb based on the unique package URL. And then it automatically figures out, based on the VCS URL information, the component and the release. So once a component is created, the next time it gets reused. So just to make the understanding easy, it's an example of Nuget and how it appears in the Nuget repository, where it refers to a source repository which is the GitHub and what developers use the Nuget package. And we need to clear the source repository for the security and license compliance requirements. So the major savings in terms of compliance effort here is, in the Alden model, we were forced to clear around 31 components and create 31 clearing reports. So in the new model, when we perform this mapping, the effort reduces to just one. So all the binaries which are referring to the same repository, we can go ahead with just one clearing report of that repository. And according to your requirements, you could implement certain methodologies where you can continuously track the development or the changes in the repository and then continue reusing the report. So there is a significant savings of effort for compliance activities because it's very rare that licenses changes between minor releases. So this is the package portlet. You might not have seen the third portlet there in the earlier demo. This is how it displays and it's a complete standalone one where you can search based on the package manager type, et cetera, and the name of the package and the release which it is linked to based on the VCS URL and the licenses. So all these information are collected from the SBOM that is imported. I will show a demo right now on this. So this is where we can import an SBOM. So we select from the project. So when you're doing it first time, you can do it from the project. You can import an SBOM, just drag and drop the file. And once it is successful, you will be able to see a short status here with the name of the project that created, what were the releases created, packages created, what is reused, and also the time taken. And there's also some error reports that would come. I will just show it in the demo here. So once it is created from a project view, this is how you could see it. Like the linked packages is what you can say as the SBOM view as such. And on the top, license clearing would be based on the linked releases. So it's like we kind of created two views for two audiences in the company. So this view is for the developers. So they get a complete understanding, okay, this is what I use and this is what I see in my project. And once you go to the license clearing step, that is what the compliance team looks at. They know, okay, we just need to clear these components and the project goes into the next stage. So the same view. So the component, the first is the component, the second is the release. And within the release, also you would see what all packages are linked to that particular release. So this kind of happens automatically and there is an option possible for you to correct it manually if required. And in the package details page, currently you don't see the part where you can capture vulnerability but the newer version has the ability to point your vulnerability assessment tool integrated to Software 360 which would then display the vulnerability per package if something is identified. And in future, Software 360's idea is to incorporate open source vulnerability databases. So we are looking at vulnerable code and other options. So by default, there would be an open source based vulnerability monitoring tool integrated in Software 360. So right now the module, we use the Siemens internal tools to be integrated but the idea is to get the tracking right from the point of creation. So I mean, this you can refer in the slides later. The slides are uploaded in the website so you can see if you want more understanding on this. So I'll just go ahead with the demo. So here, I'm going to show you import of an SBOM. It's always a high risk when I try to do a demo live in an event. But yeah, I mean, it's worth the effort. I'm too optimistic at times. So this is just a test instance. So don't assume the performance by seeing this demo. It's just for the demo purpose. So for the Cyclone DX, I kind of just drag and drop this. Upload an import. Hopefully it should work. Yes, upload is successful. Importing SBOM is in progress. It's like waiting for the launch of SpaceX. We don't know what is going to happen. Anyway, I'll come back to it because it will show the time of the input. So I can mean them. I will show a sample which I have already created. So here, if you see, in the project view, in the attachments, automatically the imported SBOM would be attached. And the status of the import would also be shown here. So it's a JSON file. So if you are integrating it in your CI-CD pipeline, your developers can access these documents via REST API also. So right now what I'm showing is how to do it from the UI part. For all of these features, REST API is available today. So you can directly integrate the creation, updation, everything via CI-CD. So another important aspect is once you create this project and then there is an import SBOM from within the project. So this is where you can update the already created SBOM because there is a chance where new versions of the SBOM might happen at different times. So you can re-import it here. Okay, so luckily it got created. So 741 releases were created from total 1326 packages and it took 42 seconds for doing it from the UI. And it gives a clear indication about what information it doesn't contain because all the packages were successfully created, but the packages that did not have a VCS information is listed here. So this can be again sent for enriching because generally we tend to, the plan is to enrich it prior to importing so that we don't get this message, but for the community version, it is available and you can enrich and re-import it. So if you look at this project, but I'm, yeah, test project for NPM. Okay, so this is our project. Yes, so you get a summary of the basic information and in the administration panel you can actually configure your license header file. So this would be used for generating the readme document or notice files and license clearing. So this is where the input for the clearing team goes in where we subject the source repositories for the license clearing. And as you saw earlier, there was VCS information missing and hence no component were linked. We could do this later also as an update. So yeah, so now you have seen the first bug in the demo. Somehow the package information is not appearing, but you saw that in one. So this was my backup information here. So this is how it works. So granular view of binary packages which can be linked to their repositories and hence enabling both vulnerability monitoring and license compliance in a much more seamless way. So that's all from the demo side. And yeah, so the idea is to transform the perception that security and supply chain compliance, how it appears to developers is mostly this way. I mean that's the developer on the wall. And we want to change this perception where supply chain compliance would look like this for all developers. We want to make developers so comfortable handling these knives. So yeah, I have put the link to Phosology and Software 360. You can scan and join and if you like it, give it a star. Yes, we are open for questions. Since I did not find a user for Software 360, that's could be a reason that I don't have any, we're not having any questions. Yes, first question there. I saw you import the Cyclone DX into the SW 360. Does the software 360 support other format? Yes, yes. The one, the demo that Kokihama showed a few minutes earlier was the SPD X1. Yes, how about if a supplier deliver you Excel files? We do have offline scripts that could do these inputs. We utilize the rest end points to do that, but natively we don't have the Excel import feature configured yet. But you could do it with a script because we all have rest end points for all of these things. I saw this Software 360 has integrated with several scanning tool. For example, ORT, for example, the falseology. I don't know if there are any use cases with the commercial scanning tool as well. The possibilities are there, of course, yes, because we have not tested it with anything because if there is a common format agreed between the commercial vendor where you can utilize the rest end points, it should be possible. But right now we have not providing any support for any proprietary vendor by default. But based on usage, if you need it, I think it is possible to do it. Thank you. Thank you. Okay, I guess that's the end of our presentation and the question round. Thank you for your time and your patience in listening. Thank you.