PurePerformance - Hello BOB - Cloud Native Cybersecurity with Bill of Behaviors with Constanze Roedig

Episode Date: September 29, 2025

On September 8 the world saw the npm supply chain attack. Fortunately the community reacted in record time to avert a disaster. In todays episode we have Constanze Roedig, Key Researcher at SBA Research, who introduces us to the new buddy of SBoM (Software Bill of Materials): SBoB (Software Bill of Behaviors) and her thoughts on how that new approach to fingerprinting software can help cyber security teams. What's a BoB? It's a detailed runtime behavior profile of software. It expands on the static validation option through SBOMs as it allows security teams to validate the correct execution behavior of deployed software at deploy time or continuously in production. Thanks to eBPF, a malicious behavior such as opening non expected ports or accessing non expected files can therefore be detected.Listen to Constanze who shares the work she and Vadim Bauer, Owner of 8gear, have done on this topic. You will learn about how software vendors can create their own SBOBs, ship them with their container images and how security teams can get alerted or enforce any detected malicious behavior. Make sure to check out their GitHub repo, star it if you like it and try their hands-on tutorial!Links:Constanze LinkedIn: https://www.linkedin.com/in/croedig/Vadim LinkedIn: https://www.linkedin.com/in/vadim-bauer/OBobCtl GitHub Repo: https://github.com/k8sstormcenter/bobctlCloud Native Summit Munich Talk: https://www.youtube.com/watch?v=XETuwndd_mw&index=11&pp=iAQBnpm supply chain attack: https://www.infosecurity-magazine.com/news/npm-supply-chain-attack-averted/

It's time for Pure Performance. Get your stopwatch is ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Welcome, everyone, to another episode of Pure Performance. This is not the sexy voice. Brian Wilson. This is just the regular voice of Andy Grabner. And you know, if you are a regular listener, if I do the intro, that means Brian Wilson had something better to do, even though I got to say, well, it's his fault. It's a shame because we have a great topic and a great

guest today. Constance, Serbos. Yes, service, Andy. Serbis Brian in absence. Hey, Constance, it's really great that I finally have you on the Pure Performance podcast. Now, I'm sure we would have found many, many different topics in the past to talk about. But we got to talk about this topic today because you had a presentation at Cloud Native Summit in Munich. And then everybody was like, I was like walking through the hallways. And then I always ask people, what are the talks that I didn't see that I should watch later on? And your talk came up in a couple of conversations. Because your talk is around the software bill of behavior, S-Bob.

And I think many people don't even know what S-bombs are. Now we come up with another S, another acronym S-Bop. Constance, I want to really talk about this. This is a really interesting way to really make us more aware about security problems, about cybersecurity. Before we dive into the topic, I would like you to explain to the audience who you are your background just a little bit too that our listeners get to know you yeah thank you andy yeah this is a this is a topic that came out of almost nowhere and the name actually he's also not

here Vadim today was actually the one that caught or coined this beautiful name as bob just as the s bombs so my name is constance i am now a key researcher at sba research in vienna but also I'm working independent, trying to be also an entrepreneur. So my goal nowadays is to use my previous understanding, both as a theoretical physicist, as well as my experience in finance, in reinsurance, in regulated sectors, as well as in pure R&D, to make especially Europe more sovereign and more resilient. And this idea is really something that happened out of nowhere. And when we saw that people understand it and people adopt it, then we found, or I found,

I will put in some effort to just check it out, have a challenge by the community, if this so-called software bill of behavior would be something that makes security actually usable. Because when we talk about resilience, cyber resilience, sovereignty, all of this is, you know, beautiful and academic, but the danger is always that it dies, right, because nobody can actually use it in their everyday life. And so this is why this topic is quite different from everything I've done before because it actually, the idea was accepted much faster than technology. And so, yeah, I'm really excited to talk about it.

