 Okay, I guess I'm good to go. Good afternoon, everyone. Welcome to my session. We're going to talk a lot of ESPAM, and I'm Hasan Yassar. I'm a technical director and also faculty member at the Carnegie Mellon University. I have two jobs. One job is being a faculty member at the Carnegie Mellon University, is teaching a course in a graduate level on DevOps course since 2013. Also, I'm a technical director on the Software Engineering Institute. If anybody knows the CMMI all days, probably some of you, yeah. It was created from SCI, but we are not supporting anymore, so we are kind of drop the ball. We said, let's get better out of it. Now, when I really started my journey at the Carnegie Mellon about 15 years ago, almost, and I really tried to bring about the engineering practices. I know SCI is known as Engineering Practices as FFRDC, which is a federal fund research lab under OST, Secretary of Defense under DOD, but we have under CMU as focusing more engineering practices. So I manage the group, does DevOps and DevSecOps agile practices in supporting many DOD programs, as well as in supporting industry, which this morning with the DevSecOps days, and Kate was one of my speaker, we have been supporting community on DevSecOps perspective as well. So let's talk about what it is, SBOM, and I really would like to get you guys think about what is the actionable stuff that we can do for SBOM. I know we heard a lot of SBOM, be no problem, be no SBOM, right? I think everybody saw the SBOM file. Anybody have not seen SBOM file yet? Not yet? Okay, not shame, I'll show you a couple of examples, don't worry. All right, so I really would like to talk about what is the actionable stuff on SBOM, what we can do. This is my kind of a legal SBOM what you see here, what the legal says, put something as a legal disclaimer who we are, what things we do, which is one, two, three, that's it, we are done. We verify it. All right, next step. I know, anybody knows what this picture about it? Any ideas? Which is yesterday's enterprise? I'll give a sticker, but I can give some bonus later on maybe. Anybody knows which city it is? It's Pittsburgh, yes, it's a Pittsburgh. It's about a hundred years ago. Why I brought that topic is it really thinks it's evolving. In yesterday's enterprise, Pittsburgh is known about the steel industry. It's not the steelers, anybody in fan of steelers? Probably yes, but it is known about the steel manufacturing. Now it got changed. So it's more about building supply chain with respect to the steelers and everything else still and all this technology and stuff, but it got evolved. Now where we are today, we are more about the complex. Now comparing with the shiny Pittsburgh right here, got evolved, it's keep changing. And also as a parallel, we see a lot of complexity on the aircraft, anywhere else. It's becoming a very, very, very complex problem, which we all don't know about it. Either in industry or using any type of technology. I would like you guys to remember these pieces a lot because I'm going to reference more into the, how the industry with respect to the manufacturing and into like a construction business or electric business is changing, why the software is not as evolving as manufacturing and the certain components, right? And other things I would like to brought up this one. I know you all know about the software, is it in the world? But the one thing is really, I would like to highlight here, this sentence is really interesting because this actually came from an FAA as an autumn. It says like, you really think about a software now it is becoming a safety problem. Because if you don't really update your libraries, if you don't maintain your software, if you don't really follow what the software is designed, it's affecting our human life now, which is very, very important. I thought we talk about like kind of what about the daily life? It's not a daily life anymore as we are using an application, it's affecting our life, which is one example. There are a lot of examples we can give how the software is affecting our human. It's gonna get even worse, I'll tell you. It's gonna get even difficult, even worse, how it's affecting our safety, our life. Now a lot of things is basically in the healthcare industry, we are depend on it using a lot of softwares and some of the doctors are doing remote operations. You wanna be a patient that's doctor with remote operation on you through the internet? I don't know. I don't wanna be that proud and it's scary. So let's move on. Actually, I prepped this slide about why is important to us, why matter to us. That number's got outdated already within a week. Within a week literally, now we have more percentage on the per commercial code and other things is keep increasing. So now the numbers keep increasing. These numbers I use based on the software supply chain report everything as it's keeping increasing. Which is we heard like yesterday, the number got bigger and I'm sure next couple months it's gonna get even bigger. So now it's growing, right? It's really growing. We cannot really stop that things anymore. But why is important to me? I would like to get you guys in the next one is why does that matter? It's about the dollar associated, okay? So one is about the growing but what is impacting to us? We know the safety is one problem. The second important one is about the business aspect of it. What does business means like? What is the dollar we are spending at time? This is one of the example actually true example I supported when the look for J happened. I was supporting one of the organizations to tell and find out are we really affected for look for J? And I will spend like a quick, this is not a big enterprise organization I'm talking about a small organization somewhere in Pittsburgh literally spent almost 900K to find out do we really have a look for J or not? This is really interesting like there's a money associated now. Finding out do we really have a look for J which is one element. Second one is yes we have a look for J but are we really compromised? Which is the impact out of it? Which is the typical financial risk can be a 5.7 million. It's like little things how much is affecting to us as the financial perspective? That's another elements of the security with S-Bombative Business Association. Like there's a safety and at the same time there's a business dollar we have to spend we have to be aware of it. Which is your return of investment? Such as one, libraries. Think about the scale that we had here about the percentage code base and the commercial percentage. Think about the one look for J. Now calculate your dependencies how much money you are dealing about it. Either finding the problems. Now I'm not talking about the solution yet just finding the problem are we affected or not? Do we have the right libraries or not? Second is fixing which is the risk. That's reason our finance people are managers they don't pay enough attention. Who are the managers in this group? Who are the finance person? Anybody has the director or VP? Who are responsible for the finance? Right? That's kind of a mindset our business they're looking for about the business and money perspective. That's your return of investments. Tell the people this is a true story how much money we are saving by spending time. They may say to you why are we gonna buy the tools? Why are we gonna spend the time? Yeah, because you're saving the time at the end of the day about finding the problems. That's one element, that's more, right? Another interesting things I would like to highlight here not adversaries are really attacking our software development and wire elements. This is not the new honestly. The paper was written as a story I really like to just take a look later on. Trusting the trust is really interesting like yes, I'm a developer's. How much I can trust on somebody else's code? Ask yourself, even though you're in the same organization you are writing a code, if you don't know enough about somebody else's code, you don't wanna trust. How are you gonna trust the code? Can somebody tell them how are you gonna trust the code? Even though your friend is writing the code how are you gonna trust the code? Anybody has an idea? Yeah. Sacred analysis, one elements, what else? Requirements, open up a little bit more. Architecture, look, when you look at somebody else's code even though sometimes I'm music with music maybe I'm kind of failing, look at my code if I wrote a six months ago. How can I trust my own code when I wrote a six month ago? I need to know about some information about the code. I have to have some notes in my code because how I write the code six months ago have a different mindset, different context now I have different context. So really trust is becoming a very, very important factor. Now taking that concept put into the adversaries now they are using a lot of trust relation the code at the writing, it's affecting our life. It's becoming an impossible to deck any micro bug in the code. What the micro bug means like the code does it's supposed to do but at the same time malicious people are inserting something into the code. Your code is really working what it's supposed to be but there is some behind the scene it's happening we don't know. Hard to check those configurations, it's very hard. So what are you gonna do now, right? That's the thing we are talking about the software of materials. Let's go on the next one. And other things I would like to highlight one important factor is we typically know our endpoint let's say we are looking for some of the components but how much do we know other people are dependent on other libraries? Like we are acquiring a software maybe we are using a software, we are using a binaries maybe libraries but the library is built on somebody else's code. We are getting a compiler version of it let's say if you get in a C++ you're getting a compiler version there's a DLL in it, you see the binaries. You see the first hand but you don't know what is really behind it, which is another complexity. Dependence is playing a key role for us we know what we know based on what we compile but we don't know what is really behind it. What is really telling me as a story this is basically a college part is becoming right? Now this portion is getting very less the code that we write that we wrote it's getting lesser and lesser and lesser. Because when I look at myself, my journey when I start to write the code about 20 years ago we were about to write a whole stack from up level. Now with the frameworks, with the new technologies with the new concept we are writing very, very small code pieces. Statistically when we look at the new way of writing the code almost 15, 20% is actually the developer writing the code. More than 80% really comes from the framework. And I actually experiment with my students I said can somebody write me a Hello World in the web page? They said okay, five minutes, here's a Hello World of the web page. What they did, they used the multiple stack behind the scene using operating system using the web server using the framework very easy to write the Hello World but dependencies are so deep operating system level web services framework. Like the code is very one line of the code but the dependency is really huge. That's becoming a college party, right? So how can we really fix that problem as it being not a college party means that we invite the one person suddenly 100 people are showing your house. We have a capacity to analyze everybody who is in our art, we don't, right? That's the problem that we are dealing. Let's move on. And other things that I would like to get into the more actionable, more reality pieces. Is S-Bomb is all about creating the file with the tools? Who says yes, no? No, we're just creating a file, that's okay, we're gonna create it. But what is important pieces that makes actionable S-Bomb file? That's really a key point. That's reality, it's making action because how are we gonna deal the problem at college party situation or dealing with other dependencies or our connectivity, it's really requiring to think about beyond the creating of S-Bomb files. So what are we going to do now? Let's spend a little bit about the goal. What is our goal? And I would like to really think about for you guys for OSP top 10, which is NIV 2021. When you look at OSP top 10, here's our goal. It doesn't matter which organization you are in. Our goal is to really build up a secure design, develop and deploy into the secure infrastructure. That's what we are trying to do. With that perspective, I'm glad that final OSP is listing insecure design as the one of the top 10 vulnerability this year. What that's really telling us, we have to think about security as part of our designing. We don't wanna be as reactive based on what we are finding. We have to be more proactive. How can we be proactive? We're gonna think about the design element at the beginning. And other things that are interesting about the software data integrity. How are we gonna keep the integrity of the file that we are using? It's the same file that we are using in our build, deploy and delivery. So think about that perspective. Here's the relationship of your goals. And other things then we can talk about how pieces. Anybody heard about DevOps and DevSecOps? Some of you probably. So now here's my solution, which I have been teaching at the class and I have been supporting many of the other programs. This is kind of how you start thinking about DevOps and DevSecOps perspective. Honestly, DevSecOps is more about people start to ignore the sec pieces. So we start to call up about the DevSecOps. If we are doing the right DevOps, we don't need DevSecOps. We don't do the right DevOps. Now we are saying DevSecOps because we ignore the security. Why ignore the security? Because we never address the design properly at the beginning. We never think about the early stage of security and now DevOps is creating so much buggy code, so much problem. We said, hey, this is not going to work out. Let's build up the security as part of our practices. So let's move on to a little bit on the DevSecOps spaces so we can connect the dot with the S-bomb relationship with the DevSecOps because always we're asking what is actionable and how can I solve this problem? This is the question that we are trying to find the solution. And other things I would like to highlight here is the DevSecOps goal. There's three main goals DevSecOps would like to achieve. One is the business mission. So that goes back to our analysis. How much money we would like to spend to fix any issues? How much value we are bringing to the user? So it's more about the business driven. If you really separate the S-bomb or a secured outside your business, you're not able to achieve the goal of DevSecOps. It's based on the business, based on the value, based on the impact, which is the first elements. Because if we don't want to be creating a software has no value. Think about your organization. The value is really how you're using an infrastructure that you may have in internally or how you're supporting your clients. If there is no income, who is going to support you? Reality, right? Which is the business mission. Second one is goes back to the deliver of capable and delivering a value, which is really for your business mission and related to your value. So now think about S-bomb perspective every time when I say any word, think about what is it here for me as an S-bomb thinking, right? Now we can put into the reasoning your product then you can deliver as end of the product. So what the product means basically we are creating an infrastructure, that infrastructure that makes you go from beginning to end adding all the capable and as you can deliver the business value, business mission based on your CI-CD pipelines. That's connected up. What is the sec and DevSecOps with S-bomb together? Let me finish up everything here, we can talk about it now. So if you look at that perspective, this is a typical DevSecOps life cycle. As you can see, there are many places that we can create other dependencies, our S-bomb files like starting from test, build, code. Every phase technically generating some sort of an S-bomb or a related dependencies, we can capture it. Here's your bumper sticker. S-bomb should be integrated into the SDLC which is software development life cycle should be your integration. If you look at the fact as creating the end to end it's too late. What we should do really think about from planning perspective. So I'm gonna show you an example of Kate and she's talking a lot of the SPDX, how to cycle index, we're gonna connect the dots. But really think about SDLC perspective that's your actionable stuff. You may say, I'm not really building a software. Maybe I'm a consumer. Still you are practicing some of the deployments. Like think about enterprise organization you are in. You may not be delivering or building a software but using a lot of CM practices. CM is configuration management. Maybe using some other Chef Puppet for your deployments. Are you looking for dependencies of Chef Puppet how they are creating the provisioning script? How you're getting dependencies and stuff? That goes back to your planning phases again. So you're kind of practicing all the in your enterprise organization even though you're not building a software you are practicing, you're not aware of it. But you are practicing already. So whatever you do in your organization you have to think about every phase of life cycle. Just like we can go over all of them but every base is creating some sort of infrastructure pieces for us. That's your go to place. What is our purpose again? Our purpose is really use those file how we create it. Let's try to verify and validate and test it. How we creating the file. How we start at the beginning as creating one of the dependencies here in the code. We have to make sure that we are validating which goes back to the we're gonna trust the developer. We're gonna make sure that people aren't inserting any new files into the process which happen a lot. As a developer if I am stuck in one of the code that is not working what I'm going to do grab a new version of it. I'm gonna get a new version or maybe change something without alerting anybody. How are we gonna catch those alert? We have to really verify through the life cycle to make sure that you are getting right libraries, light files and you're verifying those components. All right, let's think about how can I start? Anybody in the question so far? Good. Okay, you can challenge me. If I'm wrong, tell me. If we are, tell me again. Let's have more of a conversation. I really like that conversational stuff. If you want to ask me a question, I will ask a question to you. Right? Okay, let's move on. I know everybody heard about S1. I'm just gonna go quickly. There are multiple ver like the format types that exist all the cycle index, SPDX. I'm assuming that you all know about it. If you haven't seen that, I'm gonna show an example what the file looks like. There's all that available. But the one thing is important. There are common software below elements that exist already. And other things is important. MyTang language is machine readable format. Doesn't matter which one you're picking it. I favored SPDX, which new version is much better. But it's end of this machine readable. Don't really stuck on the one file. Make sure that put something into your infrastructure. Make sure that you're able to follow it based on DevSecOps practice. And let's look at closer what those files looks like, what the minimum elements looks like, okay? I added another column here, which came from the actual, I use the NTIA. These are the data field and description as minimum elements of SPA. How are we gonna create those? How can I maintain those? You will see a lot of relationship in your software development lifecycle, DevSecOps, the creating those data elements. If you're talking about the supplier name, there you can really get issue tracking or version control systems or IAC, which is infrastructure as a code, you really keep track those data elements, all that exists. If anybody's practicing DevOps, if anybody practicing modern deployment, they all are to have IAC script. They all are to have the deployment scripts. If you look at the deployment scripts, if you look at infrastructure as a code, either Terraform or Vagrants or Enosable or Chef, there is already name in it. The file name is all that exists. So don't really challenge yourself. It is very difficult to create it. It's there already. It's all that the part of the script. We never able to think, what is the SPAM creations? When we look at the component name, we can use issue tracking. When we look at the version, which is build and packaging we can do. When we get into the more about the dependency relationship, we have a project. Every repository management, it's based on the project. If you go to the GitHub or GitLab, whatever repository management you're using it, you're creating a project. Each of the project should have a bill of materials as part of the project file together. Now we can see the dependencies each other. You download it, but keeping the SPAM is separate in your repository, we're gonna solve the problem. So as you can see all of the data elements has a representation in your software life cycle. Again, you may, I'm not using a software life cycle, still you have a CM practice you follow in your organizations. You have repository management for your admissible, for your chef, for your puppet. It is already using some sort of a version controlling an environment, keep track all the dependencies for you. Let's look at a different perspective, which is another one I like it that came from NTA again. What are the minimum practices? So you finish up the data fields, which we discussed shortly. We're gonna talk about the different type of SPAM shortly like that design, source build, analyze the deploy in a runtime, which I'm assuming that you build up your deployment. Now, how can I do and creating automation which is a key point? Now go back to the practice. How can I create those SPAM files using automation? How are we gonna use automation? You have to use the continuous integration, continuous delivery, continuous deployment IAC. That's your solution. And I'm gonna make a demo by David. I will show you how it's easy to use as pipeline, create those files. Because one of the question I have been asked many times, even though when I teach the class from developer perspective, they're saying, do I have to create all these files manually? Do I have to build up all the field manually? Oh my God, I have to learn all these things? No, you don't need to. This is the format to communicate each other's. That's how we are communicating. That's how we are sharing information between suppliers, vendors, developers and tools. But the key point is that we use those automation to create that concept. Every tool, either SBDX or Cyclone or SWID, it is already available that you can use. You can generate those. Even though if there is no tools available for you as a developers, you can write it. This is not a kind of typical things that it's gonna be difficult to do that. It's just basic XML YAML file that you're gonna create it. Format is exist. But we are making so scary to people not to use it. Don't do that. It's easy. I'm honest, I'm telling you it's easy, okay? So put your perception down. Say, how can I do that? What can I do my job to make it easier? Let's move on. When we look at the practices here, that's really a tough part honestly. Which we're gonna follow the policy governance education. Now that's a difficult part. Why is difficult? You know what's an idea? People are really hard. Why? They don't wanna change themself. There's another reason it's actually culture. Because why they don't wanna change themself? Because they don't wanna be showing some power loss or maybe sampling a power game or they don't wanna show some other things how they do. If it says the developers, hey, can you show me how you do? Most of the developers they don't wanna share how they do. Why? Because they are kind of scaring to lose their job. That's the reality. They don't wanna share it. It's about the culture. Why? Because the managers are evaluating or incentivize the person different perspective. So what we can do now? Really build up a policy. We build up a governance. We have to promote engineering. We have to promote engineer, developer, or architects to follow the organizational pastures and policy guidance. That's your difficult part. Let me give an example. I may know every dependency in my code if somebody is using a code snippet from Stack Overflow. Is the policy problem in education or as found creations? What is that? It's a policy problem. Because developer wants to solve a solution, right? Right away. Go to Stack Overflow copy and paste, they use it in libraries. So we don't wanna really block the developer but somehow we have to make them enable let them do their job. Now as a manager we have to find a way to solve that problem. That goes back to the really building up of some governance pieces, building up some policy pieces. Educate your developers. It is, it's a balance honestly Camden. I don't wanna enforce basically everybody who has to follow but we have to get some freedom. People can follow based on certain guidelines and guard rails. So we can enforce in a policy, not penalizing the people, we can enforce the policy, improve our practices. That should be our perspective. So maybe we can say, hey developers, like I heard some example, like we will lack the luck on everything. It's a bad policy. Because if you luck on everything, developer has no right to do anything else. What they gonna do, they will do some other things. Because there is a pressure from our finance people, they will like to get job done as quick as possible. Here's another note for all of you. I have been running DevSecOps survey for a couple of years. I asked the question for developers, what the security matter to you? Why you're not addressing the security? 99% of the developers are believing the security, but they didn't have enough time to address the security. Why didn't have enough time? Because the bosses or managers or the customer asking, get me that feature for me in a short time from I need yesterday. So now if you put the policy to block the developers, there's another pressure. On the other hand, developers are gonna find a way to break the policies. So we have to find a balance. Another one is about education is really a key point. All right, let's move on. This is another example to tell, show you here is the comparison between SBDX cycle and SWDC, it's kind of similar it is. And as I said, like version of the relationship is a key point to connect the dots in between. Again, this is one example to see as how what SBAN looks like, right? All right, so what we're gonna do as the continuation of the journey, we're gonna start from infrastructure perspective. Now, forget everything else in a moment. When you are building your infrastructure, we have to make sure that the infrastructure is secure enough. One of the big problem I have been hearing as a vendor, they don't wanna share the SBAN files. Why? Because they don't trust you as an organization. How are we gonna protect their files? Because you technically, they are sharing with you as their secret in terms of their dependency looks like. So why is it important to protect the SBAN file that vendor is sharing with you? Why matters? There's an idea? For what purpose I can use? I said that information is useful for attackers because if they know what you're depending on, they know all the different avenues to exploit you. Great, thank you. If you look at like a pentester, what is the first step of pentester? There's some reconnaissance, right? Which they're gonna look at what the dependencies are. They're gonna find out how you build it. If they know your ingredients, they're gonna look at the CV's website. They're gonna get the vulnerability that is attack your system. Now, if you're an organization, you have to protect your assets. You have to protect it. How are we gonna protect? You're gonna build up a second infrastructure. So when you build up a second infrastructure, you're gonna build up everything in a single source code repository, which is important. I see so many people are creating multiple, multiple repositories. Do I need it? I should have a single repository so I can control it. Again, I'm a fan of us having a single repo, but creating a multiple repositories, creating another attack vector for you. How you're creating the pipeline to build it, it depends on your language, but end of the day code is a code. Doesn't matter where it is. If it's a single code repository, it's a source of truth, you have a full control of what's going on in this example, right? But you can add other components like a build, documentation, integration. You can insert other type of practices as we discussed so far, right? Now what you're gonna do is the next step, you build up your infrastructure and start to build up your dependencies in minimum three phases. In your code developments you can do, you can do the build process, you can do the deployment process. Now you can use continuous integration, you can build up infrastructure as a code, easily can build up the three steps to achieve your minimum requirements. What was the minimum requirements? Get the minimum fields. Where you can do minimum fields, you can from get code developments, build and run time. Like easily when you put the code commit into the GitHub repositories or any repositories, you can really, the composition analysis at the moment, you can create a first as from right away in the code commit. When you try to build it, which is interesting, every automation build has the build manifestos. Either using a make files as the C++ or maybe creating a Gradle script, maybe you're creating a package in your MPM, maybe you're creating a jar file, all of them has build manifestos in it. What the build manifesto means, which is automations. If you look at automation script, then you can capture your build dependencies. When you try to deploy it, now you can capture your runtime dependencies. What is runtime dependencies, which is your infrastructure script that you're deploying? Your Ansible has the runtime dependencies. Your Chef has the runtime dependencies. You all have the habit. So how are you gonna generate those files from your script that you can generate it? Let's put all together in a policy with the deployment perspective. One, you have to put a policy into your acceptance, like acceptance means we're gonna put some policy to mandate engineer or developers. Make sure that they're alerting the people or asking the permissions or following the policies, getting libraries. There's a legal element of applying the policies at the same time for a security perspective. We're gonna think about both. Now SBDX3 has a legal profile so we can keep track. Do we have a right to use those libraries? Can we make sure that we have a right? Are we paying enough licensing? Which is a very, very big problem that we have to keep track of licensing perspective. Of course, back to the policy, you should follow it. Now we can do basically some dependency analysis based on what you would like to do for completion analysis. Now jump into the CICD practices. You can integrate into your continuous integration. You can do the compliance artifact. You can do the deployment artifact, which is the operational pieces of creating an Aspire. Are we good so far? Are you guys convinced it's easy or difficult? Looks like easy, maybe. But what I'm saying is all that exists are available, all right? So what we can do overall as the quick summary, we can integrate our artifact catalog into our lifecycle and we can automate the script. We can generate a spam file every steps. Then we can monitor it. So everything what we can do, which basically creates some vetting process into our infrastructure, we can monitor it, we can verify it, we can validate it. It's simple, it's doable. If you really think about how I'm gonna create an Aspire, you're not following the right things. You're gonna think about how can I spread it throughout the lifecycle. Another thing that's important with the secretive perspective, we always thinking as reactive, we're gonna change that. Why? Either you're gonna pay tax at the end of your delivery, which is kind of a month, a year later, or you're gonna pay the tax as you are building. Paying a tax or doing some of your duties as you are building is much easier, versus doing it at the end is much difficult because it's gonna cost you more money. That's what we would like to do as early integrations. So now I'm gonna show some quick actions in Aspire, which is a demo pieces. This is the example for you to see how it is easy to create it. And this is a basically one project and based on the rest, I'm gonna show an example short, I'm gonna go a little bit background. The Rust code contains some vulnerability in it that what we're going to do, we're gonna process a build project, we're gonna execute the check of the code, we're gonna do some external libraries, this is the basic applications. And we have a pipeline, that pipeline does the static analysis, build the code, package it, generate Aspire, upload artifacts, scan Aspire to verify, and then make sure that we are following the writings in Aspire perspective. And let me go to demo and then we're gonna come back to shortly again. Let's go to demo first. Let's go right here. All right, this is the one exemplar project. Oops. And using a GitLab runner, I'm gonna show you one example. Again, this is just basically do some lin check. And I'm gonna start the build right here. Go to pipelines. And it's using a GitLab, GitLab runner behind the scene. GitLab runners created, was failed, but we can start again, run pipeline. While it is working, I'm gonna show example as the done. Let's go back here. So does the lin check, do some static analysis code pieces based on the code perspective. And creating a package, this is building, let's go open up each of them components. It's already done, but we show you how it is going behind the scene. Again, the Rust application. So to really build up the Rust, you need some packaging. So packaging tools comes from the cargo, which is I'm using a packaging tools. What it will tell me every application that language that you may have, language you have to package it, or you have to compile. That's what the CI practice looks like. If you have an AngularJS, you have the package difference of the libraries, either NPM package, other package, you are creating other dependencies, which is your build dependencies. That's what it does here about the build process and checking the code. Now let's look at other ones. What is working? Now building, which is creating a cargo package, it's compiling the code, looking all the dependencies, bringing it together. And when we create that, we are removing any BOM file exists before because we are creating every time, which is kind of, we are creating as BOM file as every time as we build. Now we're not creating a BOM file as one time only. That means you have to create it every build steps. If you're creating an S-BOM file, putting repositories, it's a one time job, you're losing the point of the S-BOM. That means you have to create dynamically. When you initiate any build process, you have to create the BOM files based on your build, based on your deployment. That you have kind of a dynamic creations. Otherwise it's going to become a static. If you become a static S-BOM file, you're creating one time storing a repository. It's all that absolute because next time something may change. You're losing that ability. Let's go back to the couple other examples. Let's go back one more time here. And building. And now it's the packaging pieces. That's how we are creating a package, which is now right now I have the packages created and give you an example as output as the rest. That's the basic hello world type of applications and creating a package is deployable, which is creating a container version of it. Every time you can create a artifacts as well as the result of the artifacts. Let's go to the next one, which is about the S-BOM generators. Now, as I said, the package is really generating S-BOM file to you. It's the BOM file. And then when we create a download the BOM file, you will see the generation of the BOM file as part of your libraries. Now it's basically specific language that I created as the rust and using a cargo app as behind the scene. So what you should really ask yourself, what is my language package I'm using it? What are the containers? What are the package mechanism looks like? And try to integrate S-BOM file generation as part of your build packages. So it's not done yet because we said we would like to verify it. We would like to validate it. For the another thing, once we validate verified, we have to look at any vulnerabilities in S-BOM files. Because we know the version, we know the files, we have to check about any vulnerabilities in the file perspective, which goes back to the BOMR scan. BOMR scan is gonna look at the any type of bill of method you created, you can look at any vulnerabilities in that files. Here's the vulnerabilities, I may see that. There you go. Based on the version that you may have, you can look at the vulnerabilities. Now it's becoming more actionable. That will tell you here's my library that I'm using it, it is known CVs in that files. So till it's all available, what we did, we basically integrate the tool into our pipeline. Generate it, look at the content, look at the file, look at the CVs. There you go. Now we can fix the vulnerabilities that you know. And other things like fixing vulnerabilities, it's also requiring all this process again. You think that I'm gonna update every file quickly, everything's gonna work out? It depends, it depends on your testing, it depends on architecture, it depends on how things you are building. So now I know it, now I can go fix it, I'm gonna run the same pipeline again to make sure that I'm able to test the functionalities, I'm able to deliver the value for my business. Let's look at another one. So I'm storing everything into the artifacts that I created into the artifact repository has to stay in the location that I created as a binaries or the artifact that I created has to store in the same repositories. Now looking for dependency analysis, if you like some dependency analysis, I can store those files and look for any dependency each other's based on the projects. And other things, otherwise you have to keep those artifacts with your code together. Because your code is your project has dependencies as project together because you may not have different files in somewhere else in sitting that you don't have version conflict because you may have different versions, different project, you have to keep them in a single repository so you can really maintain those files which are project specific. And last one is about the verification phases. Now I'm basically verifying with my BOM files which is in total, which is a kind of open source tools for attestation and creating the content of the file you're gonna make sure that you're using the files as the right component you're pulling out of it which is verification pieces. Okay, and this is the basic example to show you how it is easy time for the CI to the perspective. Questions? All right. So basically in total is running behind this and as a get the runner job getting the BOM file and sending to the in total containers and comparing the content of the BOM file based on the libraries and versions. It's basic running the containers. I can show you the kind of a configurations shortly here. Let's go back to our pipelines and look at the job. Actually I may go to the project information, there you go about the files. Here's our GitLab runner. I can share the content basic running a container version of in total and comparing the files easily which is a kind of a GitLab runner part of it and running a container each of the components. All right, so as you can see we can really create all those dependencies and compare it and make sure that we are able to succeed it. This is specifically for one example of creating a BOM file, analyzing kind of look at the vulnerability part of this. Let's look at back to our slides. In our slide what we did it basically there are multiple stage in the pipeline using a cargo clip. You can take the picture or I can share the slide later on with the cargo build with the cargo publish and create a container version of it. Now once we have created now we can really the S-BOM generation pieces using as the package content itself creating a CyclingDX as an example. Gonna show the output of the BOM files. It's an XML but you can use SPDX or you can use any type of tools converting each others. Then we pushed artifact into the catalog so we can look at later on. We verified it in total and then we did the scanning of the libraries. Now it's became more actionable for us. Couple things is dynamic creations. Look in the content. We are creating every time when we change. Now if any developer is putting a new version of the components or changing the package we'll crap right away the changes. Now it's becoming more actionable, right? So in overall, this is the link check I'm gonna go quickly because you have time. Here's the example of the BOM XML file and the cargo references, descriptions and stuff. Here's the bumper scanning tools output because we don't have enough time but quickly what is next? This is important pieces that I would like to talk about it. It's how we can really get together. How we can solve this problem. Think about what you're eating it as the kind of a little burger. Think about everything as document ingredients. So now typically when we build it we have to think about the planning perspective go-spective design. Now we kind of didn't show anything about the how the design is done but we have to think about in design perspective. Map all apps to code bases. Think about what you have in your organization. Look at all your code bases and keep track those documentation, your code and enforce the policy on CI CD which is enforcement policy which is a gatekeeper you can do. You can put your build process as your gatekeeper. You can put your deploying process as capturing the runtime files that you can think about what you're eating is in between. As a takeaway what you should do there are type of the S-Pen file that we discussed so far. You can create the design phases of S-Pen. You can really source it in development phases. You can create S-Pen in the build phase but all of this file doesn't mean they're not talking to each others. You're creating but you're creating every phases of lifecycle that you do and you're gonna connect the dots. It's really important you have to connect the dot which is automation is key point. Integration is another point you have to integrate it because otherwise you cannot have trace abilities. Creating a bunch of files sitting in repositories it is useless. I'll tell you it's useless. It's good to have it but if you don't use it for your monitoring, for your building, for your deploying there is no benefits. Why? Because go spec logforge analysis. How much time I'm spending to know is one elements. Second element is how much able to, I'm able to go fix quickly and timely to eliminate an zero day vulnerability of this. It is requiring automations. It is requiring integration. It is requiring a building at the beginning. Another thing which is my dream really I would like to put into the sacred stories. Anybody know what the sacred stories means? If anybody is writing a story for a functionalities for a planning perspective we have to write the sacred stories. There's a functional like an edge out of the turn we write the stories about the case and epics and stories. We have to think about the sacred stories. We have to think about what are the sacred requirements is required for functionalities. We can integrate S-bomb right into our sacred stories as soon as if anybody is writing some SQL statements or using some other dependencies maybe libraries that we can really track at the beginning of the planning perspective. Like one example, if anybody is gonna tell me we're gonna build up an application using it basically kind of like an AngularJS we can generate dependencies right away based on AngularJS. That's what I'm talking about the sacred stories. So overall really use the automation pieces integrate as much as you can. That's your job. Just running quickly, there's our website you can get a lot of information about DevOps and DevSecOps. I have been writing a lot of blog posts and webinars and supporting many organizations. Feel free, you can download, you can take a look, you can use any times. End of the day, it's about the code, okay. Don't forget that. Everything is code, we are going that direction. To deal about the complexity, it's about the code, whatever you do. It's a code, end of the day. S-bomb is a code. We're gonna use the code and analyze the code again. What are you gonna do? Automation and coding perspective. That's all what I have and I think we discuss a lot but if you have any questions, please reach out to me anytime. I'm happy to really share your stories or hear about your problems as maybe you have any use cases. I'm happy to talk to my students in my class every time, right. Thanks for joining and I'm here for any question that you may have it. I hope it was actionable to you. Ask yourself, what does it for me here? How can I use in my actions? When you go to the office on Monday, please remember, what is it for me? What I'm going to use it? If you're struggling, send me emails. I'm happy to answer your questions. All right, thank you again. Thanks for joining my session. Good.