 Good morning. Welcome to our talk bringing service security to a new level in introduction to sass bombs. My name is Rose judge I'm a senior open source engineer at VMware. I work on all things as bombs regret related to tooling Consumption generation and standards. This is my colleague Ivana Atanasova She's also an open source engineer at VMware and she works on all things related to software as a service Bill of materials with respect to standards and security applications So as you've probably Gleaned we're going to cover sass bombs today, but we're going to start at the beginning and we're going to establish what a service is We're going to make sure that we all agree on that understanding so that we can briefly touch on s bombs Before we explore what they might look like when applied to services instead of more traditionally packaged software Then we'll start to cover complexities around sass bombs why they're so hard to generate But also why they're useful how we can use them to secure the software supply chain And then we'll finish by briefly touching on some of the standardization efforts going on around sass bombs And what the future might look like there? And I have a question to the audience. What is the source? No Okay It's an overworld term and this is why Opinions may vary if if you are brave to answer you might give for ten different perspectives of that So it depends on whom you ask so This is why for some people it may be anything that's under a subscription model like The adobe bundle like Photoshop illustrator. Do you have any designers? It can be zoom my crowd or it can be anything that is cloud-based or a storage provider Or it can be one of those things of day-to-day applications that we use as a service like Uber wine Which is not forbidden in many places and any book a doctor applications Or it can be any cyber security protection software that's running on all of our devices And to elaborate more. Yeah, we are going to give some basic examples in more details We know that many websites and web applications use 30 third-party providers to integrate certain functions like authentication payment federated access control and In the example here Hosting service may use the content delivery network, which might In turn use an identity provider integration that can be provided as a service as an option for a consumer of the hosting service Or another example are the cloud services They offer a variety of services depending on how much you would like to offer to them or Or every in every service offering Sustainance of a lot of others more services that are backed up by a lot of Microservices and etc Or there are the clients using third-party services Which can be client applications that use one or more third-party service providers to give value to a customer Or it can be a team client. That is an application that has just enough functionality to access the service API's And we gave so many examples that it's not good to say what's not a service Obviously, it's not a traditional on-premises system software that's installed in organizational Machines hosted somewhere internally. Yeah, it's it cannot be considered a service And also even in the cloud if it's a private cloud if it's customer on We cannot consider its service and to conclude for the purpose of this talk. We will consider a service Software whose deployment management maintenance support and the entire software development Lifecycle is controlled by a supplier. Who is internal to the consuming organization? This is what we will call a service for the purpose of this talk Okay, so if you're at this talk, you probably have some notion of what an SBOM is right in its most rudimentary form We call it the list of ingredients for a piece of software. So a formal record of components for the What's in that software how it was made? If your software artifact is a cookie, it's going to tell you there's a stick of butter in that cookie But hopefully it's also going to tell you where that butter came from. Maybe the store it was purchased at when it was purchased Information related to how the cookie was actually made. What did you bake it at etc? But if we think about this in software terms this list of ingredients is going to contain a handful of things So most importantly Information about the software itself So the software that the SBOM is describing hopefully it has things like the name the version the supplier Maybe the license the checksum information about that software a Software that's any good is also going to contain a list of dependencies So that same set of information but per dependency so license check some name, etc And then it's going to also contain Relationships about those dependencies to other software in the SBOM So maybe that's two other dependencies or to the top level piece of software itself But that's going to help us make that dependency graph. So we kind of understand What this software is built on and then it will also contain hopefully some applicable references So this might be URIs. This may outline known unknowns. This may be references to security information But there will be hopefully some sort of applicable references to give us a whole context picture of What this software is made up of all of this information can be formatted using the two SBOM format so that cyclone DX and spdx the formatting of all of that metadata Of course is the easiest part the hardest part is getting the information Making sure that it's correct But the formatting is an important step because it ensures that all of that metadata is machine readable And interoperable with other tools and then of course this concept of SBOM It's very popular right now right with respect to software supply chain, but also As companies are preparing to meet executive order 1 4 0 2 8 Which is from the US government that says that any vendor selling software to the US government must contain an SBOM for that software Okay, so we know what an SBOM is but Why do we need it and to answer this question we could design an entire session for this we could take a long time to answer it but briefly an SBOM is fundamental to software transparency and Software transparency is important because we know that transparency builds trust Especially now in a time where supply chain attacks are top of mind It's imperative that software producers and consumers can trust the software on which they depend So SBOMs can help build this trust they can highlight precautions that software producers are taking to produce secure quality software and then they can also help Conserve help consumers because they can Be used to validate and verify the software that they receive so trust kind of gets built on both sides of that relationship And SBOMs can also be used for basic software inventory so for security and compliance purposes from a security perspective Having that record of components can help you do things like check for vulnerabilities in your dependencies Maybe when you do that check you avoid using vulnerable components Or maybe you just better manage the risk around those vulnerable components on the license side They can be used to check for compatible licenses In your dependencies so making sure that you're not including restrictive licenses that may affect usage or distribution And then from a supply chain security perspective SBOMs can help us contextualize risk so both around the quality of the components that you're using and their provenance so Ultimately this existence of SBOMs. It doesn't do anything on its own right checking that box really does nothing for you um Maybe it tells you like I have vulnerabilities in my dependencies But having the document doesn't actually remediate those vulnerabilities right actionable policies must be put into place for an SBOM to create actual utility so Maybe that looks like not allowing a container into production with exploitable CVEs Or with certain licenses or maybe you have a policy on a dependencies supplier Or cryptographic signature right the way you implement that policy will be unique and specific to your organization your use cases but In SBOM while it's not the only mechanism you're going to use for security can help put some of those policies into place So can we use SBOMs for services? In their current existence an SBOM defines the software componentry for a fixed software product So when the control of a software product is transferred from vendor to consumer Um, you know the consumer is going to take the SBOM. They're going to ingest it They're going to make some kind of risk calculation Based on what's in that SBOM and then when there's a new version of the software They're going to take that new version of the software that new SBOM do that same risk calculation And make the decision do they update or not and in this current model of that decision To ingest that updated software is the responsibility of the customer right presumably based on their contextualization of risk Based on what's in the SBOM, but in contrast with SAS systems We have a model where SAS software or the system that the SAS software runs on It's frequently changing right and the change is outside the control of and oftentimes not even visible to the customer excuse me, so SAS systems are continuously deployed potentially updated multiple times a day multiple times a week a month whatever it is But the consumer would need to continually pull for that SBOM to Decide if they want to run that version which they actually have no control over so they don't really have a choice There's kind of this assumed trust from the consumer to the provider Um, additionally the boundary for what makes up a SAS system is not as intrinsically defined as a neatly packaged software product Right where the boundary is a little more clear um So to answer the question using SBOM to describe a service It's a good start, but it's missing context right missing information about the deployment of the software the service dependencies Maybe the device information More services hosted or other off-premise concerns So the conceptual basis of an SBOM, which is that it's a concrete set of metadata Describing a piece of software It's a building block towards describing SAS, but we need a better framework than what's currently available to accurately do this So if SBOMs don't cover everything we need to describe services What can we use instead and you're all very smart? I'm sure you can guess the answer is SAS bombs But what are SAS bombs exactly? Yeah, what is a SAS bomb? I'm sure that most people came here for this question And the truth is that opinions vary yet There are various ideas about it And I will stick to roles analogy with uh the ingredients list so I may say that SAS bomb is something describing this You have the food content inside and you have the ingredients list for everything inside the vending machine There's nothing there But is it enough to know that this vending machine is secure? Probably you want to know that when you pay with a cart Your data will not be stolen and you won't be robbed and you want to know which provider stands behind that payment We will be able to pay with cash or with cart if you pay with cash, we will receive your return And if you select for example number 42, we will receive it or 36 We will be hit by electricity and et cetera so SAS bombs should describe the whole system as it is And of course, it's a snapshot of the s bombs inside the SAS system because you know You need to know the ingredients list for everything that's inside But that's not enough. You also need the service specific data This is a service identifier. That should be unique. It can be service endpoint your real pearl and et cetera You need a unique identifier of the provider which can be google alphabet google apis.com and et cetera And you need to know the service functions. They can be identity, identification certificate authority, law balancing, et cetera You also want to know the geographical locations As not being the host, you might be interested Where the service is actually running And you may need to know any communication protocols that are used by the service instance Like for example, does it rely on HTTP or HTTPS or does it use MQTT and et cetera You also want to know the service status Which is showing uptime information. You want to know how reliable it is And it's about the service, but there is something more because here you buy something externally, but Usually with services, it's your data there. So you're interested what's going on with the data You want to know the data flow and exactly where your data is going through which services Have access to it. So is this access violated, et cetera And you would also like to know the data classification, whether it's confidential, public, private, et cetera So let's give up some concluded comparison to ASPOM and SASPOM Okay, so it's important to remember that SAS is not customer managed, right? It's managed by the provider So therefore an ASPOM is customer managed Meaning that, you know, the customer receives the ASPOM makes decisions about how to use the software based on what's in there And that ASPOM describes a single deliberate artifact with a very clear boundary of where the software begins and ends You can think of an ASPOM as describing really the what of a piece of software Yeah, while on the other side Services are usually frequently changing They are dynamic You have frequent deployments and as we Defined in the beginning what we will consider service. They are fully provider managed So SASPOM snapshots all that dynamics So it's a bit complicated to provide all that frequent information And it's more focused on how and what, like in our Linux machine examples, the ASPOMs are What's inside while the SASPOM says how do you how you receive it and where it's located So ultimately a SASPOM and ASPOM, they're similar, right? They're similar in the sense that they're both describing software And they're communicating metadata around what's in it in a structured way But SASPOMs are describing the complexity of the how and the where What, you know, like things a combination of infrastructure software components service endpoints and the data flow between services ASPOM is more describing what's in that piece of software, which makes up the SAS And we talked about what is a SASPOM? Now let's talk about who uses SASPOM Yeah, to be honest Let's say that it's nobody at scale yet because there are some usages It's only available in some form in second dex has one to many relationship Between deployment information and the corresponding ASPOMs But think of where we are with ASPOMs with SASPOMs. We are further behind So taking into account that the concept of SASPOM and service transparency is in the process of building at the moment And the tooling is a work in progress. So we hope that it's going to be in the nearest future We'd rather focus on the conceptual point of view who is interested Interested consumer of that transparency information And we can define for interested parties at this We have the service provider Which might need that information for private compliance needs and for security response We have the end consumer who would need to prove that their data is well secured and that the service is reliable And we have the intermediate service provider, which Can need that data both from the side of service provider and And then we also have the compliance auditors. We all love them They They can access to internal service provider information or they can be considered fully external depending on the contract and what their role is And we said what is SASPOM? We said who's interested in using SASPOM? Now let's say why it's hard to create SASPOMs All the complexities are consequence of the specifics of SAS And first we have to have an infrastructure That's capable of collecting the necessary information And in some use cases it might be really hard to gather all of that We also Need to keep from up to date snapshot of our runtime system, which is also a complex problem. It's more to an observability problem And we also have The leading best to share That's a provider want to expose all that information and to risk their privacy And of course we have those privacy and intellectual property considerations that fall from SASPOMs Because so with it you reveal part of your architecture and your ideas behind our service Which might be under intellectual property So This is why in SASPOMs, especially in the SPX service profile, we separated that to internal and shared information So that you can have information that's more complete, that's for internal use cases, and you might classify it on whether you'd like to share with external organizations or not, and you could consider compliance auditor Capable of receiving such information or not, but you have those two levels of protections. It can be classified under that You will have the interested partners and we have that we can share information depending on what the interested part is It's not necessary to share it to everyone and we need to be business protective at this because It's all about the business identity, about the people using that business, and we don't want to ruin that with Breaking our all-day business privacy, we want to be business protective And let's come to the key point Okay, so You know, we can say the S in SASPOM stands for security As Ivana touched on creating a SASPOM is no simple task, right? Many hurdles lie in the way to doing that. So what is the point? Why is there so much community effort around this and why do we care? And most importantly, how can we use SASPOMs for security applications? And the answer is not much different from how we use S-BOMs for security applications for non-SAS software So assuming you have an accurate and complete SASPOM, which we've already acknowledged doesn't really exist today It's very challenging to do You can use the SASPOM for things like software transparency, which we know builds trust between providers and consumers You can use it to build policy the same way you would for an S-BOM So if the same way you'd say, you know, we don't run software that contains X dependency for SAS Maybe that policy is something like we don't accept services hosted in a certain country or services without a certain availability guarantee SASPOMs can also be used for Security to determine a vulnerability's applicability like does this service container dependency That has this exploitable CVE has the CVE been remediated in the software Kind of the same way you would for an S-BOM, but the concept is the same where if you don't know what's in your software You can't even start to make those risk calculations until you actually inventory it And then SASPOMs can also be used for things like security audits compliance audits large SAS companies have a financial interest in making sure that the data on their SAS platforms remains safe secure and private In order to protect their customers protect their own business And one way to make this guarantee is to regularly perform internal security audits SASPOMs are going to contain metadata that can help them do that Customers also have an interest in their privacy and their data and the security around their data So using SASPOMs to perform external security audits is also Something that they can do along with compliance For security and other legal matters Okay, so S-BOM sophistication A rise in microservices and SAS products It's all brought about a need to better document The metadata which represents this SAS software and we've really seen open source communities rise to this challenge Especially around standardizing formatting And kind of defining the terminology we use to talk about SAS So there's kind of three main efforts here worth highlighting The cyber security and infrastructure security agency, which most refer to as CISA. That's a US government agency It's been hosting bi-weekly meetings with anyone who's interested in this to define what transparency looks like around SAS and S-BOMs S-PDX is working on a profile for SAS services and their 3.1 specification for how to communicate this metadata And then Cyclone DX has a SAS BOM standard that complements their BOM standard Let's say a few words about the CISA working group It mainly focuses on integrating the current understanding of S-BOMs in the context of online applications and cloud services And as part of that it's exploring the needs and use cases in about S-BOMs in modern applications It's also exploring the potential value of extending the software transparency model to cloud and service transparency and service infrastructure And it's defining a model of transparencies for services to track the transitive graph of online applications and the use of third-party services as well And it's preparing an advisory without that Okay, so S-PDX They're one of the two S-BOM format standards They're developing a SAS profile in alignment with the work coming out of CISA this profile aims to support and track popular SAS use cases and in alignment with CISA it'll meet any government regulations that come from the U.S. government or other governments with regard to SAS BOMs So the profile kind of spans three primary service categories customer data governance So this is going to include metadata like data classification geographic location of the service data retention Things like that. The second is supplier infrastructure governance This is going to contain dependency relationships, you know fourth-party service providers protocols that the services use service availability vulnerability discovery and management and then regulatory compliance which will be like You know restrictions around geographic and cryptographic export controls So this is actively under development. It meets every other Monday In the morning pacific standard time, but all the meeting minutes are posted So if you're interested in getting started, you can always subscribe to those You'll probably see Yvonne and myself there and then CyclinDX the other S-BOM standard has a SAS profile which Compliments their BOM standard. So in the way, you know the way they approach SAS BOMs is to kind of separate SAS and S-BOMs Given that SAS is more dynamic. It's more likely to change. S-BOMs are more Set in stone and typically will remain more static. So Uh, their approach is you know the one to many relationship that Yvonne talked about So one SAS BOM to many S-BOMs describing the components which make up that SAS and then the SAS BOM having extra contextual information about the service itself If you choose not to do it this way, they also support embedding all the service information in their BOM standard Should you need that use case? And what's next? We have the SISO working group. As we said, it's preparing an advisory about software transparency in SAS environments. We hope that it will be already soon so that There will be official definition of what we talked about There is the service SAS profile in SPDX which is coming with 3.0 So hopefully in that one And of course It's nothing without the tooling that uses this and that consumes this afterwards so that can produce so It's a big gap actually at the moment because so we have S-BOM Producing tools we have observability tools, but we don't have any integration between both and given that SAS BOMs capture Runtime system I think that the future is some integration with the observability solutions And then it cannot be integrated with security solutions It's a whole gap and we need that we hope that efforts will start in that area because it's the next important thing cybersecurity and services Yeah, so lots of progress has been made up until this point, but like anything in open source there's always lots more work to do so you know the solutions that we develop around SAS benefit from a collection of perspectives So if SAS BOMs apply to the work you do or your company does We really encourage you to get involved to reach out Tell us, you know, what are your biggest issues? What are your biggest concerns? What are your needs regarding SAS BOMs and service transparency? You can subscribe to the SISA Working group if you want to receive more information you can access the SPDX service feeds or you can reach out For any information. Yeah, we would be really happy to follow up Yep And if you have questions now, we'll attempt to answer this Do we need a mic? I'm loud. Okay. I'll just speak right now. All right. Thank you ladies excellent presentation I'm so glad some of the time you're focusing on this area I have two questions one hard and one hopefully the soft one. Okay, start with the hard one So a rise of attacks in hyperscale environments like the cloud Is container to be in a space? So are you doing any work around We've created a SAS BOM for the whole system So that a hyperscaler or forensic investigator could go through and understand that there was a dependency on an untrusted tenant running on the same resource Actually, it's uh, there is part of that data plan to be included in the SPDX profile including all the logs that usually serve for use those use cases especially for security response. So Uh, it's one of the things that are planned to be included We'll see when the first version of the profile comes out We're not sure that everything will be within the first version because there are complexities in creating the metadata But it's planned for sure and if not with 3.1 it will surely be with in the spdx profile and In the size of working group actually The group didn't reach to cyber security yet. So I hope that those sections of the advisory will come sooner So we don't have any recommendations there, but with the service profile it's planned to be there Yeah Is there a Actually, there is one group that one weekly group every Friday morning. I'm not sure what pacific time is for me 7 p.m Yeah, and it's about service transparency and SAS and everything that's related is in this group While the b-weekly group is more general I imagine it through the S bombs that are snapshoted But regarding the service itself, there is no database service vulnerability database existing. So At the moment, it's very far from having something like the effects for services I really hope that some effort in that direction will be formed, but for the moment, it's all all Results to the s bombs and the related external references to vex there I would envision the link happening like from vex back to the sbomb or this sbomb like instead of having to update these sbombs each time you have a new vex document to reference like having And I think I've opened an issue for this in open vex, but having that reference for back to the sbomb where there's some sort of URI that you can associate and I think the system for how you'd actually do that Would probably be implemented like within an organization or a company. I don't know if they would be like an open source solution But yeah, some sort of like correlation that keeps track of Um, I don't I think ideally with vex like having some sort of feed would be helpful Like if you did have a pointer from an sbomb like just having a feed Like an rss view that could just regularly update with like the updated vex information, but I don't think we're there as a industry Any other questions About So at least with spdx they the profile The profiles there's an ai and data set profile. So I would see that working You know with the sass profile um to kind of separate out that information, but then having references to the elements within those documents between their kind of Contained namespace of types of information But beyond that I haven't I haven't considered it So you sure Yes Certainly Yeah Yeah, so spdx is working on like full system traceability all the way down to the hardware. They're starting a hardware profile to model that so Yeah, kind of separating them out into categories that all can represent a holistic system