And I'm currently putting, this is my hobby at the moment. So I'm not getting any funding. I'm not, you know, I'm just convinced that it should be tried and challenged by the community. Yeah. And folks, as we're going through the topic, the first thing, and I will probably mention this once or twice or more. There's a really good website, or it's a GitHub repository that Constance and also Vadim, you pointed me out. It's the software bill of behavior, the tooling Bob CTL or Bob Cuttle or however you

prefer to pronounce it. Not only does it explain a bill of behaviors, it also has, I think, the slides that you used in your talks to really explain the content and this and how it works, but what I really like, there's also a tutorial, a self-guided tutorial. Folks, the only thing you need is a GitHub account and then you walk through a self-guided tutorial. Quick shout-out again because you have a kind of a deaf container that runs in there like a virtual machine that runs all the software and does everything. Can we do a quick shout-out to the team that is providing this particular service? Absolutely. This is Ivan from, you might know him from

the server side. He has a blog and this was his live blog. excemioslabs.com and yeah affordable server-side training and we now use it for research for open science and for sharing our upcoming you know standards hopefully so constance i'm not an expert in this topic at all the only thing that i understand a little bit is s bombs the software bill of material where the idea is when you build software you basically say and the software is this package and it contains all of these ingredients, right? And then when you get this piece of software and you unpackage it and you deploy it and then you can see what is actually in there, it is in there what the vendor told me that it should be in there. Makes a lot of sense. Nobody has

tempered. It's a validation that nobody has tempered with the package. Now, what is SBOP then? Software bill of behavior. Yeah. So the analogy that I now like to use a lot is when you buy medication. So the S-bomb is when you buy the package and you read the ingredients on the top. Often it starts with water and then there's maybe the active ingredient number one, which if you have aspirin, is salicylic acid. And then there's typically stuff that you, unless you have a degree in pharmaceutical chemistry, you don't understand what it is. But it's, as you said, if you know what it is and you can one-to-one check that this is exactly

what you expect, you can see this is the ingredients. But especially when the CRA, the Cyber Resilience Act, came out, what was required or what the act asks us as software vendors is to provide on demand the software bill of materials. And it's supposed to help us, you know, making the world more resilient. But my criticism of this has often been, but, you know, the breaches of companies, they happen at runtime. time. They don't happen at deploy time when I compare these ingredients. They happen in the software as it is running somewhere. And couldn't we do a fingerprint? Something like when we go back to the pharmaceutical for the medication, something like the insert or in Austrian or determined the bipak settle, where it tells me about the behavior that the system component has onto my

system. So if I install this software, how would it look like while it installs itself? So basically to fingerprint the installer. So I can verify this is exactly the installation objects that are really deployed in my runtime. Maybe you see on Monday, September 8, I think it was the NPM compromise by crypto checker. For about 20 minutes when, or I don't know exactly how long, very short amount of time, there was a crypto checker in the debug NPM package and a couple of other NPM packages. because of a fishing attack on the maintainer. And it was very, very difficult to, just with a bill of materials to compare, well, where did I deploy it?

What if I had this fingerprint in the runtime? If I had everywhere a means to see, this is a deviation now, this crypto checker has a totally different runtime behavior than a debug package, right? And we can immediately see, aha, this is where I'm running it, and I see alerts everywhere. And that was the basic idea that at runtime, where the impact really happens and where I need to react fast, that I can see the deviation of the runtime behavior. And so, yeah, the idea is that the software vendor gives us this profile, because this is the important danger or naivitator was often used in the past where it didn't work, which is also important, is that the behavior profiles, if they're wrong, or if you as a user have to create them, then they're pretty much. useless because you don't know if you've already recorded the malicious behavior. So the big difference is now we have the container bypass settle.

So with the container comes with the standard, a fingerprint that is transferable, and this fingerprint was produced by the person or a vendor that knows the software, right, that knows what that software should look like. And this is why it's useful for a default, secure as default runtime fingerprint. that a user can base their anomaly detection on. Awesome. I like the analogy. I'm pretty sure we will take some of these snippets

