W3C Workshop Secure the Web Forward

Jan: Thanks for having me. As said before, I assume everybody read the papers for today. I won't go into everything that I wrote earlier. I'll pick up the most interesting parts, or the parts that might not be familiar or need to be known for later discussions. As you can see here, it's just a quick and dirty presentation. Just a few words about me.

Jan: I'm a software engineer architect. I'm not a manager or anything, I don't do security for my living. I just write tools or libraries related to SBOM which is short for Software Bill of Materials. And I'm a project co-lead for the OWASP CycloneDX Project. Which is just one thing related to SBOM.

Jan: And since we're talking about SBOM, we need to make clear what it is and what it isn't.

Jan: In general, you could just think of it like the backside of a bottle of shampoo or something, where you read there's water inside your shampoo, which might be interesting. And all this other great stuff in there.

Jan: You might think of it like a little bit of more information. I mean, water's free. and everybody has it. But an SBOM could also include where the water was sourced from, an SBOM could tell you which license was put on this water and special, or if the water was modified, somehow. Which is usually not a thing for bother, but since we're talking about software, this is a really common practice. There's this one thing that was used in your product software product. And you wonder: where did I get it from? How was it licensed?

Jan: We're not at Software bill of materials at that point, but what I'm talking about or will be talking about is not the how something was manufactured or produced. It's not the information that your water was stewed for like 50 min, or something, or whatever it could be. This would be not software bill of materials. This would be a manufacturing bill of materials, which is yet another talk, maybe.

Jan: And since we are talking about web front-ends in my talk, or I would better say, it's a web deliverable, something that is delivered from the web and run in the web browser, which means, in the end, it runs on a client's hardware somewhere. It runs on clients software.

Jan: This might include security risks, doubts. All the usual legal aspects just like that. And security issues. And since we're talking about web front-ends nowadays, and not like 20 years ago, we have the situation that web front-ends deliverables in general might consist of many, many components that aren't written by you, your company, your organization.

Jan: That might be sourced from externals, maybe trusted sources, maybe sources through trusted channels or untrusted channels. And all these components might be bundled somehow. They might be modified, patched. And in the end these components are usually get meshed up somehow there, processed, compressed, modified, [missed], and everything, by tools like webpack, for example. Which is just one example for a whole family of programs that have the idea to make web deliverables smaller, more ingestable. Adjust, remove parts that you aren't actually relying on.

Jan: And like I already foreshadowed, the reason why we should have SBOM for web deliverables in the first place, to get knowledge about the things that we are actually shipping to web browsers.

Jan: Remember the software that you are shipping is not run on your machine. It's not in the back-end. It's the front-end. It's the client-facing part that's run on client hardware, client software. Maybe in sandboxes somehow.

Jan: But if you have any security issues in that thing, it might not only steal the cookie from your clients, so that credentials are leaked, but it could even break the web browser sandboxes, or modify web requests, that you might not be aware of even. The idea is to get the list of ingredients of your software that you are actually shipping and run an analysis on it like issue or security to find known security issues with those components that you ship, that you actually depended on somehow. Or just to identify that you need to get rid of some supply chain risks. For example, you fetched your whole component set from a public source, maybe it's trusted today, what happens if this trusted source gets tampered with, and you're not actually shipping from it the components that you were using in the past but modified versions in the future? So, to get this information. you could just use your SBOM looked at up, run tools on. It might be safe. So this is posture that you're interested in as the developer of your deliverables.

Jan: But as the person that actually runs the code in their own browsers, they might have an interest on that information, too.

Jan: There comes the question, how does a client site... (where's my slide for that? It's gone)

Jan: There's the question, how does the client site receive an SBOM? This will be the matter of the next upcoming talk. But for now... (and there it is!) here. The next talk will tell us what an SBOM actually... how it could be fetched.

Jan: For now the question, how an SBOM could be generated? You could write that by hand. You might just use a tool if you're using a tool to generate your deliverables in the first place, why not use tool like the CycloneDX webpack plugin for example? That's a tool that hooks into one of these deliverable generators and generates an SBOM alongside.

Jan: That's probably it. Questions from you?