The Application Security Podcast
Chris Romeo and Robert Hurlbut dig into the tips, tricks, projects, and tactics that make various application security professionals successful. They cover all facets of application security, from threat modeling and OWASP to DevOps+security and security champions. They approach these stories in an educational light, explaining the details in a way those new to the discipline can understand. Chris Romeo is the CEO of Devici and a General Partner at Kerr Ventures, and Robert Hurlbut is a Principal Application Security Architect focused on Threat Modeling at Aquia.
The Application Security Podcast
Hasan Yasar -- Actionable SBOM via DevSecOps
Hasan Yasar believes that everyone shares the responsibility of creating a secure environment, and this can only be achieved by working collaboratively. He underscores the idea that security is not an isolated endeavor but a collective effort, urging everyone to come together and build a world where safety and security are paramount.
Yasar also shares his thoughts about education and security. He highlights the need for integrating security concepts right from the foundational levels of teaching programming languages. By introducing concepts like input validation and sanitization early on, students can be better equipped to handle security challenges in their professional lives. Yasar also mentions the importance of bridging the gap between real-world problems and academic research. By organizing workshops and connecting researchers with real-world challenges, there's an opportunity to create more awareness and solutions that are grounded in practicality.
He contrasts the challenges faced in developing complex systems like simulators with those of web applications. In the context of simulators, every aspect, from memory management to user interface, needs to be meticulously crafted, keeping both safety and security in mind. This holistic approach ensures that safety and security are intertwined, ensuring a robust system. On the other hand, with web applications, developers often only see the tip of the iceberg, unaware of the underlying dependencies, making security a more challenging endeavor.
Hasan Yasar introduces Chris and Robert to the concept of "actionable SBOM" (Software Bill of Materials). He passionately argues against viewing the SBOM as just a static file tucked away in repositories. Instead, Yasar champions the idea that it should be actively integrated into the infrastructure as code. This ensures that when deploying tools like Docker containers, there's a consistent alignment between the software components and their documented versions in the SBOM.
Yasar further underscores the importance of real-time monitoring of the SBOM, especially in a production environment. This proactive approach not only keeps track of the software components but also alerts organizations to new vulnerabilities as they arise. By integrating the SBOM with vulnerability management tools, organizations can maintain a secure environment, ensuring timely updates and patches when potential threats are detected.
The podcast also touches upon the challenges of maintaining an actionable SBOM in fast-paced development environments, where software updates can occur multiple times a day. However, Yasar remains optimistic. He believes that with the right mindset and tools, it's entirely possible to keep the SBOM updated and relevant, making it an invaluable asset in the ever-evolving world of software development and security.
Links:
Software Transparency: Supply Chain Security in an Era of a Software-Driven Society
by Chris Hughes, Tony Turner
https://www.amazon.com/dp/1394158483?ref_=cm_sw_r_cp_ud_dp_PHSFCKCRM7Q8KZ41RDXT
Cybersecurity First Principles: A Reboot of Strategy and Tactics by Rick Howard
https://www.amazon.com/Cybersecurity-First-Principles-Strategy-Tactics/dp/1394173083
Carnegie Mellon Universi
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast
Thanks for Listening!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We're honored to have Hasan Yasar, the technical director of the Continuous Deployment of Capability Group at the renowned Software Engineering Institute at Carnegie Mellon University. With over 25 years of experience in secure software development, Hasan is at the forefront of leveraging emerging tech like DevSecOps, AI, ML, and more to drive transformation in software development. He's a seasoned security engineer and software architect who imparts his vast knowledge as an adjunct faculty member at CMU, teaching software and security and DevOps courses. In today's episode, we'll delve into Hasan's journey into the world of SBOM. and explore its significance in complex systems, especially in highly regulated environments. We'll also discuss the concept of an actionable SBOM, the various types of SBOMs, and how DevSecOps can play a pivotal role in enhancing security. So, without further ado, let's dive into this enlightening conversation with Hasan Yasar.Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO slash general partner of Kerr Ventures, and I am also the CEO of a stealth cybersecurity startup. I know it sounds very mysterious, but there will be information released soon. Also joined by my co host and good friend, Robert Hurabot. Hey, Robert.
Robert Hurlbut:Hey Chris, yeah, Robert Hurlbut, I'm a principal application security architect and threat modeling lead at Aquia and really glad to be here again for another great podcast.
Chris Romeo:Yeah, we're going to unpack SBOM, as our listeners know, one of my favorite things to talk about. Looking forward to it here. Super excited to have Hasan Yasar with us today. Hasan, we like to jump right in with Security Origin Story, giving you no time to warm up whatsoever. How'd you get into this world of security?
Hasan Yasar:All right, it's a long journey. Actually, we have been in security for since I started the writing of program almost 1993, but we never really maybe say clearly about the secure is kind of a laptop requirements, but I have been dealing with the writing a software mainly for F-16 simulators or the aircrafts. We have to have a secure as by design. However, when we get into the more industry places, and I kind of started dropped the security because business was more driver for the functionality. Then, I did a lot of IT related work in industry, and I came to the CMU Carnegie Mellon University as the division of the Forensic Division as part of the CERT, Computer Emergency Response Team, part of the SEI and CMU. Then, I brought my industry experience years and said, Wow, we're going to do something here that's important by thinking securely, not just looking from a forensic perspective. Really taking that application context and get into the, our original thinking of softwares and engineering and all the complexities. Now we have to really clearly talk about secure as we are building application. That's what I kind of get back into the secure world as starting at the CMU 2010 as part of the CERT and try to build up application secure as we are building application. Around that time frame, DevOps started as kind of a thing in the community. As kind of another myth or whatever you call for DevOps and became a reality and how the business functionality is pushing a lot of security minds like business thinking. Now actually security became like kind of more ignored in the community perspective as well as the business drivers and I build up the DevSecOps concept as part of CERT, and CMU said no, we have to do Sec as part of DevOps. We have to do secure as part of application security. We have to do the secure concept as by design. Now there are a lot of opportunities. At the old days, it was very difficult because we had limited tools, limited practices, and we were not able to do a lot of security thinking. Now there is an opportunity for all of us as community members. We can use either DevOps concepts, or Agile concepts, or SAFe, or anything we do, software engineering. Now there is an ability to get the security into our practice. That's kind of my day time job doing a lot of DevSecOps and supporting various Department of Defense organizations and programs as well as teaching at the CMU software security course and DevOps course and I saw how important DevSecured and also how easy to use the secured as part of software engine practices when we think about at the beginning. That's what I'm trying to do, Chris.
Chris Romeo:Okay, so yeah, I have a couple of questions before we even start talking about SBOM.
Hasan Yasar:Absolutely.
Chris Romeo:Caught my attention when you mentioned F-16 simulators and Secure by Design. When you think about building software for an F-16 simulator, how is that different than building software for a web application?
Hasan Yasar:It's a big difference. Why? Because when you think about the, like, a simulator or any type of complex system, Chris, we are not doing a lot of, uh, kind of a very architected or different layers of applications. We were writing the code from literally an interface layer up to the functionalities, either using a C, C++ as an example. If we were kind of at engineering, we have to think about all the. The stack and as well as all the functionalities from memory management all the way to the, uh, kind of users, click the button, etc. It has to be completely controlled. It is great to think about that perspective because we don't know other dependencies. We have to write everything from scratch. As an engineer, it's taken a lot of team coordinations. The security focus was more on making sure that we are addressing the safety and criticality as we write in the code. Safety and security was kind of parallel. in that world, because when you are dealing about a flight, as an example, you have to have a safety. What a safety means? Memory management. What a safety means? About timing. What a safety means? We can write the code that those qualities should be part of, which is kind of a by design, a security, a safety together. When we look at a web application now, we are dealing with just the tip of the iceberg. We don't know other dependencies a lot. Like, we're just writing a code in AngularJS. It is running on such web services. How much do we have a control of web services? How much do we have a control of the dependencies on infrastructure? So the coding seems much easier to write in a web application. Easier means like less timing. But we don't have a control on the code. Comparing the 15-20 years ago, almost 30 years ago honestly, when I write the first time decoding C++ we have a full control. It takes longer to write the code. It takes longer to verify the code and test the code. That's kind of a dilemma we are dealing right now, like time and control. Which one are we going to choose? Do we have to go fast and fast, has less control, or do we have to control the application, but it takes a little bit longer? That's kind of a more directional people are looking for. If you look at the CISO as an example, I'm sure you heard about it, that now we are looking for more Rust language as the memory safety language. They're replacing some of the code bases. To find a balance between time and control, Chris, what I have been seeing in the community.
Chris Romeo:And I guess in the world of F-16s, even though it's a simulator, the stakes are so much higher than... And you could say that the stakes in a web application that processes credit card information and stores that potentially in a database, the stakes are high for that, but that's not a life and death situation. Whereas F-16s and the software that is driving them, and I know you're talking about a simulator, but, um, it just seems like the stakes are higher.
Hasan Yasar:It is. It is higher than in reality. When I did simulator, we were using the same code base for actual flight. One is, one is really running on emulators and, or using a machine as on, on ground. The other one is actually running on a machine, which is the car, the flight, flight is basically aircraft is flying. So it's the same code base, but interface or the machine is really running on the ground. So all the interfaces as same as running on aircraft. Like radar systems, or the heads up display, or the connectivities for each of the control units are exactly the same, mimic, or same configuration using the same instruments. It is not that just the, I know you remember the old Microsoft Flight Simulator, it is not like just the computer graphics. We were dealing with the actual cockpit. All the instruments are interacting with the radar unit or air and altitude or other type of units. It's kind of interacting each other. Difference is running on the ground. So it's kind of, maybe I can say high fidelity of the simulators. So in that sense, we have to think about it. Here's the impact of that thinking. Also, if you train the pilots, if there is any timing of the training pieces, They cannot develop the skills, then they can run the actual aircraft and be so quick in a matter of second. It's a life situation. Like if they don't decide, if they don't learn enough on dealing some indicators on the cockpit or in dealing indicators, some of the, the other in, uh, in kind of a interfaces oriented that's coming a message from the other components. It is very difficult to pilot this site on the flight, so they have to learn those skills when they are practicing simulator. That's the impact of the flight and kind of that situation or a risk assuming situation. So when we take that concept actually, maybe we're going to discuss later on, it's becoming very, very important now if you're dealing with the safety critical systems. Now look at every devices we are on the street and driving the cars. It's the same situation. We are dealing with self driving cars. It's a life threatening situation that we have to think about. Or we are depending on some devices that we are using in our home, or maybe the car that we are using, or the flight we are taking. There's many, many other complex systems that are evolving. So now, comparing that, yes, it is, but it may not be affecting my life, unless if I'm using something, either a medical device, or kind of driving or flying on that device.
Chris Romeo:And we're heading, we're heading towards a world where... There's, there's, you know, such, such as such more software that's going to be surrounding us. And we already have it now. We just, we have to stop and think about how much software runs around us. But I wanted to catch one more topic before we dive into SBOMs. Cause I know you're coming from the university world and you're teaching classes in software security, which is incredible. Like I love to hear that we have professors teaching these subjects, but in general, when I look across academia, I still see a real hole in us teaching security to undergrad students specifically. Like we, I hear from students and I have this favorite question whenever I meet a CS student, it doesn't matter what university you're from. I said, I always ask them the same question. What have you learned about security in your, in your degree program. And often I still hear networks, we do a class on network security. And I'm like, okay, that's great. But there's, we're teaching Java coding or Python coding. We're not doing secure coding with Python, secure coding with Java. So, what's been your experience as somebody who's, who's a lot closer to academia today than I am? Are things getting better when it comes to teaching security to, to undergrads?
Hasan Yasar:So I'm teaching at a graduate level, Chris, and I'm teaching at the, uh, program, which is the graduate level. I'm... My students coming from all around the world to the graduate level courses, what I teach. I see a kind of year by year and undergrad students becoming as a graduate student more knowledgeable in security. Maybe just a, a kind of a community is, it's becoming more aware of the secure account because it's affecting our life now. It's affecting our ability. Now, the students are learning either forcing from the curriculum perspective or learning from where they work, what they do. So I don't see still as very well or teach or taught by the kind of undergrad level yet, Chris. Even the CMU Carnegie Mellon University, we don't have a specific security class under CS department at an undergrad level. All the courses secured as basic graduate level courses. There are a couple of reasons, my opinion is, why we're not able to teach as undergrad. There are maybe some others, like a basic foundational concept. But there isn't any kind of approval, accreditation comes from a university level that you can put a cyber secure as part of undergraduate level. There's one kind of like every, every university has to go approval process. When they look at the CS or other departments, there's certain classes has to be taught to get approval from IEEE and ISO. There is a disconnect between the organizations who are approving the accreditation of those courses. But there's no room for the security yet. So what's happening, like, students are taking, as graduate class, when they're in senior level, that's happening in CMU, and CMU is letting the people, like, interested students, who knows the basic concept of networking, and also the design and operating systems, kernel level, all those things. Their ability to take those software security courses in their senior year to be ready at least when they get to the workhorse community they know about. Which is kind of an undergrad side. But overall, unfortunately, we don't have an ability or teaching or sharing with the communities undergrad level for software security. This is sad. I wish we had more, but there's some kind of constrain we're not able to achieve the security courses. And other constraints that I have been seeing it. Undergrad level is teaching about more what it is, in terms of the concept, in terms of abstract. There's not much courses about how it is, how it can be done. So what it really means, like, it is more theory. It's more about, hey, I'm going to create an operating system. So in kernel level, I'm going to create some data algorithms. It is focused on more about abstracts and theory, building up and engineering capabilities. Now, when we look at the secrets, shoot more kind of a on day, on kind of a more living things, it is very difficult for faculty member keeping up to date. What is the new threats? What is the new problems? You and I, we have been in the domain for years. We know what type of potential threats we might see. We know the trends, because secrets keep changing every six months, as we know, just keep things coming up. It's very difficult for undergraduate professors keep it up to date and changing the curriculums, get approval every time, which is another constraints. It's kind of, yes, we would like to do, we were wishing it, but it is difficult. So what I did in the graduate level, Chris, and I kind of rewired the content every semester, not every year, every semester. Look at what are the trends looks like, what are the adversaries are taking advantage of this new domain, like today, maybe Docker Kubernetes. Now, next, it may be different, something else. So I'm trying to get more into the, uh, relevance of the security instead of teaching something like outdated four years ago. Still it's relevant, may not be relevant as 10 years ago. So it's more kind of connecting the real world scenarios, give the reason, or give some incidents to the student, they can analyze, they can see what's going on. It's more kind of an up to date information that's required to really get understanding security concept. Goes back to your analogy at the beginning, Chris. We don't want to just be teaching the students just writing the secure recording. We have to teach why it's important. What is the impact? Where can I use? What, how can I think about the complexity? What the relationship looks like? Yes, we have to write the secure coding, but we have to know why it's important. I'm gonna stop here.
Chris Romeo:Yeah. And I think, you know, I think there is a lot of room in academia to, to refactor. There's a good development term, right? We need to refactor what course material is going into a CS program. If it means we got to take something out to get the pieces of security added in, then that's what needs to happen. Because when I think of things like input validation, Right? A Java, a secure coding with Java course or secure coding with Python. We should start with input validation before we even let them, before we even let them take a single line off the command line. We should have a lesson in input validation because input validation is really the genesis of almost every class of vulnerabilities we have in the world of web AppSec. It's because somebody didn't validate the input and there are things you can do in an object oriented world to attach, you know, to, to, to find fields and, and define the characteristics and, and shaping input. Maybe that's a more complicated term or a complicated thing, but, but we can do some basic input validation before we even let somebody do a single line program that grabs input from the console. Like so that they know what that threat category looks like. And so that's what I'm, that's what I want to see from the world of academia is it's time for academia to catch up. And I commend you. You're, you're teaching that the highest, you're teaching at the graduate level, the things that we need people to come out with graduate degrees in those things. I just want to see it sprinkled across more, anybody who's writing code, because I think the boot camps are starting to catch on to the importance of security.
Hasan Yasar:it it is, it is. Chris and other things I would like to share with you too, which is kind of a parallel things. We have been trited in the community as frontrunners. We are trying to bring the security concept, as you mentioned, about the input validations or sanitization, time to check, all this concept that has to be taught when we are teaching the language at the graduate, undergrad level. To make their awareness of the faculties as well as the researchers, now we are trying to build up some workshops under, of each conferences, like research conferences. The workshop, the students, usually there is workshop participants as well as the faculties, try to connect the real world problems with the researchers, academia people. Let them be aware of what is going on. Like, the kind of one study I have done, look at the common vulnerabilities. I came up with a total of 24 vulnerabilities we are talking about. Look at every vulnerability in an NVIDIA database or CVs. It came to about 24, like input sanitizations, and checking the times, and password privileges, etc. It is independent from the language. It doesn't matter what language you're using. So kind of building up a lot of workshops under research conferences, and create some awareness for academia, as well as the students who are pursuing their PhDs, or other type of degrees as part of the, you know, after graduate, undergraduate program. So there is, there is evidences keep growing, and most of the research conferences are opening up a venue for a product edition, of course, which is a great, great thing to see, the product edition is also becoming a part of research conference to share the real world scenarios, what is really happening now, which is connecting the two worlds. Like next week, I'll be at Italy and talking about ARIES conferences. I have a specific workshop session talking about DevSecOps, talking about AppSec. describing what the potential problems that we have been seeing in the community. How can we get the researchers focusing on today's problems and deal about and educate the people, educate the students, they will be ready to work for the course. It is getting, but it's not there yet. I agree. We have to do more work down the road. But at least we should start to work in that direction.
Chris Romeo:So I think we've, it's time to talk about SBOM. So Robert, take us into SBOM here.
Robert Hurlbut:Okay, no, it was great, great conversation. Uh, uh, just quick aside, you know, I'm also working on my PhD and, and I got my master's in cybersecurity as well. So, uh, you know, I've seen some of the same things that you've seen and. And so it's been really interesting just to sort of aside to talk about that. Um, so yeah, let's talk about SBOM. So how did you get into SBOM and what drew you to focus in on that area of security?
Hasan Yasar:Great. Thanks, Robert. So it goes back to my CMU journey that I started when I worked in the DevOps. The first time when we tried to do infrastructure as a code, we were not really calling SBOM at the moment, but we were talking about software supply chain as part of infrastructure as a code, as part of the deployment scripts, as part of the build scripts, and creating those artifacts. So, like, we were using as part of a typical DevSecOps practices, like collecting the build artifacts, storing artifacts in repositories, look at the dependencies, creating an environment parody. Now, when we start to see more communities deriving those automation practice, and White House ordered the software bill of materials, and because of the SolarWinds case, everybody remembered that story, that became a kind of a, yes, we have to create an SBOM. But the one thing that's bothered me, And everybody looked at SBOM as just a file content, creating a file that we are done. If you have a file that I know, that means I'm great and I know everything else in the file dependencies. But people never thought about it, what version that we are doing about SBOM. How we generate those files, how can we use those files. So that type of problem attract my attention as I said. Now, as a community members, I have part of CMU. Let's talk about more what really SBOM it is. How we can use those files? Where we can utilize it? And all these questions needs to be answered. Then I became kind of another person in that community, and putting the red flags. Hey stop. If you're talking about the file, CycleIndex or SPDX, let's stop, let's talk about what it is, where we can use, how we generate. That's the reason I'm part of that SBOM community. Talk about it, share some examples, tell the people what it is and how can we use, where we can use. And these are the things that attract me that I'm, that's the reason I'm in the SBOM world as application security perspective and utilizing the modern software language and technologies. That's the reason I'm kind of getting into the SBOM.
Chris Romeo:And I know we've heard in your history, you've talked about some of the complex systems you've been involved with throughout your career. And I can see how complex systems, it's hardware, it's software, these are going to be challenging in regards to SBOM and AppSec. Can you share a story with us about how SBOM plays out in highly regulated environments like Department of Defense?
Hasan Yasar:So, it's a big, big, I will say either a mess or a problem, both directions. The problem is, we are not just dealing with one type of application set, Chris. When we talk about the complex systems, think about any, uh, aircraft. Doesn't matter what type of aircraft it is. Or think about any missile, doesn't matter what missile it is. Or the satellite. There are many components in that, such systems. So each of the components not develop as single vendors. Multiple vendors are contributing. So multiple vendors are contributing either as specific languages, they may have even though some of the systems have still Ada, or a Fortran, and some systems has Rust, or AngularJS. See the complexity? It's a lot. Like we are dealing about very, very old archaic language, versus we are dealing about so much modern languages. It is not just always a container based application we are talking about. There is a real time operating system. So, complexity is, it is more about the different components in the systems. So, when we look at the different components, it is becoming a nightmare of looking at all those dependencies, finding out. So, like, If vendor is developing, uh, uh, one of the components, they may not be delivering the code along with the artifacts. Probably they have some secret source in their modules or their dependents, or whatever, whatever they are delivering the part of the complex systems. Let's say, like, we are talking about aircraft radar as an example. Whoever building up a radar system, they don't want to share how they build it. Because a lot of, kind of, uh, company property information in it. So they don't want to share the SBOM, or they are sharing the artifacts as the binaries. How much do we know that binaries is built based on dependencies? We don't have it. Because they're just sharing how they build it, but it is very limited. So when we look at the complexity, usually in that systems we are looking for the first order of the file dependencies. We don't know the second and third order. Because usually it's built... It's shared with artifacts. So when we look at the, uh, web technologies, usually we're kind of building the components. We know how it is built. We know all the dependencies from the perspective. But in the complex system, we don't build all the time. We're just getting vendor drop. Vendor drop has artifacts as binaries. And here's SBOM. We don't know the second, third order. The second problem is when we get those files, how can we protect those files? Where we can store? Which is a lot of policy or the risk people, they don't want to share. Even though it's not kind of everything else, but they share as part of artifacts. It's becoming a very challenging where to store those SBOM files, how to utilize it, where we can put it, which is protecting those SBOM files. The third one is, once we get all together, let's say we're going to analyze some of the dependencies. If it is conflicting each other. So let's say I have the one versions running in such systems, the same version running in other components. Can we update those systems automatically? Or how can we maintain it? We know it fine, but can I update it? Can I address those vulnerabilities when I look at it? Now, is there any process to update those vulnerabilities? Probably we can update them out of the factory, but when we talk about updating automatically, it may not be easy. It's a very difficult job. Fourth element is about the approval. In the Department of Defense, a high regulatory environment, every piece of software has to be approved. When I say software, actually I'm talking about the system level. Every system has to have an approval that goes into the field and soldiers and mission operator they will use on the field. To have the process we call as an ATO, alternative operating process, now we have a continuous ATO, it is requiring so much checks and validations of those dependencies and risks. It takes longer time to get an approval. There are many, many reasons we can discuss in another podcast why it takes longer. When I put myself in the situation as the AO person to approve, authorize the systems, if I don't know the components, I have to test it. It will take longer time to test those applications for certain vulnerabilities. So it's creating a very complex situations, building hundreds of hundreds of files. Not just building, just somebody's dropping. Now, if I'm a person analyzing all these dependencies, how do I know that? How can I verify it? How can I validate it? How can I test it? It's becoming a very, very complex situation, Chris. So there are some movement happening in the, kind of, more public version information that I can share. There is an IronBank container, maybe you've heard about it. So Air Force decided to build up a containerized versions of every component that we use, let the vendors going to use those containers as we know at the beginning. Let's say I'm going to build up a kind of like a maybe the Rust container or the Python container, whatever the language that people would like to use, build up a container version of that environments, sharing with the community, that community who are using those libraries to build up the systems. At least to solve the, uh, some sort of billing problem, material problem at the beginning when we are trying to build up the components. But it is not there yet, it's just a start to solve the complexity at the beginning of application or system creations, which is more software side. So when we look at the hardware bill of materials, it's another complexity that we have been seeing. So we have so many hardware components. How do I know that the hardware component that we are building, we have a traceability of those hardware materials? So NavDiod is actually talking about XBOM, including just saying S or H, we are saying XBOM for everything else. Use that concept as keep tracking the hardware components, keep doing the software, build, building a configuration management concept as keeping the same version, at least to solve the complexity problem. There's a lot of work that needs to be done, but it's very, very challenging. It's not as kind of thinking about, I'm going to have a web application, I know every file, I can build it automatically. We're not building everything in the DoD context. We are a consumer of the build. When you're a consumer of the build, then how do you know that the SBOM is the true SBOM that you are getting it? How do we know that it's actually the right file? How do we know that we're going to use and protect? These are the typical challenges I have been seeing, Chris.
Robert Hurlbut:So Hasan,
Hasan Yasar:very difficult in comparing with a typical web application. Like, as I said, I'm sorry to interrupt you, Rob. The one off aircraft, we are talking about more than 1, 500 components. It's odd.
Robert Hurlbut:Yeah.
Hasan Yasar:It is difficult. And 1, 500 components, 1, 500 vendors that talk about that perspective. Maybe more. It's very difficult.
Robert Hurlbut:Definitely.
Hasan Yasar:Yes, Robert.
Robert Hurlbut:Uh, so Hasan, uh, you've talked about or mentioned the term actionable SBOM. I wonder if you can take us through that a bit, but also, um, you mentioned XBOM, another type of SBOM, maybe some other types of SBOMs, but in particular actionable SBOM. What do you mean by that?
Hasan Yasar:Great. So when I look at the DevSecOps concept that we have been advertising and working a lot, and a little bit background for both of you. At the SEI Software Institute at CMU, we are architecting DevSecOps infrastructure, many DoD programs, in organizations we do. So what it really means, like we are creating the infrastructure, infrastructures, Let the vendors, as well as the internal developers, they can use infrastructure, DevSecOps pipeline, CICD pipeline, to build up the systems to verify and test it and integrate it. So we will get a perspective going back to the reason why I'm in the SBOM domain. Seeing that the file as the deliverables doesn't mean anything. We have to use those files in our analysis. We have to generate those files if you're able to build it. We will have the file that we have to know it is aligned with our application artifact version together that we push into the deployment environment. When I said actionable means, we don't want to treat SBOM as a static file that stays in repositories or stays in the artifactories. We would like to use those files as part of our infrastructure as a code. We have to use those files somehow to integrate our deployment scripts. If I'm using a docker containers, I want to make sure that my docker container are aligning with my SBOM file that I generated. If I'm using my infrastructure exec code to provision my test harnesses, and I would like to make sure that all the line of the infrastructure exec code, like all the provisioning and all the configuration item, should pull the libraries aligning with the SBOM file that we have, which is more constructing infrastructures or versioning or environments. Now if I am using those files, I have to monitor it, how it is working in a production environment for the vulnerability perspective. That means I have to monitor it, look at all the files, monitor for the new vulnerabilities that keep coming up, and I have to use those vulnerability management software. We have a lot. We have a lot of vulnerability management software. That has to be aligned as well so we can monitor it. We can go back and change it if it is required. But to have those changes, really we have to make sure that it is kind of created as part of our artifact together as had to be versioned together. So versioning just the file itself It's not enough. We have to create a package as code. My dependence is an SBOM. Here's my deployment script as running in production environment. That's kind of using the file as we are creating, as we are building, as we are deploying, as we are testing. So these are the things that that actionable means that we have to use as we are doing the daily process I can let it
Chris Romeo:How does that work? How does that work? Let me just ask a question here because I'm trying to, trying to still, trying to understand actionable SBOM. So how does that work using that artifact when most of the software that a, that a company buys slash consumes comes from another vendor. So most of the software that I get SBOMs for comes from a SaaS provider that they're, I'm not, I'm not building the software, for example, right? So how does, how does actionable. How does actionable SBOM help me in kind of what I think of as the majority of the use cases where I don't, where I'm not building the software myself.
Hasan Yasar:Great. So, perfect. I'm getting, DoD is actually fitting that case a lot. I have to get those files, but I have to create a use case of what I'm going to use. How can I monitor third party libraries in my SBOM file? That means I have to connect the file that I received and align with my monitoring tools, whatever the monitoring that I have, looking for my production environment or the components. If I have a vulnerable management software, that software should look at the files that I got from a specific project. Like, as we know, for the Logforge is an example, right? Logforge is one of the problems. People couldn't find where it is. Do we have a log4j? If we have it, how can I fix that log4j? So, going back to SBOM, if I know the SBOM, if I have a versioning is created with all the artifacts, again, I'm not building, I'm just acquiring the software from third party. I have a full transparency and full traceability of my product that I got from third party vendors, running in which servers, which infrastructures, which machines that I'm using it. I have a traceability of where I deploy, that goes back to the deployment. I know exactly where I'm using it. I exact, I keep monitoring the FO files, which is kind of actionable, means I'm gonna monitor those components. All the libraries and other things is important. Like sometimes we see interdependencies, we have one version, another version, maybe there's sub versions are conflicting each other, so you have to look at those files as well. If I'm running a, an applications in my single server has two products are running in the same server, if I have a conflicting version of those dependencies, I have to know about it because if changing something, it may be okay, but it's going to break other ones. So it's more about the visibility and transparency and also traceability of each of files and where we, how we get it, where we use it, how we monitor it. Each of them is requiring an end to end life cycle thinking, Chris.
Chris Romeo:How does that work from a speed perspective? So one of the challenges I've had with SBOMs has been the government's come out and made these requirements that say we have to have SBOMs for all these things. Anything the government buys has to have an SBOM. And I'll tell you, I'll kind of read back to you what I think is happening with 99.9 percent of these SBOMs right now. The, the customer that's buying software says, I need an SBOM. You just send it to me. And they're taking that SBOM and they're putting it on a, on a file share somewhere. And they're never going to do anything with it again. And so, but what about a world where... Somebody releases software 50 times a day. Okay. So like SAST, like even most startups that reach a certain level of maturity, get to the point where they push software multiple times a day. Let's even say they do it five times a day. How does that work in this, this scenario of actionable SBOM that you're describing for me? Can actionable SBOM keep up with five releases a day? Can it keep up with 500 releases a day? Does it break at some point? What are your thoughts?
Hasan Yasar:So when we look at the monitoring and traceability aspect of it, Chris, we can handle that. We have been, I have been demonstrating already in many use cases. What do we have to do as a secret? Once we have the build artifacts of any systems, any product, the file has to be treated as our artifacts. We have a lot of automation of artifact collections. Like we build an artifact, that artifact goes into the artifact factories. Right? We know that. We have handling. We have process for continuous delivery and deployments. We all are doing all this CD practices as the speed of delivery, but we have to treat SBOM file as part of the package of our binaries. If we treat that, what that means, we have to create SBOM file. As we are creating artifacts, then we are putting artifacts into art dif factories. We can use the SBOM file as part of art factories. We can use the same art factories that we can collect it, put it when we look at the deployment practice. We can attest, we can verify the content of the deployment against SBOM that we created, which is easily coming. There are many, many tools available in the community that tools will help us to use Integrate. The key point is here, Chris, we have to integrate each of the steps in our pipeline. We have to think about SBOM as part of the code. Once we think about as part of the code, how the code is following those steps, we can automatically keep the SBOM as part of our code, how the code is tested, how the code is deployed. Absolutely, we can handle the speed of utilizing those SBOM files. Utilizing as part of our defectories. Utilizing as part of our dependency tracker. Utilizing as part of our code analysis vulnerabilities, like using the bummer as an example. Or using it into a test station of looking at the file content. So there are many tools available. The key problem is we don't think about it as part of the code. We never integrate those files as part of our function together. Just 101 things in the configuration management aspect of Icarus. CM practices says you have to take every component as the individual items in the code base. When we say item, But the item is not just the binaries. Item is the code. Item is the SBOM. Item is the dependencies. So 101 configuration management is actually dictating us to trace each of the items all the way to the end in the production environment. But what we do as a community, we're just creating a file, keep it in somewhere else in the shared drive. They're never able to connect our pipeline, our infrastructure, our deployments. That's the problem we are facing right now. That's the reason we cannot handle in this scale. That's the reason it's becoming useless. What we have to do is really think about it as part of our code. Even though we can think about early in the life cycle, the design phases, Chris, which we, if you look at the CSS, the different type of SBOM, there's a design SBOM, there is a source, there is a build. Each of the SBOM is actually, we are creating as we are building an application. If I am acquiring a third party libraries, I should be able to create a design SBOM as soon as when I'm acquiring. If somebody is changing the one of the dependencies during the build phases, I can verify it for a licensing perspective. I can verify that organizations, is this my developer are using the file that I acquired? Or they are getting somewhere else? So we can really connect each of the phases, but what we do. My opinion, we never really think about this life cycle. We always think, why I have a build time, someone's going to give it to me. So bad. If it is the shared drive, there is no benefits. If it is the shared drive, there is no, we can scale up. It's impossible.
Chris Romeo:Yeah, and it sounds like, I mean, you, you are kind of in the, of the same mind as I am. SBOM is valuable. Transparency is valuable. But it has to have action associated with it. It can't just be another file that sits on a file share somewhere that's just never to be acted upon. Okay, I think we got that one, I think we got that one covered. Um, let's, let's, Robert, let's go into our lightning round here. I wanna, I'm, I'm, I'm very curious to hear Hasan's answers to our now famous... Lightning round questions. I don't know why they're famous. I just declared them famous, but I can do that.
Robert Hurlbut:All right. So Hasan, we have, we have three questions. So the first one is, uh, what's your most controversial opinion on application security and why do you hold this view? Thank you.
Hasan Yasar:So one thing is we don't, we always trust the static analysis result. And we always following the, what the static analysis tool says to fix those vulnerabilities. My biggest problem is we don't know what is enough is enough. Do we have to fix everything? What is the threshold of saying enough is enough for fixing those static analysis findings?
Robert Hurlbut:Okay,
Hasan Yasar:that really means, do I have to fix everything? What the tool says is a hire? Or what matters to me, which is people are really getting in a trap, trying to fix every vulnerable is what the tool says.
Robert Hurlbut:very
Hasan Yasar:It really matters to what the risk that we are dealing about it. It matters what organization risks are. We never think about that perspective. We always say, yeah, I do, but never ever. I haven't seen any organization are really linking those findings, scoring those findings based on their organizational risk policies. It's bothering me. I don't know how I can fix it. I don't know, but we don't know what's enough is enough.
Robert Hurlbut:I hear you.
Hasan Yasar:One day we will do, but I don't know when.
Robert Hurlbut:So our second question is, uh, what would it say if you could display a message, a single message, on a billboard at the RSA or Black Hat conference?
Hasan Yasar:That's a tough question. You know what? I'll say. We are in this world together. Build safer world. All of us, we live for forever. Build a safe world we can live for forever. That's my vision. That's my mission. How to get there? Works together as a team. Let's build up a safe world together to live for forever.
Robert Hurlbut:Excellent. And what's your top book recommendation? Uh, it could be related to security, it could be another topic. Um, and why do you find it valuable?
Hasan Yasar:So I have been reading actually two books that just came out recently, and one is Software Transparency and from Chris Hughes, and he's a good friend of mine. Finally, he's talking about a similar ish this thing we discussed as of today. It's about transparency and how it get, how it get there, how it can be used, how it can be used, how can we make it transparent for everybody else. I like that. The other one actually is kind of, I like that about the Cybersecurity First Principles, Cybersecurity First Principles, and from Rick Howard. And we have to really understand our strategy and techniques and ideas. Then we can really build up our why, why is important to us, what is the strategy. Without having a strategy, it's very difficult. We always kind of becoming a more reactive, we like to build a more proactive role. And I believe the cyber security first principle is going to allow us to think about more proactive instead of being a reactive role.
Chris Romeo:Very nice. Very nice. That's our second or third time the Software Transparency book has been recommended. So folks out there, if you haven't read it or bought a copy and read it yet, it's like the third time you've heard about it. So I don't know what you're waiting for here. But Hasan, how about a key takeaway call to action for our audience here? We talked about a lot of things. We talked about actionable SBOM. We talked about F-16 simulators. We talked about the future of higher education. What, what's a, what's a key takeaway you want to leave our audience with?
Hasan Yasar:You know what key takeaway is, I always say when I was kind of dealing with my students or dealing with the higher ups in DoD, I always say, we are dealing with the security, we are dealing about the problems every day. But we have to learn how to mitigate, how to navigate in this complex world, in this complex security settings. We have to know the risks. We have to know about it. We have, we cannot say like, I'm going to stop everything, don't do it. It's not the right way to think about it in a security perspective. We have to learn as a team wise and how to navigate these complex situations and with a secure mindset. How can we do it? It's just the talking and sharing. That's one of the reasons the podcast is important to learn from each other. We're not alone in this world. Somebody somewhere else dealing the same problem, maybe they're talking the same topic. So being a good ethical persons, let's work together.
Chris Romeo:I think that's a
Hasan Yasar:Let's share the concept and idea so we can get better as a team,
Chris Romeo:Yeah, that's a
Hasan Yasar:instead of silent.
Chris Romeo:great thing to leave us with. Let's, let's work together. This is security is a team sport. It's not a, it's not an individual activity. We can, uh, we can all help each other to, to solve problems and we can learn from each other along the way. And so Hasan, it's been, uh, it's been an honor to learn from you here as a, uh, distinguished professor, as you are, uh. Thank you for coming on the show and sharing your wisdom with our audience and even teaching me a little bit about F-16s. That was of one of the coolest things...
Hasan Yasar:Thank you. Thanks for having me and Chris and Robert. Thank you.