that you just mentioned for the promotion of this. But to kind of recap a little bit, S-bombs, if I look at a package, I have 50 tablets in there. Or if I look at a piece of software, I have these libraries that are part of it in these versions. the software bill of behavior, however, says, and again, currently my English also escapes me, it's the Ausweig, or how it works, right, the medication, or when it comes to software,

it is if you install the software, which files are accessed, which ports are open, whatever else, but this is kind of like the behavior, and if the software, your idea, your proposal is, if the software vendor not only gives me the piece of software, the ingredients, but also tells me how this thing behaves, which ports it open, which files it, it accesses, read, right? Then we can validate if the system behaves differently than the vendor tells me it should behave. Precisely correct. And let's say, especially when we use observability tools like Dinotrace, and I want to use the correct Dinotrace software, right? And there is this, like, who is the software calling home to? It's always very important.

especially if it is security of observability tooling. And what if somebody corrupted this web page, this endpoint, this DNS point somehow? And this is not dinatrace.com, but it is a mistyped dinetraise, but it's in fact the different DNS look up. I think it's very important for the trust between the vendor and the user

that this really is the dinah trace that you're wearing the shirt and not some fake. And I think they're currently is no regulation that asks us to verify that this endpoint where the telemetry goes to really is that endpoint that I thought it was. And it takes a lot of time for me to manually check, is this really the real diner trace or is this some fake, right? And if you could just provide it to the user and possibly you do it anyway, but many

other companies, especially in the open source world, you know, maybe do not. So if I have a means to verify out of the box, this is the known network endpoint, well, then I feel more secure, I hope. Yeah. And I told you before we hit the record button that years ago, we also bounced around the idea of using distributed traces and analyze them if, for instance, my microservice after a deployment is really only connecting to the backend database it's supposed to connect because we have this information on the trace.

Or a more common thing we actually analyzed with this is sometimes configuration mistakes happen and then you deploy a new version in pre-prod and it connects to the production database. So it connects to an environment it shouldn't. And we only have trace data available. And now my question to you, going down a level deeper on the technical level, how is something like this implemented? So currently it is an EBPF tracer. Maybe you know Inspector Gadget.

It was one of the older tracers, like one of the older EBPF tool stacks. Cubescape is another open source tool in the CNCF as well that wraps a lot of different projects and also wraps inspect the gadget in the Cubescape node agent. And what it gives you is a single YAML file, it's a flat YAML file. It can be really arbitrarily long and it records all the file opens, the SIS calls, the capabilities, the network endpoints, also the protocols and headers even, and the SIS calls. And you can specify rules if you have exceptions, et cetera. And, yeah, so there are also other tools that we don't yet work with, like NeuVector.

I know it does something similar. I don't know it in detail yet. But for example, so this is not the only tool that does such a thing. I now only work with Inspector Gadget slash Cubescape. And so that means also this is all stuff, folks, again, go to the website, go to the Git repository, it gives a great explanation. and you also walk through the tutorial where you are running an application and basically you're executing some load and then you're getting all of these details about what the application actually does. So it's really cool.

So that means the idea is if I'm a software vendor and hopefully do my testing, obviously, right? While I run my tests, I use tools like Inspector Gadget to then understand and collect what are the system calls, what are the file, what are the ports and everything. And then I take this and package it up with my container so that my container then includes my binaries and my S-Bob. And when I then deploy it and our customers or whoever uses this particular piece of software can use this information to validate that the system acts

and behaves exactly the same way as the vendor intended. Precisely. And in this case, So, you know, we also want the user, just like in the packings bylager or the bypass settle, you always have this ability for the user to use it differently, right? Or the doctor to say prescribe this because reasons, because everybody is different, you know, you might have different side effects. And we wanted to have the same thing.

