WEBVTT 00:00.000 --> 00:12.680 Okay, pretty full house here, yeah, it makes me happy that so many of you are interested 00:12.680 --> 00:21.520 into security topics and I hope I can meet your expectations and maybe tell you something 00:21.520 --> 00:27.400 new or interesting in this talk. 00:27.400 --> 00:32.840 Before I start, maybe I should note that on my name is Sebastian and I work for the 00:32.840 --> 00:40.280 company Lamentry and we are pretty small team and contractor of the Center for Digital 00:40.280 --> 00:47.000 Server Unity in Germany, so I'm a bit biased maybe because I work together with the 00:47.000 --> 00:53.640 colleagues and a lot of the things I will present to you so maybe just for transparency 00:53.640 --> 00:55.160 at that point. 00:55.160 --> 01:05.720 I would guess a lot of you guys have heard about one of the recent attacks on the surface 01:05.720 --> 01:13.920 supply chain in the last weeks, month, yes, whatever and maybe you noticed that it's also 01:13.960 --> 01:21.840 getting noticed in media that it's not focused on IT anymore, so even in the evening 01:21.840 --> 01:29.400 news or something, this can be a topic nowadays and one of the last big things for those 01:29.400 --> 01:35.560 of you that write or view the movie June, movies June, you will be familiar with the name 01:35.560 --> 01:44.800 Shai Hullud, so the San Wams from this story and there was an attack where initially 01:44.800 --> 01:51.000 an MPM package was compromised and a Wam that replicated itself, so it's still credentials 01:51.000 --> 01:56.080 from the machines where it got installed and tried to replicate in another package and 01:56.080 --> 02:05.480 another package and so on, pretty net these things that made it pretty clear and accelerated 02:05.480 --> 02:15.480 with that whole topic and unfortunately it's not a single shopping, it seems to be a pattern, 02:15.480 --> 02:22.400 so if you look on the lower right headline, it's from 2021, so it's not a really new thing 02:22.400 --> 02:29.280 I would say, but yeah, it's getting more extreme I would say and if you look for example, 02:29.280 --> 02:37.680 the open message F has the malicious package database repository where they list packages 02:37.680 --> 02:42.960 from that we know that are really just malicious, so there's more way inside and so on, 02:42.960 --> 02:53.080 so really malicious packages and around, yeah, summer 2025, we had this plot here about 02:53.080 --> 02:58.480 the numbers and it was like a linear increase I would say, so every year there were more 02:58.480 --> 03:04.560 packages that we know that are malicious and then Shahulud hit it and we now have this massive 03:04.560 --> 03:12.000 increase here in 2025 and that makes a bit of a rainy day when you look outside of the window 03:12.000 --> 03:20.000 as a developer looking at 2026 and the question is what can we do about that, so what can we 03:20.000 --> 03:25.800 do about that and what is public administration doing about that and typically public administrations 03:25.800 --> 03:32.520 are not that progressive in every part I would say or the ones that lead technical development, 03:32.520 --> 03:40.840 but I would say there are some good initiatives. I also would say that a lot of you guys will 03:40.840 --> 03:47.000 have heard the nice bus words, deaf cyclops and shift left, so next to that they are great bus 03:47.000 --> 03:52.520 words, there are some pretty good concepts behind that, so the basic ideas that we try to 03:52.600 --> 03:59.560 automate stuff and that we try to do things early and that we don't want to do security in the end 03:59.560 --> 04:05.480 or as an additional thing we want to integrate it in our development process and we also want 04:05.480 --> 04:10.600 to do it pretty early so when we plan a new feature when we design something we want to keep 04:10.600 --> 04:19.000 security and mind and as said we want to try to automate things so we can do stuff like secret scanning 04:19.000 --> 04:26.280 looking for leaked secrets and our get history it happens the best developer some hopefully 04:26.280 --> 04:31.480 development token gets committed or something you can check that pretty easily and automate it 04:31.480 --> 04:37.960 or you can look for yeah obvious bad practices inside your code using static application security 04:37.960 --> 04:44.760 testing and so on and one big thing is dependency analysis so you all maybe know the number from 04:44.760 --> 04:51.080 the Linux Foundation 80 to 90% of the typical software project are based on open source dependencies 04:51.080 --> 04:59.320 so it's a huge huge thing we have to look at that and have to check there are known 04:59.320 --> 05:06.440 known vulnerabilities for those dependency dependencies what can we do about it and if we recap 05:06.440 --> 05:13.480 how vulnerability management usually works we have to answer several questions so that example 05:13.480 --> 05:19.960 we initially have identified oh using some scanner or whatever we have a critical CVE in one of 05:19.960 --> 05:25.480 our libraries and our dependency tree that we are using and then we have to answer the question 05:25.480 --> 05:34.920 okay if Lypy there's this known vulnerability is a effected of that and if so is our direct dependency 05:34.920 --> 05:41.240 reactress effected of that and if so are we are we using the vulnerable parts of reactress and that 05:41.320 --> 05:49.160 example so several several questions we have to answer and I would say the last one so for our 05:49.160 --> 05:56.600 direct dependencies is often yeah kind of easy so you have decided to use the dependency and 05:56.600 --> 06:01.480 started and you're using it on everyday basis you know what you are doing with that dependency so 06:02.120 --> 06:07.800 it's more easy to find out or to answer this question then for things hidden inside your dependency 06:07.800 --> 06:13.000 tree so the further it gets down in your dependency I would say it's harder to answer that questions 06:15.000 --> 06:22.680 and it would be pretty great if we could share this workload so if that would be a way that if 06:22.680 --> 06:28.040 somebody did that part for the subtree or something or a project is doing it for that part and I'm 06:28.040 --> 06:35.000 using that project inside the chain if we could share this workload and this information assessment 06:35.320 --> 06:41.720 that we're already done and fortunately there is a way to do that it's a so-called vulnerability 06:41.720 --> 06:48.520 exploitability exchange format so machine readable format that allows to share this assessment 06:48.520 --> 06:55.000 resides somebody has has hopefully done and in combination with the S-bomb so the software 06:55.000 --> 06:59.800 bill of materials that answers what's inside the software we can combine that with the 06:59.800 --> 07:07.320 Vex to share to our customers and users and yeah consumers of our software what are the 07:07.320 --> 07:12.120 the resides of our assessment so we can share what's inside which dependencies we are using 07:12.120 --> 07:18.040 and combine also the answers for known vulnerabilities of that package what's the result 07:18.040 --> 07:27.960 are we affected or not and yeah now I want to switch over to the public administration part 07:28.040 --> 07:37.960 because there this was identified or tried to to do in parts so as other speakers today in this 07:37.960 --> 07:45.720 this steproom told the public administration in Germany relies in many parts on container 07:45.720 --> 07:51.960 applications and an operation through container images and there are also some 07:51.960 --> 07:59.560 like policies like cloud strategy and things like that that you put this even further to 07:59.560 --> 08:06.280 to rely more on containerized workloads and therefore the the tenders and identified 08:07.080 --> 08:13.960 or the public sector identified it would be pretty cool if we have a collection of images where 08:13.960 --> 08:20.920 this assessment we're already done and where we can share this information and take a bit of the 08:21.000 --> 08:29.640 burden for the users for the dependency management vulnerability management and of course and 08:30.680 --> 08:37.080 fortunately was also said that has to be transparent and open source and therefore it's not restricted 08:37.080 --> 08:45.160 in ways of reuse to public sectors so everybody can can reuse it but it's it's an initiative made 08:45.160 --> 08:53.000 from from the public sector and needs of the public sector and the working title I would say I 08:53.000 --> 09:01.160 don't know is the container.gov.de website where you can find these images so there are images 09:01.160 --> 09:07.320 provided minimize hardened base images and application images that you can use all open source 09:07.320 --> 09:12.920 license and this is an interesting part they come attested with as bombs and winability 09:12.920 --> 09:18.760 explorability exchanges so all this information what's inside and what's about vulnerabilities 09:18.760 --> 09:25.560 for this components inside are maintained and attested to the images and also there's 09:27.720 --> 09:32.760 requirement you have to to comply with to get listed on this page that you have to be or your 09:32.760 --> 09:41.160 image has to be free of unhandled high or critical known vulnerabilities unhandled in that case means 09:41.240 --> 09:47.160 it's okay if there's a high CVE remaining in your image but you have to state something about that 09:47.160 --> 09:53.880 inside your vex there must be a justification why it's there or you have to have to have handled it 09:54.520 --> 10:04.440 and yeah in addition all images are signed and so on as it's an open source initiative 10:04.440 --> 10:10.200 contributions are very welcome so if you look at it and have ideas feedback want to contribute 10:10.200 --> 10:17.720 something it's very welcomed and you can find all that on the open code platform what's open code 10:17.720 --> 10:24.600 open code is another interesting thing from the public sector it's basically a good lab with 10:24.600 --> 10:31.480 services around it so the send us is providing a space where the public sector can develop 10:31.480 --> 10:38.760 open source software together and also provide services around it's like runa infrastructures 10:38.760 --> 10:46.520 that you can run your CICD pipelines so pot services discussion rooms and so on and so everything 10:46.520 --> 10:53.240 that you need for collaborative and open source development and it's yeah I would say the the 10:53.240 --> 10:58.760 building block below because it's bid on there the runa infrastructures use to bid these images 10:58.760 --> 11:07.240 and so on and another thing we need to look at is the vulnerability management so as stated all these 11:07.320 --> 11:15.320 images have to be free or have to have handled vulnerabilities classified high or critical 11:15.880 --> 11:22.120 and we need to do vulnerability management for that and need tool for that and this is where 11:22.120 --> 11:29.640 the Devcut project comes into place and the mission or vision of the Devcut project is to make 11:29.640 --> 11:36.040 security or develop yeah secure development more easy for everybody and Shannon leads the founder 11:36.120 --> 11:42.360 of the Devx up the second option once said everyone is responsible for security and that is totally 11:42.360 --> 11:49.480 right but we have to enable that because developers and engineers maybe are not that deep into 11:49.480 --> 11:55.000 security topics because they have to do and focus on other things have to do their development work 11:55.000 --> 12:00.280 and in many computer science studies and so on you can go around that topic pretty good 12:01.160 --> 12:08.280 unfortunately and therefore you try to make it easy to get these things done and how we do that 12:09.320 --> 12:16.680 in the first step we need to know what do we have so we have to have a look on our project 12:16.680 --> 12:22.360 and do some scans or even a best case you already know what's inside you already have a 12:22.360 --> 12:29.960 good knowledge of your or of your project and maybe already have an S1 for example to 12:29.960 --> 12:37.080 to start and check for vulnerabilities inside your dependencies but there are also these other 12:37.080 --> 12:44.760 typical Devx setup steps you may want to consider like secret scanning and so on and the Devx project 12:44.760 --> 12:51.160 does not develop skin as itself it just creates a list and pre-configures them 12:52.120 --> 12:57.960 and yeah make them usable and reuse it is your eye components get up actions and so on 12:57.960 --> 13:03.800 that you can easily integrate that into your project and after we have identified what's inside 13:03.800 --> 13:09.880 we can start with management part so one central central thing of that is that you have 13:11.160 --> 13:17.000 possibility for vulnerability management and that you get listed with things or known 13:17.000 --> 13:24.680 vulnerabilities for packages that you are using and of course get more details on these findings like 13:25.240 --> 13:32.600 the official descriptions I think it's unfortunately not that good readable and you also get 13:32.600 --> 13:38.680 details on where's located inside your dependency graph and so on so what's the path to the 13:39.000 --> 13:46.040 vulnerable components and also get supported with prioritization so up here you see a risk score 13:46.040 --> 13:52.040 and typically a CVE so a known vulnerability is assigned with the so-called CVS as a common 13:52.040 --> 14:00.200 vulnerability scoring system so an indication is this something really bad or not not so important at 14:00.200 --> 14:08.680 the moment and so on yeah to help you where to to start and the CVS standard itself says you 14:08.680 --> 14:15.480 have to refit it to your your situation your security requirements you have to enrich it with 14:16.760 --> 14:24.680 current timely information like are there an exploit POCs available things like that and you have to 14:24.760 --> 14:34.440 refit this yeah this critical it criticality score to help you to prioritize and next to and then you 14:34.440 --> 14:40.280 can do the the typical handling options like maybe it's a false positive unfortunately maybe you 14:40.280 --> 14:44.840 have to accept the risk you can fix the risk and so on you can do your normal vulnerability management 14:46.120 --> 14:52.680 next to the dependency part there's also the part with code risk so everything that's inside your 14:52.760 --> 15:02.200 direct code so that that that resides from secret scanning and last analysis and so on yeah 15:03.320 --> 15:10.360 you know and one really important thing we try to consider to base that all on open standards and 15:10.360 --> 15:18.520 open exchange formats so as stated several times they are basically the two yeah would say most 15:18.600 --> 15:24.920 important or of most used formats is a so-called s-bomb so what's inside your project and the 15:24.920 --> 15:31.800 vx and also for static analysis resides the reform up and um or that you can ingest into 15:31.800 --> 15:38.920 devgot and also get out of devgot so it's really based on these open open exchange formats 15:40.280 --> 15:45.080 so that you can use your scan as as long as they provide these these formats 15:45.160 --> 15:52.120 so back to the connection with open code and the hardening of these container images 15:53.320 --> 16:00.840 open code as a platform service has deployed devgot so every user of open code can freely use 16:01.640 --> 16:06.520 a devgot instance and do their vulnerability management there so you don't have the 16:06.520 --> 16:12.840 the need to set up tools yourself and so on so it's just provided as a security service platform 16:12.920 --> 16:18.920 service to you you can just use your existing account to log in there and it even synchronizes all 16:18.920 --> 16:26.120 your repository directly so that you find yourself you find your repository directly and you 16:26.120 --> 16:35.160 don't have this the setup burdens and the most interesting part is that when you're doing your 16:35.320 --> 16:41.880 vulnerability management there and you do all that I've shown before you have like an 16:42.440 --> 16:48.760 without an extra step you get this vx format in the end so you're just ingest your information 16:48.760 --> 16:54.840 you do your vulnerability management and without an extra step you are compatible with the 16:54.840 --> 17:01.880 vx format and also the seesaw format is another exchange way basically also building on the 17:01.960 --> 17:09.480 the vx format to share your assessment resides with your users and this is where it's connected 17:09.480 --> 17:16.920 to this container initiative so all container images are managed or the vulnerabilities of these 17:16.920 --> 17:25.400 container images are managed by devgot and also the attestation in the end is connected there so 17:25.480 --> 17:32.440 the pipeline that bits these images in in the last step fetches your assessment resides from 17:32.440 --> 17:39.720 the open code devgot instance and attest them to the image also with this link connection there 17:39.720 --> 17:45.240 what's pretty interesting because you don't want to have a snapshot you don't want to have this 17:45.240 --> 17:51.480 thing that you build to this image one week ago and there you had three assessment resides inside 17:52.440 --> 17:59.000 and maybe inside or during the week there's also happening something and you have continued 17:59.000 --> 18:04.680 providing information or for example marked another vulnerability that was found later 18:05.400 --> 18:13.320 as was positive you can get the most recent or most latest information by just carrying this link 18:13.320 --> 18:20.840 yeah now but at least I want to do some advertisement for other cool features we just implemented 18:20.840 --> 18:29.640 inside there inside of god is a dependency proxy feature so in that case nothing special and at 18:29.640 --> 18:35.480 first look but the pretty cool thing is that all these known malicious package packages we have seen 18:35.560 --> 18:44.440 in the start like yeah especially it's during a shayhulu to the hex and so on are connected or 18:44.440 --> 18:50.680 your installs are checked against that so if you have JavaScript or go a Python project 18:50.680 --> 19:00.040 you can simply download your packages sorry through this proxy and packages that are known 19:00.040 --> 19:06.760 malicious packages are just blocked from installed before something could happen and you also 19:06.760 --> 19:11.880 are provided with some interesting details about your dependencies so even if there is no vulnerability 19:11.880 --> 19:18.120 inside one of your dependencies it's maybe also interesting to have an overview like when was it last 19:18.120 --> 19:25.160 time published where it's located in my in my dependencies what's about the repository we had it 19:25.160 --> 19:32.600 not the talk to us earlier about the batch program off of senders it's a bit connected to the 19:32.600 --> 19:38.760 scorecard approach of open message f so you maybe want to have some insights about the repositories 19:38.760 --> 19:45.560 behind this dependencies you are using and some other interesting stats yeah and there's even more 19:45.560 --> 19:51.320 inside I don't want to go in detail about that but there are pretty interesting talks around here 19:51.400 --> 19:57.800 today and tomorrow about things like in total size and at the name of the station then so on 19:57.800 --> 20:05.000 and all that are concepts we try to to base this whole approach on and to use and make them 20:05.000 --> 20:12.600 more easy and accessible and yeah you can find dev card as stated it's an open source project 20:12.840 --> 20:23.080 so you can check it out it's an overspe incubation project and yeah I would finish here and we 20:23.080 --> 20:29.400 would love to hear your feedback get impressions try to contribute even with ideas make some issues 20:29.480 --> 20:35.880 and so on and yeah I'm open for some questions now 20:45.720 --> 20:53.240 so you have a proxy one on directly into the individual tool where you get more brief because 20:53.240 --> 20:57.800 it seems like it's on a proxy the one over for a individual user 20:57.800 --> 21:04.280 um I would say yeah yeah so the question was regarding the dependency proxy of it and it's 21:05.960 --> 21:13.560 a lot of work for individual users and I would say yes as an individual would be pretty annoying to 21:13.560 --> 21:21.400 set it up itself but using it it's pretty easy you just can say in your touch NPMRC config I want to 21:21.480 --> 21:27.640 use it and that's it so it's a one-on-line command and a stated there's a public instance 21:27.640 --> 21:32.920 several other public instances maybe your company corporation organization whatever wants to set 21:32.920 --> 21:39.080 up that and then it's a yeah it has a high impact for a central central thing I would say 21:39.080 --> 21:47.320 I've been maybe I got your question not that right yeah that would be great it would be great if 21:47.320 --> 21:52.840 the registries they're self would do that but unfortunately at the moment we don't have that 21:52.840 --> 22:00.840 situation so we have to to help out right and I think open SSF is reporting their findings to 22:00.840 --> 22:05.640 the registries like saying okay we know this is a malicious package maybe we want to block it 22:05.640 --> 22:11.720 or remove it from the registry but take some times not not always working yeah 22:17.400 --> 22:31.400 okay no more questions I take it as a good sign would say thank you and have a nice 22:31.400 --> 22:37.000 day tomorrow