 Hello everyone, so hope I'm audible So our today's topic is there's one way that of consuming and ditching managing inbound It's bombed for automated compliance continuous compliance. Okay, so me and up on my colleague Arun Will be presenting this topic. So about our ourselves Myself on from ghost from Siemens technology India working as a technology professional. I also call it the SW 360 project Yeah, I'm Arun. I am kind of leading the compliance activities at Siemens health in years So responsible for the tools and compliance processes at health near so I Lead a team of Few of the compliance experts. We do the filer license clearing and all the other related activities at Siemens health in years So today I would be showing about a new feature that we have brought in software 360 and possibly a live demo of that feature So what's the actual challenge that we face? phase in a company when we have a compliance workflow So we need to identify the ways as component. We need to register the component review Assessment then verification and then documentation. So with all this module probably start with the build automation on the pipeline where you would like to generate Using some SCA tool you would like to generate is bomb and then From that is bomb try to register your component of the project In a tool for the registration purpose But during this process you need to enrich this bomb or enhance this bomb because it's bomb Maybe missing some information or maybe it has a lot of information in it So you need to enrich this bomb and then put it into a for registering your project for here is the tool established 360 that we are focusing on and Yeah, so then you can exchange the information with this W3 16 different s-bomb using different s-bomb importer like cyclone DX SB DX Now once you have the component then also you need to review and assessment review and assessment. So for review and assessment Facilogy is the tool that will be looking into so user in Siemens. We do a file label clearing So for that for the logic supports with license copyright Here also we have the exchanging information using a speedy exam copy day Cyclone DX s bomb Now engineering team mostly look into verification and documentation of the product so All these phases that we see that we need to exchange some form of is bomb. We need to end these days bomb We need to exchange messages over using is bomb So for today's presentation, we'll be mostly focusing on the registration and review and assessment part. That's more mostly With the two tools SW 360 and sociology and we'll try to see how this Tools can be used for some of the automations We are trying it out So about the introduction of the project is W360 SW 360 is a Eclipse Foundation project It became open source in 2018 SW 360 is basically a open source component hub where you can keep track on your open source libraries So the tech stack of SW 360 is mostly using life report We are in a development phase for replacing the life report all with SW 360 front-end which is real react base UI that we are doing and It's on active development and the back end says we use Java for message exchange strip spring boot for rest and rest and couch to be as a database you can interact using in SW 360 using the way we interface or Over the rest API so what's this project is all about as I Said that SW 360 is a third-party component catalog assign third-party components to product and project here the alphabets You can say component with releases. So basically it's the release Or the library is that or dependencies that you found inside your project Project and product almost similar terms that we use in SW 360. So these are all Dependencies that related to your product or project and yeah with The benefits that we get here. You can link you can reuse this information of the component you can We need to find also the product documentation also Support the clearing infrastructure for these components that we have in SW 360 So let's go through the use cases that we have What why we need a tool like SW 360. So it's the 360 is a component inventory database It's all about component management. So here at the component level You can also collect licensing information and store it into SW 360 SW 360 is You can mark the you can take open source component but along with open source You can also take internal component commercial and few years You can choose different type As the name goes it's software 360 software 360 should give you a 360 degree view of your product or project so along with License information for the waste is component. We also support ECC vulnerability Some statistics code analysis and a dashboard as well. So to To monitor your component lease and project and the usage is one management is The main topic for today and SW 360 is designed to manage this bomb where you can Find the relations between the project and the components It also captures means whatever the component and project you are using in your organization So When you have projected component It's always need you have to you need some reporting form a reporting structure to extract the report whatever Analysis you are doing in the tool. So here we have support for SW in SW 360 We have SBDX and Cyclone DX to exchange information For To get information for the license copyright acknowledgement. You can also track the project Read me what is that includes your license information copyright information and other findings So with this main use cases We try to build what kind of data model we can have for a stability 360 where we can minimize the duplication Duplication of component entries. We can also have separate separate vendor and version From the component catalog. So for the component name so that we can track them more appropriately with this The structure that we have now data model we have now the release is the main entity into SW 360 So release can be connected to projects. It can be multiple releases of In a in a group it forms a component and vendor can be Linked to releases. So there is another module that's package portlet. It's new introduced into SW 360 Arun is going to talk about it more detail We also need to support external systems where you can Configure CP's in a simple 360 and track your vulnerabilities So to support all these we need a clear data model to enhance the search and the filtering functionality into a tool So how all this works? So first you need to create a component That's the basic container where you can keep your releases or track your releases releases basically the version of that component and Then you add Packages to the release so Earlier we don't have the package portlet So it's if you if you want to use multiple packages then it's you have to maintain it in a release structure But with the package portlet, it will be easier So now once you have the components you can also create the project entry so project to track your project and Usage and then create a bill of material out of the project and Link those releases or the dependencies that you have in your software to the project Now once you link the releases to your project, you also need to clear those dependencies Okay, yeah, so it's all good that you have everything together now How do you scan those? How do you how do you go for the clearing? So the solution that We use in automation with SW 360 is for sociology So a brief introduction of for psychology For so what is a Linux foundation project? So what is an open sense project under the GPL a GPL 2.0 license from 2008 and It's become a Linux foundation project in 2015. It's a placeholder for multiple oasis license oasis scanner It's it's gives you the wave interface as well as the CLI Rest in point to communicate with for sociology You can scan it has multiple scan agents that can scan your copyright licenses ECC Keywords and can be used for multiple other purpose because it use mostly rex base scanner for the copyright and keywords So it's a multi user multi tenant way be why for you organizing clearing jobs So there are multiple organizations those were using Physiology they put their logo here. So yeah, if you are using you are interested You can also send us your logo to put it here. So I'll just Go through the automation workload that we have with physiology currently with SW 360 So SW 360 Though the entity here I've given as a human but you can be I see a tool that automatically can push data to SW 360 Then it's W360 uploads the dependency or the releases that you have in your project project to physiology server now for so what he runs his scanners to More to finding license copyright and other details from your library Then it goes for a review. So infosology review is only mostly manual so that you can There is an automation around 10 to 15 percent that works But not more than that. So yeah, it's mostly manual once you have the finding then Clearing user go through the findings clear the package and then create a report and upload it back to SW 360 So to bring more automation to this space. We are also working With something which we call it license compatibility agent that will help you to Check the license compatibility compatibility infosology What's the license compatibility agent check the compatibility of the licenses then decided agent helps you to identify Those license those are compatible and then clearing result is automatically generated and uploaded to SW 360 So here the benefit that you will get you don't need to Manually do things most of the things but everything cannot be automated So most of the things will be auto can be or can be identified automatically, but some portion that Requires identification. You will be able able to clearly identify that from SW 360 So with that I'll hand over to Arun for Yeah, I will start with You know the core requirement why we need to process s-bombs in software 360 and what is all about the new approach so to explain that I would want to define the you know Certain terminologies like we you have been hearing it component component release package So this is strictly based on our business context and it is not an industry standard term Package would mean different in different context, but in the Siemens world in our business context This is how we define these three elements. So in software 360 component would be the topmost element which is mostly mapped to a Source code repository and the component release would be mapped to the corresponding releases or you know, how they have Defined to their release management via tags. So Those are the component release and those are the artifacts which are linked to a particular project So the usage happens at that level So the new scenario comes in where with all of these automation coming in and the s-bomb requirement and the majority use case of Compliance comes from the way Open source is consumed. So most of us know that we consume open source in the You know binary non-modified form through different package managers So that brings in a challenge and a conflict with our existing clearing process which demands Source file level clearing. So there is a disparity between What the developers see and use and what the compliance team wants to clear So this was a challenge in the existing or the earlier versions of software 360 Where we were forced to register a package say for example a binary package also as a component So then that becomes a lot of redundant information and it led us into a lot of clearing volume Additional clearing volume. So in order to solve that we have come up with the package Portlet, which is in addition to components in software 360 So this was if we take an example of angular like what I have highlighted here is the angular Organization and the angular are positive. So in our terminology angular would be the component and it's release management based this would be the release and the same form in the npm registry it would appear as a A package where it establishes a relationship with the repository So this is how we find the relationship between the binary package and its source Component so in the current data model as I explained we have to link component releases at project level But invisibly there is also a corresponding component, you know linked to each releases So in the new data model what would differ is apart from the component releases and component We have this new additions of packages So to explain a little more detail into the component relationship to take an example say we go for a nugget component Microsoft application insights. So there I think from 2019 new gets Started to include this information source repository as a mandatory field while releasing packages So since then it is mandatory to mention the GitHub repository or any source repository Where you are maintaining the code So this means this is the view the binary view is what the developers use and they download the NuPKG package and that is how they ingest into the code But the compliance team would need the source code to review at a file level So we wanted to reduce our workload and also speed up the development process say for example in this use case Apple app inside SDK contains 31 packages and all those 31 packages are referring to a single source repository So in the old model we were required to create 31 clearing requests Against one clearing request and in in source report So even though we knew it there were a lot of workarounds done by teams to manage this offline But it all led into additional manual tasks and it become became cumbersome when you know The number of packages started getting increasing. So it was difficult to manage and Hence we launched the package portal it so I will also explain it in the demo a little bit But let's go through the screenshots right now. So here In the database you will get a collection of all the packages ingested during various times for during various Projects and you can differentiate it based on the package manager and search You know according to your needs so even though you have we have manual capabilities here We prefer that the creation of packages and management always happens via automation And we have enabled it through the process of Cyclone DX importer which I would show in a minute So from the UI there are two times like where we can two use cases where we want to import And sbom into a project so at a project level we can import an sbom when we do this for a first time And it is just basic drag and drop any JSON or XML file And it would import the entire sbom and model the project in its granular form And you know it gives us also a feedback in terms of what is missing and what is available For example the minimum requirement to create a package is the presence of a package URL And to link a component released to that corresponding package we need a vcs URL present in it So that is where the sbom enrichment Anupam talked about earlier comes into picture Because most of the tools we use a lot of Cyclone DX tools for the ACA part And depending on the technology the results vary some might give the vcs URL some might not So we have to implement certain steps to enrich the bomb so that the information is collected at the right point And we can model the project at the first go itself So the more quality that you bring in the sbom or the more enriched sbom that you bring in to import More perfect your project modeling would be So from a project point of view we have this new tab where this linked packages are available Where you would see the vendor package name and also the release link to it if a vcs is present And if a vcs is not available it would not restrict the creation of a package But it would create it and would say that okay it's an orphan package So we can still use it for maybe security monitoring if your workflow you want to define your workflow and limit it to that level But in our use case we have to go one step ahead and do the source level clearing So hence we want a release to be linked to a package And the license information in this view is also coming from the Cyclone DX sbom And based on the package manager type it would display in the UI So similar way like the existence of a package is independent of a project So as I told like it would be there and in your project you would only have the exact packages that are used for your particular project Say suppose if application insights currently shows two linked packages In one of your project you might not use both of them but only just one But then your modeling would reflect exactly that way Even though at the release level you will have the complete collection But at the project level you will have only the required one which has been identified by the SCA tool and is part of the sbom that you imported And if you go one step ahead like this is the package details like we are not collecting or there is no attachment at this level We don't intend to attach any files as we do for releases at this level But just a basic summary change look and in future we would also extend to track vulnerabilities here So apart from the basic information like the package URL and you see the version control system So because of the presence of the version control system we identify the linked release based on that And we can consider this kind of a good quality sbom where this information is available and this goes very smoothly I mean this is a screenshot from a typical sbom and how we capture certain details and map it to software 360 So the external references are mostly for Nuget components we do get it in the first shot But certain other technologies we might not and we have to really put some glue code where we can find that information So I think it is time for the demo I will just, I mean I have just set this up for this demo purpose so there is no data in it So from the project view I am going to import an sbom So we also have the facility to import spdx but that is not in the current scope But software 360 at the community level does have that functionality and it supports it So here I am going to use, first I will use XML based sbom And I do the upload, usually it doesn't take this much time but in every demo this happens Maybe I can blame on the network speed but yeah And the funny part is like we do capture the time for import also in the results so that is embarrassing right now I will wait for few more seconds and then see if I can do another one So this what I am showing is right through the UI but we also have the entire package portlet in the REST API supported So you can actually configure it in your pipeline to do this This is bad So it seems that it is available here, I don't know why it is not showing the status or it is hanging So it has created the project and you can see the corresponding components that are created And if we check the project we can see the linked So the demo is kind of bombing it a different level but yeah This is how it would configure Maybe I am not going to, yeah So it took this much of time and there is like around 1300 packages and existing packages were reused somewhere created And this is the information that it gives saying that out of this 1300 382 did not have VCS information So this is kind of an information to the developer that says that okay you need to enhance or enrich your SBOM So this information even is available like at the project level once this input is done It should be available at the attachment folder And I will do one more with a different one which I am like Okay so it is like NPMN should be fast Don't fail me here This is like it should happen in one or two seconds ideally So meanwhile this is the advantage that we get by reduction of what I meant is the clearing effort So for example all of these components of different versions are grouped to a certain version of a component So the current it is 352 entries and the releases would be correspondingly small to create it I think it is just speed and it works speed I am not sure Yeah luckily it, yes So after the input the SBOM is already automatically attached into the project And also the status of the input is again attached as a JSON file which we can view at a later point So in this case there were no reuse so all our new packages and I think most of it doesn't contain VCS information So all of the linked packages are kind of you know requires enrichment to identify it But at this point like the advantage is that you have the granular view available like what your developer is using So the developer can come to this software 360 and see that yes I am using this thing and they can monitor it against vulnerability statuses In whatever tool you have connected to software 360 And the license clearing at this page we would have the linked releases which would be much smaller number compared to the you know 1,300 packages So once it is done as per our workflow like we can you know just create a clearing request to the clearing office and that's how the workflow goes And it's a it's tracked and then all of these components would change the status to a green state where we say that okay it's all approved And then if there are obligations based on the licenses found that would appear here in the obligations tab where the project can review these obligations and perform the remediation accordingly And when it comes to vulnerability tracking status if you have enabled vulnerability monitoring so currently we are we have linked an internal tool from Siemens to do this vulnerability So it does a nightly sync to that vulnerability application and gets all the information back to this project level So it's a you know real time tracking happening and daily sync based on this so the project can take decisions based on the vulnerabilities that are reported So that's all from the demo for now So our whole intention of coming up with these features is to you know we want to really help the developers to you know move from this position Because in terms of compliance everybody feels every engineer feels like this And we want to help them to get from this position to somewhere here where they are so comfortable I mean that is our goal So I think we are at the end of our presentation and these are our links to our projects Visit the project at GitHub consider giving it a star and if you have any queries please write to our email list or you know contact us And we do have a community call for software 360 every Wednesday at around I think 10 a.m. European time Yeah, so you are welcome to join and raise your concerns or any new feature request and you know welcome to contribute If you have any questions So have you discovered any severe license contradictions or obligations that result of this and also who would it be within Siemens that acts on the information Is it the engineering team or is it the legal department the you know like a I don't know if you have an Ospo or a hotel's program office Okay, so the question is like who would act on the findings Yeah, and if you have found any major license conflicts Yes, so as Anupam mentioned earlier we use phosology and we have the facility to capture the legal obligations in phosology So we get that feed from the legal from time to time when they update the license obligation database And that is embedded in phosology so the clearing report that we generate out of phosology would contain that legal obligations which are provided to us by the legal And that would appear in the obligations tab I showed in the UI so the project and for each business unit at Siemens we have a You know third party software manager who's responsible for the coordination between the project and he act as kind of a license between the project and the compliance team So then they sit together discuss the next steps and only if some cases comes out beyond the existing recommended obligations or terms then a legal would be involved So most of the time when a new license comes up which is not there in the database we get help from legal to do an interpretation or if it is a very business specific case we do get that I mean you have a question, yeah Okay thanks I wonder why you're actually looking into package or from into the sources of packages provided by package manager so I totally get if you have your own sources But why are you scanning the sources of public packages where usually the package manager has all the license information present Partially right, yes for certain package managers when they provide the package we do have a complete license but certain package managers trip off certain comments and license header files when they make the package So the legal at Siemens says or our procedure demands that we use a file level source based clearing, yes I mean sometimes we also feel that it's a overkill but process legal so we cannot say no on that To follow up on that it's fairly common for packages to not have correct or complete license information I've seen packages where the license field is actually a user guide or a pretty picture which is not helpful But a question, you said large scale automated scanning and you're showing a manual upload so where is the large scale automated clearing going on? Sorry? Where is the large scale automated clearing going on? You showed manual upload and manual request of clearing whereas the automation Yeah so as I explained once the clearing request is available from a project we have an internal automation which we run a pipeline and we send it to the phasology tool So the source code is uploaded automatically to phasology and all the agents which are configured are run automatically And there are two reports or reports that can be generated at two stages Once we can take the raw report like what the scanner has found and the other one is where an expert has concluded those licenses So if it is a big project the project also get the opportunity to start looking into the raw findings like how the compliance team is seeing it Like they can see the exact license and it will show the exact files where these licenses applied Say for example the main license would be MIT, the other licenses they might find a GPL 2.0 license But they can investigate further thing and they find it to be in a docs folder so that means it is not going to affect in any way So similarly, yeah Yeah I just have the question so I guess you will not share the license compatibility matrix that you use at Siemens I guess so because we would not share it But you potentially know we also have this evaluator in the OSS review toolkit where we had at least a common rule engine more or less Do we already think about or could we start then collaborating on this because I guess we could reuse it in phosology the same way So kind of modular approach I would really appreciate that because then we could say okay we take the same license specification set The policy set that we use in order we could also use it in here in your approach I would really appreciate that Absolutely we can collaborate here We can connect after the talk and I think we had tried integrating ORT you know some few years back and then I think it was the time of antenna right It works, ORT with ORT establishes integration works so if you have a ORT analysis report then you can upload to establish for 60 to create the dependency free and the project Yeah and specific to the license policy like there is also an upcoming feature that we have it's in the concept stage like a license policy manager which we would add to software 360 So based on the results it would make the make it easy for the engineering team to make decisions like we would do all the intelligent work like if it is a permissive license then there is no further action required And we would just group those source packages which contain the problematic licenses and say you have 100 components so 95 components are fine Please look into these five components and then they can focus on how it is being used whether there is a modification or it is just a binary non-modified usage and they can fulfill the obligations in that way So this is also in the works and then we should also talk about it Yes Yeah we have it Thank you So you showed that you have packages that come from the same repository but you separate them on the package level so do you then do individual clearance for all these packages and differ in their concluded license or do you do the clearance on the repository behind it And in most cases then maybe overreport on these packages if you take the repository license for the underlying packages so I know you get a lot of examples where you have a repository that is for example under an Apache license But there is I don't know 400 packages that come from that repository and for many of them maybe it's an MIT license would be the concluded license correctly so do you differentiate in that? Yeah we do at Siemens at the package level we do not I mean right now we are forced to do the clearing at package level which has you know taken our workload a lot So this package modeling would enable us to reduce that with this grouping and still provide this granular view to both the teams like for the engineers and all the compliance team And why we do it at the source repository level is because most of the packages the concluded license is taken as from the main license part so the other included files are not often seen so we just check for if there is any incompatible So that is where the incompatibility agent would also work which says that okay the main license is Apache and you have few files under GPL too and that is when the engineering would decide like if they are modifying the package or are they using the package in the source form If they are creating the binary then they need to remove it so those decisions would be based on the source file source level clearing report So that is why we do at the each release level and for package we go with the main license which is already most of the time available from the SEA tool as a result Okay thank you Any more questions? Questions? Okay so then thanks for attending Thank you