So many people use Helm. So we asked what are all these templating engines? We started with Helm, 80% of people said they know it and use it. So the idea is you have the same idea of overrides or customizations that you are very much used to in the open, in the cloud native and open source space. So basically you can say I install dinetraise, but I don't use the namespace, diner trace.

I use Constance in namespace because of it. And so I can automatically do this templating. And this is also, I think, very, very important for the user acceptance is that people bring in their own knowledge and their own usage of their tool and can override. And they still benefit from the defaults. And I can say, well, but this port, I use a different port here. So it's not hard baked.

And it uses normal regex, which also pretty much everybody is familiar with, that you can modify a couple of paths that you want to change. And then who is, again, from a technical perspective, I understand how a vendor could kind of record and create an S-pop. on the enforcement side. Technically, is it enforced through which tools or do you have your own operator? How does the enforcement work?

So currently what we've done the exploration on or the prototypes on is using KubeScape on the production side and KubeScape on the user side, but different versions of it and also different kernel versions, different Kubernetes versions, and this is only for alerting. That's very important. Currently, we're only implementing alerting because we all, if you've ever used the Linux security module like S.E. Linux or ARMA, you know how dangerous it is to go into enforcing when you're still not sure because you break production, essentially.

So currently only alerting. So what's on the roadmap is to support other such tracers that behave similarly as, as I said, NeuVector. And the Bob CTL is, will be essentially a collection of pearls scripts that translate. the one YAML dialect into the other YAML dial too much. And for the enforcing part, there we have two much, much older and more established tools. So I will still do my recording. I always do it with KubeScape. And then I'm translating a small piece of it. For example, the capability section.

The combination of capability and executable is probably the most stable and the most powerful section of the profile. and that I can transpile into up-armor. Up-Arma can then enforce it in its usual traditional way, and we use all the safe points and don't endanger production, because it's a much, much smaller subset. And this already works, we can combine it with Seccom. Seccom is also a very old established way of sandboxing in the kernel,

which acts like a ciscombe, sorry, a cis-call filter. And Kubernetes supports both UpArma. and SACCOM profiles, I think, since 1.19, Kubernetes version, so a long time ago. Very cool. Folks, if you're listening to this and you're not as deep into the security world as Constance, I think if you feel the same like me, this is a lot of new things that we learn. Most importantly, this is really about bringing, I think for me, the big aha moment when I read through your Git repository and looked at the presentation.

is that I always thought S-bomb is all we need. But obviously S-bomb is a very static thing and we don't know how the dynamic behavior of software really is where it was tempered with during the runtime. And so Constance, I know this is a rather new project and we will provide the links to all of the material, your presentation, your Git repository, your LinkedIn profile also, not just from you,

also from Vadim, who couldn't make it today because of my mistake because I used the wrong email address when sending out the placeholder so Vadim, I am sorry, Trudigong, we'll get you back at the next episode

we do about the project. What are the next step that the community needs to do? What do you want, what do you need the community to do to make this fly? The one thing is

I need other maintainers to give me their test cases Because so I'm very happy to do all the tracing and write the pearls scripts to properly, you know, generalize it, reg exit. And also, T.OVine has granted me a hardware bucket, essentially, of allowance. So I can build all the emulated kernels and Kubernetes versions and as much of a test matrix as I can. So I can run a software, let's say, Pixie or Tetragon. I can run it or the Redis database on all these different versions and build a generalized profile, right? Because the importance, again, is that this trace actually or this fingerprint transfer.

So I need to generalize it to some extent to build all this reg X. So that's something I'm very happy to do. But what I cannot do is create test cases because, again, I'm not the person who knows this software. So I need to ask the maintainer or producer to give. me their test suite. This is also why we started with Pixie, because I worked with Dom Delano from Cosmic, who is one of the chief maintainers of Pixie. So he gave me their test cases and made sure that it actually, you know, it's actually correct and triggering all the benign behavior. I think, I mean, ideally, right, this gets integrated in your CICD test pipelines. So if you're

