[00:00.000 --> 00:21.680] Thank you very much. [00:21.680 --> 00:25.260] Welcome to our talk on Standard Bomb. [00:25.260 --> 00:30.920] We are here to share with you some of our experiences that we've had introducing a common [00:30.920 --> 00:35.000] S-bomb format at a large company. [00:35.000 --> 00:41.760] And we also hope to get into a discussion with you about your experiences and maybe [00:41.760 --> 00:47.800] things that you noticed that we've missed or that we should or could do better. [00:47.800 --> 00:53.200] So all three of us, I must say, the thing is called Standard Bomb. [00:53.200 --> 00:56.720] It's just our name for Cyclone DX format. [00:56.720 --> 00:58.160] So we are not reinventing the wheel. [00:58.160 --> 01:01.160] It's not like we've invented a format or something. [01:01.160 --> 01:03.720] And we're also not selling anything. [01:03.720 --> 01:08.040] It's just sharing experience and talking to you. [01:08.040 --> 01:13.000] All three of us are from Siemens, so I feel I need to say a few words about the company. [01:13.000 --> 01:17.160] Siemens is a technology company, so you can buy small things like thermostat for your [01:17.160 --> 01:23.640] smart building or if you need a whole train or a power plant. [01:23.640 --> 01:25.240] So I mean a power plant is nice. [01:25.240 --> 01:31.240] And also things in between like medical devices, magnetic resonance, tomography systems, or [01:31.240 --> 01:35.840] if you're equipping your factory, then you can buy a factory equipment. [01:35.840 --> 01:38.560] So Siemens has also been around for some time. [01:38.560 --> 01:45.240] Just recently we've celebrated the 175th birthday of the company, so it's changed a couple [01:45.240 --> 01:47.320] of times over the years. [01:47.320 --> 01:51.440] And traditionally, of course, there has always been a focus on hardware. [01:51.440 --> 01:57.520] But in recent, well, decades, I could say, software has become increasingly important. [01:57.520 --> 02:03.960] So now of the 50k R&D employees, we have a sizable portion of software developers. [02:03.960 --> 02:08.320] I couldn't find out exactly what the portion is, but I'm quite certain it's in the five [02:08.320 --> 02:11.440] digits and growing, certainly. [02:11.440 --> 02:17.800] So and since there's no like in a company like that, there's no one technology stack, [02:17.800 --> 02:22.080] so we're basically using everything, I should say. [02:22.080 --> 02:28.640] And that growing importance of software, of course, leads us directly to software builds [02:28.640 --> 02:29.640] of material. [02:29.640 --> 02:38.720] You know, you're all aware of the legislation that's upcoming mostly in the form of executive [02:38.720 --> 02:41.960] order and CRA and so on. [02:41.960 --> 02:45.840] So S-bombs are getting more and more important. [02:45.840 --> 02:50.800] And I don't want to explain S-bombs, that's just, you know, you all know that stuff on [02:50.800 --> 02:51.800] the slide. [02:51.800 --> 02:56.280] I just want to stress one thing, and that's generating an S-bomb for a software product [02:56.280 --> 02:58.720] is not something that can be done manually. [02:58.720 --> 03:01.800] It must be the result of an automated process, okay? [03:01.800 --> 03:08.280] So there's just no way to reliably do that manually. [03:08.280 --> 03:14.200] And one of the things that we realized is that an S-bomb is always created with a particular [03:14.200 --> 03:16.160] use case in mind. [03:16.160 --> 03:19.680] Even if you're not thinking of a use case while you're doing it, then you're still [03:19.680 --> 03:21.920] implementing whatever's in your head at that point. [03:21.920 --> 03:28.800] So it's always, the concrete S-bomb document is always intended for a particular use case. [03:28.800 --> 03:33.520] Just to give some examples that we are dealing with, one would be license compliance. [03:33.520 --> 03:36.880] So we want to, you know, make sure that we follow all the obligations from open source [03:36.880 --> 03:39.000] software licenses. [03:39.000 --> 03:43.400] That's very important because OSS software is used extensively at Siemens. [03:43.400 --> 03:45.600] We use many components, and we also publish them. [03:45.600 --> 03:50.720] So if you go to github.com slash Siemens, then you will find some of them. [03:50.720 --> 03:54.440] And if anyone of you does that right now, then be sure to also click on the badges on top [03:54.440 --> 03:55.440] of the page. [03:55.440 --> 03:59.160] They link to other places on GitHub that have Siemens open source software. [03:59.160 --> 04:02.240] It's not all consolidated into one. [04:02.240 --> 04:09.280] Anyway, license compliance also requires us to have source code available, because that [04:09.280 --> 04:10.280] must be scanned. [04:10.280 --> 04:14.920] Individual source files might be licensed under a different license than the main project [04:14.920 --> 04:16.720] and so on. [04:16.720 --> 04:19.800] And that's a particular requirement of that use case. [04:19.800 --> 04:24.600] So the S-bomb will look different compared to, for instance, the security vulnerability [04:24.600 --> 04:26.080] monitoring use case. [04:26.080 --> 04:27.440] Also very common. [04:27.440 --> 04:28.640] Source code is not so important. [04:28.640 --> 04:33.000] It's important for finding the vulnerabilities, but not so much for monitoring them. [04:33.000 --> 04:36.000] But you need different metadata, such as CPE information. [04:36.000 --> 04:41.120] CPEs are used to look up the vulnerability in the corresponding databases, so that's [04:41.120 --> 04:43.240] critical. [04:43.240 --> 04:48.640] And also you might want to include build tools, test frameworks, and so on, since they might [04:48.640 --> 04:52.880] also be vulnerable. [04:52.880 --> 04:55.280] Both of those use cases are internal use cases. [04:55.280 --> 05:01.080] So we generate the S-bomb for us, use it with our systems and processes, but we don't share [05:01.080 --> 05:02.840] it outside of the company. [05:02.840 --> 05:09.320] In the third case, regulatory, that would be, again, another use case where we are required [05:09.320 --> 05:14.200] sometimes due to the new legislation to publish the S-bomb. [05:14.200 --> 05:19.280] And then, of course, we must be sure to include certain fields in that S-bomb about every [05:19.280 --> 05:24.280] component that are required by that regulation. [05:24.280 --> 05:30.360] And we will not normally put much more into the S-bomb than we are strictly required to [05:30.360 --> 05:35.840] do, because that's for regulatory purposes, and we don't want to open up an attack surface [05:35.840 --> 05:42.320] for just people who want to bitch about some information being wrong or something. [05:42.320 --> 05:46.560] So that's just the realistic thing that's going to happen. [05:46.560 --> 05:51.320] And you'll see later that this is relevant, those S-bombs being created for different [05:51.320 --> 05:53.200] use cases. [05:53.200 --> 05:57.560] Because when you're creating an S-bomb for your concrete product, you're actually solving [05:57.560 --> 05:59.160] something of a puzzle. [05:59.160 --> 06:04.400] So you have all kinds of pieces that must fit together to get the final S-bomb. [06:04.400 --> 06:11.680] Imagine you're shipping something simple like a front-end container with an Angular application [06:11.680 --> 06:12.680] in it. [06:12.680 --> 06:16.600] So maybe you have an NPM to ask for dependencies. [06:16.600 --> 06:21.000] That's the easy part, because it's under your control. [06:21.000 --> 06:27.400] But then you also have, let's say, an nginx in the container, which has an S-bomb or [06:27.400 --> 06:29.440] consists of some components. [06:29.440 --> 06:34.240] And it's in, let's say, a Debian Linux. [06:34.240 --> 06:41.560] And that has, I don't know, 100 or so open source components as well. [06:41.560 --> 06:46.280] And well, sometimes you're lucky, and you work with partners or a different, in a company [06:46.280 --> 06:50.080] like Siemens, you have all kinds of different business units that produce components and [06:50.080 --> 06:51.640] give you S-bombs. [06:51.640 --> 06:56.240] Those S-bombs might have all the data that you need, or they might not. [06:56.240 --> 07:02.120] Imagine that people only gave you the S-bomb because they're required to by the regulators, [07:02.120 --> 07:04.440] the third use case. [07:04.440 --> 07:06.880] Then it would probably not be enough. [07:06.880 --> 07:12.640] For instance, license information is something that's not even required by the NTIA for a [07:12.640 --> 07:13.640] public S-bomb. [07:13.640 --> 07:15.640] They just want to know what component is it. [07:15.640 --> 07:18.440] They don't want to know much metadata. [07:18.440 --> 07:21.720] So that's something you need to have to enrich then. [07:21.720 --> 07:28.760] You will probably need to have backend systems to enrich your S-bombs and arrive at the final [07:28.760 --> 07:31.760] S-bomb while you're solving this puzzle. [07:31.760 --> 07:37.280] So now I've talked a lot about the S-bombs in general, and let's look at some more detail [07:37.280 --> 07:38.760] with Alex. [07:38.760 --> 07:41.160] Yeah, thank you. [07:41.160 --> 07:46.080] So as we already mentioned, one goal that we have is to take you through the process [07:46.080 --> 07:51.200] of how we adopted a common S-bomb format within the company and what some of the challenges [07:51.200 --> 07:55.320] and major pain points were that we detected as part of that. [07:55.320 --> 08:00.040] So of course, at first, you look at the requirements that you actually have, and usually to do that, [08:00.040 --> 08:02.400] you look at the process and the people involved. [08:02.400 --> 08:05.600] That's a good idea, even when you're trying to solve a technical problem. [08:05.600 --> 08:09.720] So what we considered initially early on, I mean, you've seen our product portfolio. [08:09.720 --> 08:14.880] We do everything from hardware to software as a service, so every team at Siemens is [08:14.880 --> 08:19.000] different, which for us immediately meant that there is probably no silver bullet that [08:19.000 --> 08:20.480] works for all of them. [08:20.480 --> 08:25.280] So there wasn't going to be a single automation approach that we could push onto people. [08:25.280 --> 08:28.040] Instead, we needed to provide an ecosystem. [08:28.040 --> 08:30.240] So that was realization number two, right? [08:30.240 --> 08:35.120] So we need a common set of tools, but not everybody is going to use every tool. [08:35.120 --> 08:42.080] But the goal here was to simplify the actual S-bomb generation and allow people to feed [08:42.080 --> 08:47.040] that data because that's the background that we come from into our OSS compliance and commercial [08:47.040 --> 08:51.720] license compliance tooling, and to enable developers to actually use that as part of [08:51.720 --> 08:53.240] their builds. [08:53.240 --> 08:57.480] And from the get-go, we were pretty clear on that either becoming in a source within [08:57.480 --> 09:00.080] the company or potentially also open source. [09:00.080 --> 09:02.480] We will comment on that a bit later. [09:02.480 --> 09:06.320] And then of course, you can't always optimize for the edge case. [09:06.320 --> 09:10.880] So there will be teams within Siemens that use tools that nobody else apart from them [09:10.880 --> 09:11.960] uses. [09:11.960 --> 09:18.880] But even then, we wanted to enable them to also use the format by at least having a set [09:18.880 --> 09:20.880] of libraries that they could include. [09:20.880 --> 09:25.320] So currently, we offer these for Java, Python, and.NET. [09:25.320 --> 09:29.680] And that definitely covers a lot of the different teams that we have. [09:29.680 --> 09:34.360] And similarly, that is provided as in a source today. [09:34.360 --> 09:35.720] Yeah. [09:35.720 --> 09:40.840] So one valid question that you can, of course, ask is why do we care so much about our S-bomb [09:40.840 --> 09:45.040] in the first place, and why do we care about them being accurate? [09:45.040 --> 09:49.960] There's more reasons than the two I'm going to talk about, but generally, these are the [09:49.960 --> 09:50.960] main two for us. [09:50.960 --> 09:52.680] So one is security, right? [09:52.680 --> 09:56.640] So it's not that long ago, actually less than one and a half years, that lock for a [09:56.640 --> 09:57.640] shell hit. [09:57.640 --> 10:04.040] Or if you think back to SolarWinds, it's important to actually know the products that you consume, [10:04.040 --> 10:06.920] so the dependencies that your own products have. [10:06.920 --> 10:09.440] And for that purpose, an S-bomb is exactly what you need, right? [10:09.440 --> 10:16.040] So we want to be able to identify vulnerable components as quickly as possible. [10:16.040 --> 10:21.040] So if a zero-day hits, it's not necessarily a good idea to start investigating which product [10:21.040 --> 10:27.640] uses a vulnerable component at that point, because then that delays the process. [10:27.640 --> 10:30.840] And obviously, you can only start with the mitigation once you have the full picture [10:30.840 --> 10:32.720] of what you actually need to mitigate. [10:32.720 --> 10:38.360] The other part is something that is more of a legal topic, so compliance, license compliance [10:38.360 --> 10:39.840] specifically, right? [10:39.840 --> 10:44.520] So a failure to comply with license terms of third-party components is something that [10:44.520 --> 10:47.240] can trigger litigation. [10:47.240 --> 10:51.080] Litigation is something that is very time-consuming and expensive, and our lawyers would rather [10:51.080 --> 10:52.360] do other things. [10:52.360 --> 10:57.480] So it's important for us to also make sure that this part doesn't happen. [10:57.480 --> 11:02.080] And one thing to also be aware of is, generally speaking, at least from our experience, the [11:02.080 --> 11:07.800] larger the company, the larger the compensation claims that people will sue you over. [11:07.800 --> 11:12.120] So if you have a GPL violation, then suddenly we're talking about millions of dollars. [11:12.120 --> 11:16.360] And the worst case, which as far as I know is something that is probably a bit specific [11:16.360 --> 11:22.040] to German copyright law, so it can actually happen that if a GPL violation, for example, [11:22.040 --> 11:27.280] is detected, you can get slapped with an injunction, and you are prohibited from shipping the affected [11:27.280 --> 11:29.760] product until that is resolved. [11:29.760 --> 11:33.840] Which for us, if you imagine that something like that happened with a Linux kernel version, [11:33.840 --> 11:38.320] we have a driver with a GPL violation or whatever, for us that would be a big deal. [11:38.320 --> 11:42.560] So it needs to be avoided just from a business perspective, for both scenarios. [11:42.560 --> 11:47.040] And then even beyond that, of course less tangible, but still, both of these things, [11:47.040 --> 11:50.600] they will land you on the news, and you will not get the good kind of publicity. [11:50.600 --> 11:52.720] So they are actually a PR nightmare. [11:52.720 --> 11:56.040] And that's where we want to get them right, we want to be good citizens, our bombs need [11:56.040 --> 11:57.640] to be accurate. [11:57.640 --> 12:02.600] Yeah, another challenge that we detected early on, because of course even our embedded hardware [12:02.600 --> 12:06.200] colleagues by now, they have figured out that containerization can help them with certain [12:06.200 --> 12:07.200] use cases. [12:07.200 --> 12:12.800] So we also need to make sure that our containers are OSS compliant, and there we have a special [12:12.800 --> 12:16.120] challenge in generating accurate S-bombs. [12:16.120 --> 12:22.960] So S-bomb creation, which is what this chart here pretty much shows, it lies on a spectrum. [12:22.960 --> 12:28.760] So what developers of course like to do is they like to consume public images from Docker [12:28.760 --> 12:30.760] Hub or other public sources. [12:30.760 --> 12:32.000] That's very low effort for them. [12:32.000 --> 12:35.240] They can just pull them, they don't need to create them themselves, but they also don't [12:35.240 --> 12:36.440] know what's in it. [12:36.440 --> 12:40.720] So you have low effort on the developer side, but we also have very low certainty. [12:40.720 --> 12:45.760] So creating an accurate S-bomb is insanely difficult, and in some cases I guess we can [12:45.760 --> 12:48.360] actually conclude it's impossible. [12:48.360 --> 12:53.880] Yeah, and then the further you move to the left, the more effort is actually involved [12:53.880 --> 12:57.760] in building the container, but at the same time you have increasing certainty about its [12:57.760 --> 12:58.760] contents. [12:58.760 --> 13:03.520] The pathological case on the other side of course is that you build every image yourself. [13:03.520 --> 13:09.360] We use a lot of different images, so maybe you don't want every team to build their own. [13:09.360 --> 13:13.320] And so the next best thing that we've arrived at is sort of having these known base images [13:13.320 --> 13:17.800] that get shared within the company, or we consume upstream based images that already [13:17.800 --> 13:22.400] have an S-bomb that we trust, which is of course a major asterisk there. [13:22.400 --> 13:26.960] So you also need to be able to trust the S-bomb, it's not enough for it to be there. [13:26.960 --> 13:31.720] And then there, creating those images is much higher effort, but you also have a much higher [13:31.720 --> 13:32.960] degree of certainty. [13:32.960 --> 13:38.480] So that's something that we realized, and that's something that we try to put in practice. [13:38.480 --> 13:41.680] Yeah, so I mean, these are the challenges, right? [13:41.680 --> 13:45.800] Obviously the conclusion then was we need the common format to facilitate all of that, [13:45.800 --> 13:47.840] and we need to build an ecosystem around it. [13:47.840 --> 13:51.760] So that's what we did, we called it standard bomb. [13:51.760 --> 13:56.600] We have an internal page, landing page for the format, so if you try to navigate to [13:56.600 --> 14:00.120] that right now, it will not do anything for you. [14:00.120 --> 14:04.880] But the reason we are showing it is because that domain pretty much tells you this isn't [14:04.880 --> 14:11.200] just a side project that we started, it actually is one of the main sub-domains within the [14:11.200 --> 14:12.200] company. [14:12.200 --> 14:15.920] So we already have a lot of teams using it, and yeah, it's growing. [14:15.920 --> 14:19.520] So we are picking it up, we are now actively looking into ways we can make some of this [14:19.520 --> 14:22.640] available upstream again, and in fact we already have. [14:22.640 --> 14:27.240] So I contributed the Cyclone DX support to Scanco Toolkit a while ago. [14:27.240 --> 14:30.880] But yeah, so we are still figuring some of that out. [14:30.880 --> 14:35.040] Yeah, so Thomas already preempted that a bit. [14:35.040 --> 14:36.880] What is standard bomb? [14:36.880 --> 14:39.560] At its core, it's Cyclone DX 1.4. [14:39.560 --> 14:44.240] The special caveat is, or maybe I quickly need to explain what Cyclone DX is. [14:44.240 --> 14:51.440] So it's an OAS format, and it prides itself in being lightweight and composable, you can [14:51.440 --> 14:56.680] add extensions to it, and so for us that flexibility was really appealing. [14:56.680 --> 15:00.400] One limitation that we already put on it for our internal use, which is probably a bit [15:00.400 --> 15:05.040] controversial, but we did it because we prefer it, we only use the JSON flavor. [15:05.040 --> 15:07.160] We don't care about the XML. [15:07.160 --> 15:12.560] Once you start dealing with large XML documents, you have to worry about things like vulnerabilities [15:12.560 --> 15:14.680] in your parser, and we don't want to deal with that. [15:14.680 --> 15:16.880] With JSON, they are much rarer, generally. [15:16.880 --> 15:18.800] They're not impossible, but they're rarer. [15:18.800 --> 15:23.840] So of course, using JSON makes it pretty much programming agnostic, because every language [15:23.840 --> 15:29.640] I know of, unless maybe Cobol has a JSON parser, and probably Cobol does too, I just don't [15:29.640 --> 15:32.320] know about it. [15:32.320 --> 15:37.480] And then also, the benefit that this flexible format had for us on top of that is it's independent [15:37.480 --> 15:38.600] of the source ecosystem. [15:38.600 --> 15:42.960] So we have all these different text stacks within the company, they are all supported. [15:42.960 --> 15:47.040] There are upstream tools to create bombs in those cases where those aren't good enough [15:47.040 --> 15:52.040] and up to snuff for what we need, we wrote our own. [15:52.040 --> 15:57.200] And another benefit that it has, it's independent of the consumer. [15:57.200 --> 15:59.280] But, and there's a caveat here, right? [15:59.280 --> 16:04.520] So it's important to keep in mind, even though they are independent of the consumer, as [16:04.520 --> 16:09.560] Thomas already mentioned, usually you create it with a special use case in mind. [16:09.560 --> 16:14.800] So if you submit an S-bone for software clearing, maybe you want to also put a statement of [16:14.800 --> 16:20.760] intent alongside it to say, yeah, this is mainly for software clearing purposes, don't [16:20.760 --> 16:22.760] use it for vulnerability scanning. [16:22.760 --> 16:26.480] Because if it contains references to the source packages, there's actually a high possibility [16:26.480 --> 16:31.560] that your actual product, because the binary doesn't have the source, isn't affected. [16:31.560 --> 16:36.080] So that's a statement of intent that we support through something that we call profiles. [16:36.080 --> 16:38.760] So that's metadata in the bomb. [16:38.760 --> 16:42.680] And yeah, that was also a valuable addition from our perspective. [16:42.680 --> 16:45.960] So that's pretty much what I have to say about it. [16:45.960 --> 16:50.640] And now to get into the nitty-gritty details, I will hand over to Thomas. [16:50.640 --> 16:54.640] Thanks. [16:54.640 --> 17:00.240] So, well, we're using Cyclone DX, so do we do something special a little bit? [17:00.240 --> 17:03.560] But at the end, we still use Cyclone DX. [17:03.560 --> 17:08.320] So every of our standard bombs is 100% Cyclone DX bomb. [17:08.320 --> 17:11.760] And this is that we really like to emphasize. [17:11.760 --> 17:18.080] But because we are consumers, so we heard in the morning a lot of people create S-bombs. [17:18.080 --> 17:22.760] So on one side we create also S-bombs on the other side, but we are also the consumers. [17:22.760 --> 17:27.680] So we need to ensure that we understand all the information whoever created it. [17:27.680 --> 17:32.480] So we just needed some additional set of rules or guidelines. [17:32.480 --> 17:36.920] So for example, we decided that we want to have the components as a flat list. [17:36.920 --> 17:40.400] We don't want the hierarchical structure. [17:40.400 --> 17:45.400] In the Cyclone DX S-bomb as it is, but we still have the dependency information because [17:45.400 --> 17:48.640] it's just at another place. [17:48.640 --> 17:53.320] Another thing is that we find out we need some additional properties. [17:53.320 --> 17:59.760] And, well, if you tell your developers just add something, they will add it anywhere under [17:59.760 --> 18:00.760] any name. [18:00.760 --> 18:04.000] So Cyclone DX offers properties. [18:04.000 --> 18:06.560] These are just the key values to work. [18:06.560 --> 18:10.640] So we talked to the Cyclone DX guys and they said, okay, you could reserve a namespace. [18:10.640 --> 18:11.640] So this is what we did. [18:11.640 --> 18:18.000] We provided a taxonomy and now we have the Siemens column, whatever, to clearly describe [18:18.000 --> 18:19.400] this as one of our properties. [18:19.400 --> 18:24.000] So this is maybe something that our developers should use. [18:24.000 --> 18:30.000] The next thing, because the three of us come from the license compliance side, is that [18:30.000 --> 18:32.160] we require the source code. [18:32.160 --> 18:38.160] We require the source code because this is what we scan for licenses, for IPR issues, [18:38.160 --> 18:39.960] export terms, those things, whatever. [18:39.960 --> 18:44.400] So we need to find a way to express where can we find the source code. [18:44.400 --> 18:51.560] So it could be a local file, it could be the upstream location, but we have a way to describe [18:51.560 --> 18:53.720] it in Cyclone DX. [18:53.720 --> 18:59.520] And then the next thing is that the best case would be if the development teams pack all [18:59.520 --> 19:00.520] of this together. [19:00.520 --> 19:05.000] So the source code, maybe also the binaries and the S-bomb. [19:05.000 --> 19:08.800] And this is then something that they ship to our backends. [19:08.800 --> 19:13.920] And then we have all the information that we need. [19:13.920 --> 19:18.800] So just to give you an overview, I know it's small on the screen. [19:18.800 --> 19:23.400] So you see a lot of standard Cyclone DX properties. [19:23.400 --> 19:26.800] You also see the license, for example. [19:26.800 --> 19:29.240] And what do we have some other information? [19:29.240 --> 19:33.360] We have the source code, we have the information about the website, which is still standard [19:33.360 --> 19:34.360] Cyclone DX. [19:34.360 --> 19:37.280] But we also want to know, OK, is it the direct dependency or not? [19:37.280 --> 19:40.080] Sometimes we need this, sometimes not. [19:40.080 --> 19:42.680] We would like to know what kind of a regular language is. [19:42.680 --> 19:47.800] We add, if we find such information, also in the first thing, scan something about third [19:47.800 --> 19:51.480] party notices or copyright statements. [19:51.480 --> 19:55.560] Just a short example how this would like. [19:55.560 --> 20:04.040] Now maybe for a better understanding, again, what do we do when we talk about this S-bomb? [20:04.040 --> 20:05.720] We use it as an input. [20:05.720 --> 20:07.560] So we have the developers. [20:07.560 --> 20:10.360] The developers commit their code. [20:10.360 --> 20:15.480] Many of them do it to a central GitLab instance that we have, which is called code.zimmons.com. [20:15.480 --> 20:19.600] And there they run their continuous integration, continuous development runs. [20:19.600 --> 20:27.160] So this is where our tools kick in, part of CI, they use scanners either from us or from [20:27.160 --> 20:35.400] Cyclone DX or created by themselves to create at least the first version of an S-bomb. [20:35.400 --> 20:40.360] And if the S-bomb maybe does not contain all the information, then we have additional [20:40.360 --> 20:44.600] tools, maybe to find source code or to guess where the source code might be, to download [20:44.600 --> 20:50.720] the source code, or if we have different kinds of ecosystems to merge S-bombs. [20:50.720 --> 20:56.600] Because let's say you have a container, you have maybe a scan for the front end, NPM components, [20:56.600 --> 21:00.480] for Java components, for.NET, and the underlying operating system. [21:00.480 --> 21:04.400] So we want to combine it to one big S-bomb. [21:04.400 --> 21:07.760] And yeah, we also have some kind of validator. [21:07.760 --> 21:12.040] And then this is something that can get forwarded to our backends. [21:12.040 --> 21:16.560] So we have different kinds of backends, but one of them that you already had talked about [21:16.560 --> 21:21.200] is SW260 and with a scanner for Solitude. [21:21.200 --> 21:28.440] So again, we use this information, store it, let's say, in SW260, and then someone else [21:28.440 --> 21:34.760] pulls it out of SW260, does a scan with Solitude to determine what the licenses are, what the [21:34.760 --> 21:36.360] copyrights are. [21:36.360 --> 21:41.960] So the detailed information, where this information is found, we don't need it here. [21:41.960 --> 21:43.400] We need it down here. [21:43.400 --> 21:47.760] But then it's created by Phosology, and probably it's SPDX. [21:47.760 --> 21:50.960] It might not be necessarily Cyclone DX. [21:50.960 --> 21:53.760] But again, our focus is here on the input. [21:53.760 --> 21:59.080] What Siemens then does, we have a look at the single component, determine the licenses, [21:59.080 --> 22:03.720] the copyrights, the obligations, as we also heard from the French colleagues. [22:03.720 --> 22:08.800] Our legal team has a look at it, and then at the last step, we do something what we [22:08.800 --> 22:14.880] call product clearing, that is, we take a look at all the components, all the licenses, [22:14.880 --> 22:18.680] all the obligations in the context of that rubbery product. [22:18.680 --> 22:22.080] And then we do a final check if everything picks. [22:22.080 --> 22:28.720] Because you may know that if you have an embedded products, there may be another situation [22:28.720 --> 22:34.160] than if we have a cloud back-end or a cloud front-end. [22:34.160 --> 22:40.440] Now, this is maybe the way that it takes to get to a good S-bomb. [22:40.440 --> 22:45.640] So we think it's not an easy way, and we are not yet done. [22:45.640 --> 22:51.120] We shared our experiences, our opinions, our approach on what we did or what we would like [22:51.120 --> 22:52.440] to do. [22:52.440 --> 22:57.560] And now really, we are here also to hear your comments on that. [22:57.560 --> 23:02.800] So parts of the things have been upstreamed, are available as open source. [23:02.800 --> 23:07.400] Is this the US case that you would also be interested in? [23:07.400 --> 23:12.720] Is it something where you would say we should do more open sourcing of our tools? [23:12.720 --> 23:18.160] And then the interesting question is, well, if there is already a Cyclone DX Gradle scanner [23:18.160 --> 23:26.400] or PyP scanner, do we want to have another one, or should we find a way to combine it? [23:26.400 --> 23:33.080] It's up to what the open source community would like to have. [23:33.080 --> 23:37.360] So I guess we have five minutes left. [23:37.360 --> 23:42.960] On one side, you see the key takeaways from our presentation. [23:42.960 --> 23:47.880] I don't want to go to all of them again, because maybe you have questions. [23:47.880 --> 23:51.880] There's a question from the chat right now from Borger. [23:51.880 --> 23:57.160] Question, how do you generate and track S-bombs for multiple language projects? [23:57.160 --> 24:01.520] On your introductory slide, you will mention lots of programming languages being used to [24:01.520 --> 24:02.520] teach. [24:02.520 --> 24:07.360] Yes, so there are separate scanners to create. [24:07.360 --> 24:15.920] The question is, the question is, how do we generate S-bombs for multiple languages or [24:15.920 --> 24:16.920] for multiple ecosystems? [24:16.920 --> 24:18.520] Yes, we have different scanners. [24:18.520 --> 24:27.640] So here, some of the scanners that we created by our own. [24:27.640 --> 24:32.680] If we don't have a matching scanner, we tell the people to look for Cyclone DX scanners. [24:32.680 --> 24:36.640] If there is no scanner like that, then, well, these are developers. [24:36.640 --> 24:37.640] They can do it by themselves. [24:37.640 --> 24:38.640] And then you merge the results. [24:38.640 --> 24:39.640] Yes. [24:39.640 --> 24:40.640] Yes. [24:40.640 --> 24:41.640] Yes. [24:41.640 --> 24:47.640] At the end, it depends on the use case, whether we process them separately or not. [24:47.640 --> 24:51.800] But we have the way to merge them. [24:51.800 --> 24:52.800] More? [24:52.800 --> 24:55.640] Yes, just a quick comment on that. [24:55.640 --> 24:56.640] Can you? [24:56.640 --> 24:57.640] Yes. [24:57.640 --> 24:58.640] Thank you. [24:58.640 --> 25:03.800] So we merge because what we found is at build time, these separate build tools, so whether [25:03.800 --> 25:10.200] it's Gradle or the Go compiler or whatever, they have a lot more information than just [25:10.200 --> 25:13.080] doing static analysis with some other tool like scan code. [25:13.080 --> 25:18.080] So occasionally, for specific use cases, we prefer to go through build plugins that have [25:18.080 --> 25:20.280] all that build metadata to get the full picture. [25:20.280 --> 25:23.080] And so that's why we actually have that modular approach. [25:23.080 --> 25:24.080] Right. [25:24.080 --> 25:27.080] Siemens is a big organization. [25:27.080 --> 25:28.080] What have you done to your supply chain? [25:28.080 --> 25:32.080] Because I'm sure you've got lots of things coming into Siemens. [25:32.080 --> 25:36.080] What are you doing with the components that are coming that have S-bombs or don't have [25:36.080 --> 25:37.080] S-bombs? [25:37.080 --> 25:40.880] Have you changed the way you are reacting with your downstream supply chain? [25:40.880 --> 25:41.880] We hope. [25:41.880 --> 25:46.640] Ah, what do we do with all the suppliers? [25:46.640 --> 25:50.000] Do we just rephrase it? [25:50.000 --> 25:52.880] Do we hope that they have S-bombs? [25:52.880 --> 25:56.480] And the question is, yes, we hope, but we don't expect it. [25:56.480 --> 26:01.880] So are you generating S-bombs essentially in Siemens components? [26:01.880 --> 26:02.880] Yes. [26:02.880 --> 26:03.880] Yes. [26:03.880 --> 26:04.880] Okay. [26:04.880 --> 26:05.880] Yes. [26:05.880 --> 26:09.280] So that is something that is actively being worked on to comply with the executive [26:09.280 --> 26:10.880] order and so on. [26:10.880 --> 26:11.880] Yeah. [26:11.880 --> 26:12.880] The one in the back. [26:12.880 --> 26:16.880] What has made you choose Cyclone DX over SPDX? [26:16.880 --> 26:17.880] Yeah. [26:17.880 --> 26:20.880] So the question is, and we anticipated it because we already had that conversation with [26:20.880 --> 26:22.880] Kate at the fringe event. [26:22.880 --> 26:28.480] So why did we choose Cyclone DX over SPDX, right? [26:28.480 --> 26:33.560] So it was partly because that's what all of us already knew. [26:33.560 --> 26:35.400] So that was the first point of contact. [26:35.400 --> 26:39.240] And the other reason is that we got going on in a lot more quickly. [26:39.240 --> 26:40.480] So it's lightweight. [26:40.480 --> 26:44.520] You can start at a very low level and then build on top from there. [26:44.520 --> 26:48.720] Whereas, so our subjective experience, I'd like to say it might be different for somebody [26:48.720 --> 26:53.440] else, but so the SPDX spec is quite daunting in its depth. [26:53.440 --> 26:54.960] And we didn't need all of the features. [26:54.960 --> 26:57.880] So understanding the spec fully wasn't in scope for us. [26:57.880 --> 26:59.640] Yeah, sure. [26:59.640 --> 27:04.200] I would like to add one thing about the SPDX versus Cyclone DX thing. [27:04.200 --> 27:10.440] I mean Siemens is relatively large and there's lots of different parts in it, right? [27:10.440 --> 27:14.040] And that's probably, as it is in most companies of that size. [27:14.040 --> 27:19.760] And we discovered that we had already started with Cyclone DX individually before we came [27:19.760 --> 27:22.800] together as to solve this centrally, right? [27:22.800 --> 27:26.520] And then once you discover that on an important question like that, you're already almost [27:26.520 --> 27:27.520] aligned, right? [27:27.520 --> 27:30.760] Then you don't open that kind of worms again to choose the best formula. [27:30.760 --> 27:33.560] That's kind of a, well, realistic approach. [27:33.560 --> 27:40.520] How do we scan containers? [27:40.520 --> 27:41.520] How do we scan containers? [27:41.520 --> 27:47.800] Yeah, so I'd like to say that's still very much an ongoing field of research internally. [27:47.800 --> 27:53.800] But I can give you, so I do believe that to give you the full picture, we should maybe [27:53.800 --> 27:56.880] talk afterwards that won't fit into the QA session. [27:56.880 --> 27:59.240] But we have a combined approach there as well. [27:59.240 --> 28:04.560] So we use stuff like scan code IO, turn all these other static scanners, sift actually [28:04.560 --> 28:05.560] to get us started. [28:05.560 --> 28:08.880] But then once you start digging deeper, of course, that's not the scope of the tool. [28:08.880 --> 28:11.520] It needs to be fast. [28:11.520 --> 28:13.160] And then we need to aggregate that. [28:13.160 --> 28:14.600] And that's the biggest challenge, of course. [28:14.600 --> 28:17.400] So reconciling all those different scan results. [28:17.400 --> 28:21.400] And so if somebody is doing active work on that, I'd be happy to talk to you. [28:21.400 --> 28:23.280] Thomas, maybe? [28:23.280 --> 28:24.280] One last question? [28:24.280 --> 28:40.320] Yeah, so the question was, how do we make sure that the dependency scan is complete? [28:40.320 --> 28:47.280] Well, I mean, it would be snagal to say that we can always be sure, because we're not going [28:47.280 --> 28:48.280] to be sure. [28:48.280 --> 28:53.440] But we have a best effort approach that has been tested against lots of images. [28:53.440 --> 28:57.920] And occasionally, people will actually come in after the fact and verify the results. [28:57.920 --> 29:02.160] And based on those findings, we will improve. [29:02.160 --> 29:04.520] And that's not one other aspect to that. [29:04.520 --> 29:09.200] And we kind of mentioned it on the containers slide when we were at that point. [29:09.200 --> 29:11.720] It depends a little bit on what you're scanning, right? [29:11.720 --> 29:16.160] So if it's in your source ecosystem, then I can, as a developer, I can be reasonably [29:16.160 --> 29:18.360] sure that the S-bomb is complete. [29:18.360 --> 29:43.840] If I take a random container from the internet, then that's very difficult.