building, if you're deploying, hopefully many are around. at least some type of tests, functional performance test, whatever tests. This is a great opportunity while these tests are executed, that you can then capture the behavior. And so I think integrating this into the build pipeline or into the delivery pipeline and test pipeline would be awesome. And then the scales, I would say, right? Yes.

So this is definitely a roadmap feature that I would be able to predict actually what are the gaps and what is the optimum, you know, detail. level of a profile because one thing we have to be careful about that we don't have too much of a performance degradation at runtime because you have to imagine we're doing anomaly detection so we're diffing so if generate a very nice profile of 100,000 lines of file opens we're going to really degrade the runtime performance of this thing this is why we need to find an optimum and this actually we have hopefully master's students this is coming out of people trying out how can they find the optimum also, and this is another cool thing,

is to avoid this alert fatigue in the people that need to deal with the alerts that come out of the anomaly detection, right? You want to find that optimum ratio of false positives versus noise, true positives versus noise, for this to have a good decrease in the attack surface, but not too much false positives. for whoever looks at the SOC report. So we're the operation center.

Yeah, yeah, yeah. Yeah, makes a lot of sense. Yeah, I mean, you brought up a very key term, alert fatigue, but this will only fly if people don't think this is just overwhelming them with useless information or if you have too many false positives. Besides, the links that we already covered that we will add to the description, As of the time of the recording, we are early September. I think this one will air around mid to end of September.

You will be talking about this at any upcoming conferences or events or webinars? Absolutely. So next week in KCD, Sophia, we'll have a talk about it. Then at KCD Austria, so C in Cloud Native Days, Austria, we'll talk about it. There will be a keynote about Bob Ctel at KCD Denmark. then we will mention it at the KubeCon North America in Atlanta because it will be the base of our IOUring rootkit detection suite that we're doing together with Pixie.

And in Munich at the Security Summit, Munich in December will also talk about it. You got a very busy fall ahead of you. That's pretty cool. Yeah, don't close your eyes. So that is. It's good, right? That tells you you have a hot topic. And especially, you know, these are new ideas, new ideas that we need to tackle these challenges that we have with when it comes to security. Yeah. And from the community, I also received a lot of support. I must really, this is also why I got so many talks. And while it's overwhelming in one side, and what I'm also looking forward is constructive challenges. Because a lot of people are destructively challenging. it like this has failed so many times before because fingerprints are too you know to specific etc but also constructive challenges you know people that say like um you know we've done this before and we've learned this and this and this format that's yeah if somebody if the people want to open

issues very very happy to engage with them so folks again this is the last reminder the the GitHub repository is Bob CTL in the K-8 Storm Center organization. So you'll find the link. And there will be links also to a LinkedIn post from you that includes the slides and there's a YouTube recording from the talk from Munich and whatever other recording is out there

we'll make sure to put the links into the description. Awesome. Constancy, did we miss anything before we close the session. I think that the big version, and you can call me a complete idealist, is to bring this into the new CRA regulation when it comes out in the next phase in 2008, because I think if it succeeds, it could really help us create a lot more trust in the software world.

And this is the Resiliency Act from the European Union, for those listeners that might not be familiar with cybersecurity. in general or with the European regulations. Awesome. Yeah, that's a very nice way to end this amazing podcast. Thank you so much for the insights. I do hope you get some of our listeners that check out the material. Don't forget to star the GitHub repository.

Don't go. Don't forget to go through the tutorial. That's really great. And, yeah, thanks for your little bee here. if you have seen the screenshot that we took, the thumbnail for the podcast, you may have seen a little bee in the picture. And if you watch the little video that we have

in the LinkedIn promotion, you will probably also see, maybe see the bee on the shoulders because it was sitting there for a while. Constance, thank you so much. Thank you. All the best. See you soon. Thank you so much, Andy.

Thanks so much for your time. And Brian, you missed out on something.