---
title: "Tommy Ross — The BSA Framework for Secure Software"
url: https://appsecpodcast.com/tommy-ross-the-bsa-framework-for-secure-software/
date: 2019-07-19
duration_seconds: 2218
guests: ["Tommy Ross"]
topics: ["Secure Development", "Software Supply Chain", "Privacy and Compliance"]
audio: https://www.buzzsprout.com/1730684/episodes/8122637-tommy-ross-the-bsa-framework-for-secure-software.mp3
transcript: true
---

# Tommy Ross — The BSA Framework for Secure Software

*July 19, 2019 · 37 min*

with [Tommy Ross](https://appsecpodcast.com/guests/tommy-ross/)

on [Secure Development](https://appsecpodcast.com/topics/secure-development/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Privacy and Compliance](https://appsecpodcast.com/topics/privacy-and-compliance/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122637-tommy-ross-the-bsa-framework-for-secure-software.mp3)

## Show notes

Software producers, customers, and policymakers need a common way to discuss security without pretending that one checklist fits every product. Tommy Ross, a policy leader at BSA and a drafter of its Framework for Secure Software, explains how the framework was created and who it is meant to help. He describes its outcome-focused structure, the relationship between functions and more specific categories, and the role of existing industry practices. The conversation uses software supply-chain requirements to show how a high-level goal can become a useful discussion about evidence and risk. Tommy also explores procurement questions, policy needs, and the process for collecting feedback. The result is an introduction to a shared vocabulary for evaluating software security.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Tommy Ross:  
→ [Tommy Ross at RSA Conference](https://www.rsaconference.com/experts/tommy-ross)

Mentioned in this episode:  
→ [BSA Framework for Secure Software — PDF](https://www.bsa.org/files/reports/bsa_software_security_framework_web_final.pdf)  
→ [Framework repository](https://github.com/thomasrbsa/BSA-Framework-for-Secure-Software)  
→ [SAFECode](https://safecode.org/)

Chapters:  
00:00 The BSA Framework for Secure Software  
01:24 Tommy’s path into security policy  
04:17 What BSA does  
06:09 Introducing the software security framework  
10:27 Producers, buyers, and policymakers as audiences  
14:24 A common vocabulary for customer requirements  
20:10 How the framework was developed  
24:05 Functions, categories, and outcomes  
27:21 A software supply-chain example  
28:17 Applying a requirement in practice  
29:20 Questions policymakers can ask  
32:51 Finding the document and contributing feedback

## Transcript

*5,436 words · assemblyai*

**0:00 Chris Romeo:** Tommy Ross serves as Senior Director Policy with BSA, the Software Alliance. In this role, he works with BSA members to develop and advance global policy positions on a range of key issues with a focus on cybersecurity, privacy, and market access barriers. Tommy is one of the coordinators/collaborators on the BSA Framework for Secure Software. This document caught our attention when it came out a few months ago. as it is a reliable representation of all the pieces an organization needs for software security. Tommy shares with us some of the background stories on how this document came to be and also walks through the various pieces contained within. We hope you enjoy. I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

**1:24 Robert Hurlbut:** The Application Security Podcast. Here we go. Hey folks, welcome to the Application Security Podcast. This is Chris Romeo, one of the co-hosts here, and I'm also the CEO of Security Journey. And I'm joined today by Tommy Ross from the BSA. And Tommy, we always start this podcast— our listeners know this already— but we always start with a person's security origin story. So, if there was a comic book that describe the way you got into security, what would episode 1 look like?

**2:24 Tommy Ross:** Oh, well, episode 1 would be a little ways away from security because I started out as a lowly letter writer on Capitol Hill answering questions from constituents about national security issues that were going on in the world. Really at the time, mainly about the war in Iraq. I wrote thousands and thousands of letters on the war in Iraq. So it was a long journey to get from there into cybersecurity. I worked on Capitol Hill for about 12 or 15 years and eventually worked for the Majority Leader of the Senate during the time when Congress was considering comprehensive cybersecurity legislation. And so spent about 5 years focused on trying to understand how the government could best put in place tools to shape cybersecurity across the industry and to defend government and critical infrastructure systems against malicious cyber activity. We kind of failed dramatically in our effort to pass comprehensive cybersecurity legislation, but it laid the groundwork for a lot of the legislation that's on the books today and really got me into cybersecurity and put me on my current career path.

**3:40 Robert Hurlbut:** And that ultimately led you to the BSA, which we'll get into that here in a second. But I just want to fill our listeners in a little bit on how we got here. So, BSA put out a release, press release about this new document that was coming out that was gonna focus on software security. And one of our other guests, Adam Szostak, who's very well known in the world of threat modeling, we were talking to him and he said, hey, I'd listen to an episode if you talked about that new document that came out. And so here we are. So thanks, Adam, for, you know, for—

**4:17 Chris Romeo:** Thanks for having me.

**4:17 Robert Hurlbut:** volunteering to listen if we went ahead and did the interview here. So, Tommy, I think it'd be good for our listeners to understand, first of all, what is BSA? Because to be honest with you, I'd never heard of it before this document came out. And so I'm curious, kind of what is BSA? What's it there for?

**4:31 Tommy Ross:** Sure. Well, back on my sort of origin story, I should clarify, you know, I'm a, I'm a policy guy, not a technical guy. And I think that's sort of the space where BSA lives. We're an industry association representing Most of the leading enterprise software companies, the traditional software companies that everyone's heard of, like Microsoft and Oracle and IBM and Apple, but also born-in-the-cloud companies like Salesforce and Splunk and Workday that are bringing a new type of software product and a new type of software development in a lot of cases to the market. So we have a pretty broad array of leading software development organizations. And BSA as an industry association represents their equities in the government space around the world. So in front of both legislative organizations and executive branches in the United States, in Europe, in Asia, and around the world.

**5:35 Robert Hurlbut:** So cybersecurity is just a subset then of what BSA focuses on. A number of different categories I saw on the website of different kind of areas that result in software, but cybersecurity just happens to be one of them.

**5:49 Tommy Ross:** It's one of them. It's one of our priorities. I mean, we do work in a number of different areas, but I think what we've seen over the last 4 or 5 years is that cybersecurity has come to the forefront in a way that has elevated it as a priority among our member companies and therefore made it one of the chief areas of focus for BSA.

**6:09 Robert Hurlbut:** Great. And so that takes us then to the BSA Framework for Secure Software. And so I thought it'd be good to, for those that may not even know that this thing exists at this point, it'd be great to just get a definition of what is this document called the Framework for Secure Software?

**6:25 Tommy Ross:** Sure. Well, maybe I can sort of start out by talking about why we did it, and that'll give you a sense for how it developed into the tool that we envisioned. We have seen a gap for some time in the policy space around software security, and not just the policy space. I mean, it affects developers as well, and it affects stakeholders across the ecosystem when it comes to software security. There really has not been a defined benchmark for assessing or discussing security outcomes related to software security. And so our members set out to fill that gap, and many of them had had a lot of positive experiences over the past several years with the NIST Cybersecurity Framework, which is really more focused on networks and defending critical infrastructure networks in particular. But they had had a positive experience with that. They liked the way that it is flexible and outcome-focused so that it allows for software developers to look at a lot of different technical approaches consistent with a specific and measurable outcome. And so we set out with that as a model. What we were trying to achieve was a tool that, like that NIST framework, can be used to help organizations understand and assess their own security practices, but then help outside stakeholders, including policymakers and customers, understand and assess security outcomes associated with the software. And so we did follow the NIST model where we had a framework approach that's, as I said, flexible, risk-based, adaptable to different technologies, different development environments, different coding languages. And then it follows the framework model. So there are functions, categories and subcategories. We also adopted NIST's mapping to relevant standards and informative resources, but then we added a little bit additional detail because with software development, the details are really important, and we wanted to get sort of down to the next level beyond where the NIST Cybersecurity Framework had gone. So we incorporated something called a diagnostic statement, which is really intended to be a specific measurable statement. And then we also added a comment, a column on comments on implementation. One of the chief challenges that we faced when it came to this framework was that there are so many different kinds of software, so many different methodologies used, whether it's different development models or different coding languages, different update timelines, all that kind of stuff. And so even where we wanted to be as specific as possible, we also wanted to be as universal as possible. And so in some cases, we needed to further elaborate on how diagnostic statements might apply to certain development methodologies where the application isn't obvious. So that's kind of a general overview of the framework. And as I said, it is a tool, or what we intend is that it is a tool to help guide developers and then to help stakeholders across the ecosystem have smart conversations about the level of security associated with individual software products and services. including within the organizations and then with external stakeholders like policymakers and customers and also suppliers.

**10:27 Robert Hurlbut:** Yeah, I think it's great that you've stuck to the NIST CSF model. I've been a big fan of NIST CSF since it came out just because I think it's so easy to understand. It's not like a giant 1,000-page document that you're lost in very quickly because it's got so much detail. And so, yeah, as I was going through the Software Security Framework here in preparation for this conversation, I thought, yeah, this is— I like how this is kind of lined up. And now I'm realizing it's because you took that same approach as NIST CSF. So it's great to take things like that and carry them forward. So who is this actually for then? Who is the— I mean, you mentioned policy folks, you mentioned some other ones, but who is the target audience for this document?

**11:15 Tommy Ross:** Yeah, I mean, that was of course a question that was at the top of our minds as we were developing this. We didn't believe that there is one target audience. We believe that there's a handful of them. For software developers, we see this as a document around which a secure development lifecycle can be built or can be assessed if it's already in place. It does link back to best practice literature on the secure development lifecycle from a variety of different sources. And so it's a resource for developers to think through logically how to build or how to improve the development process for their software. It's also internally for organizations a way to enable folks outside the software development team to understand and talk about security, whether it's security teams that are— that need to be looking at software as it's coming out of the development teams, depending on how the organization is structured, or whether it's, for example, lawyers or government affairs representatives who need to be able to make representations about the security of the software before the audiences that they're dealing with. So the software development organizations themselves are one important audience. I think a second important audience, and really one that drove a lot of our, a lot of our motivation for producing this was the policymaker audience. What we've seen is that around the world, there are a number of different governments that are looking at ways to build confidence in the security profiles of the software that is being procured by the governments and that is going out into the marketplace in IoT devices and in other forms. So policymakers was certainly a second big audience. And then the third is that, you know, as we went through through this process, we heard from a number of the software organizations that we spoke with that they are increasingly confronted with customers that are really concerned about the security associated with the products or services they're thinking about buying, but don't have good ways to talk to the companies about it. So they'll submit questionnaires that might be up to 100 pages long, and might have some good questions in there, but also might have a lot of stuff that's just not relevant. And so what happens is the security teams, instead of really pouring all of their resources into security, spend a lot of time answering these questionnaires, and it sort of lengthens the sales cycle and that kind of thing. And so what we had hoped is that this tool would provide customers a way to have more sophisticated targeted conversations with their suppliers in a way that would improve their confidence in the products or services, but also shorten the sales cycles and simplify the, the, the conversations.

**14:24 Robert Hurlbut:** Yeah, as somebody who's been on kind of both sides of that last one, the customer requirements, uh, definitely every time— it seems like every time we get one of those, it's slightly different. Like, yeah, like 80% of the questions are the same, but they're not worded the same way. And so, I think you're right on there that there's really a need for— if we got to the point where even where the software security framework here was what folks were referencing, it would at least give us that common vocabulary and common set of questions versus we always have to interpret what the question is to try and figure out what's the answer that somebody's actually looking for.

**15:00 Tommy Ross:** Yeah, that's absolutely our goal.

**15:02 Robert Hurlbut:** So, I see a couple of guiding principles that you've highlighted here for the document itself. These really jumped out at me because I like to understand when I'm thinking about something like a framework, what was driving the decision process that you made. And so you listed risk-based, outcome-focused, flexible, adaptable, and aligned with internationally recognized standards. Tell us a little bit about why you chose those as the guiding principles.

**15:28 Tommy Ross:** Well, I think that as we've looked at different efforts to try to think about software security, in different contexts around the world, we see these as areas that are common pitfalls of those kinds of approaches. I mean, obviously, when you have rigid standards or rigid regulations around software, software evolves so quickly that those rigid regulations can really inhibit software developers from pursuing those innovations or pursuing that evolution. And so the There needs to be something that is flexible enough to allow for continuing evolution. But I think the important caveat is that it needs to be flexible, but also meaningful from a security standpoint. So that's why we have tried to be as specific as we possibly can with the introduction and the diagnostic statements. Risk-based, obviously, that's a principle that we think is important to incorporate throughout the development lifecycle. And we've done that within the, within the framework itself, development of software really should begin beyond the idea for the software, should begin with an assessment of the potential risks or the potential threats. The threat modeling, as you brought up earlier, is a really crucial part. And so many different parts of software development build off that initial understanding of the risk landscape. And so we've tried to build in a risk-based approach throughout the framework. Outcome-focused, very similar. We think there are a lot of different technical approaches to get to common security outcomes. What should matter is not the specific technical approach, but the outcome, whether we get to the security control or the security capability that's important to address the threat that's been identified. And then we do think that there is a need for the framework to be universal, to be adaptable to different technologies, different development processes, different coding languages. That's been one of the big constraints on developing tools like this for software security in the past, is that there's just so much variation across different development processes and different coding languages. Just to give you an example, We understand, well, many sort of traditional software developers will issue patches or updates on a regular schedule, every Tuesday or once a quarter, that kind of thing. But with a lot of the DevOps-based continuous integration, continuous delivery kind of methodologies, we see software platforms being updated 1,000 times a day or even 10,000 times a day. And so we have to have— and this is important both in terms of having a framework that can apply to both types of development processes, but also it goes back to the evolution of software. You know, if you have a testing-based approach that tests software against, you know, a specific rigid set of standards or criteria, you can test that product in the morning, and by the time you go to bed, you're 10,000 versions behind.

**19:03 Robert Hurlbut:** Yeah.

**19:04 Tommy Ross:** So, you know, we thought that that was— that having something that worked across these different methodologies and was flexible enough to account for the speed at which software is evolving was really important. Finally, I think from our members' perspectives, you know, they are working in markets around the world, and what they see is that, Governments share a lot of the same challenges, but they often don't take common approaches to solving them. And when they don't, it creates market challenges. It creates barriers for global companies to be able to deliver quality products consistently around the world. You know, if you have different standards that you have to build to, and you start having to build different products for different markets, it divides your efforts as a company to achieve and adhere to consistent standards for security. So that's a long-winded description of why those principles really are core to the framework.

**20:10 Robert Hurlbut:** Yeah, so I want to switch gears a little bit and talk about the construction of this document because it has so many different pieces to it. I'm really curious as to how you were able to decide what to actually include in this thing. And I'm envisioning a room with hundreds of hours of people yelling and arguing with each other to try and— because, you know, this is— some of these are controversial topics to some degree. And so how did that process all work? How did this come together?

**20:38 Tommy Ross:** Yeah, well, there's a virtual room for sure. I mean, we went through several different drafts. We have the luxury of having a number of members who really have been innovators in software security over the last several years. So you think about Microsoft really inventing the secure development lifecycle. A number of our other members have been major contributors to organizations like SafeCode, which develops coding best practices or software development best practices. They've been major contributors to standards development organizations and to best practice literature. So there's a lot of knowledge that we had to pull from, also a lot of differing opinions. across these organizations and a lot of different methodologies for developing software. So we got a diverse group that we could draw upon through our member companies. We also reached out to a lot of stakeholders beyond our membership, including the open source community, other non-BSA member companies, government stakeholders, think tanks, nonprofit organizations, and so on. And we shared drafts and solicited input. I think we began by looking through what we identified as commonly used or widely recognized literature, including best practice literature, NIST publications, internationally recognized standards, OWASP, of course, the Common Weakness Enumerators that we reference throughout the framework. We looked at all these different documents and tried to identify the themes that seemed to resonate across a number of different communities and really begin our construction of the framework by drawing on that best practice literature that was already there. We then worked through that content and tried to put it in a logical progression and fill in the gaps where there were gaps. And there are gaps. I mean, if you look at the framework, you will see that for some of our diagnostic statements, there are not informative references or relevant standards listed because there just isn't a whole lot of literature out there. And one of the areas that we think is really important where there's just not much best practice literature at all is around the end of life for software.

**23:13 Robert Hurlbut:** Yeah.

**23:13 Tommy Ross:** So, you know, we had to make it up and we made it up based on our understanding of how software is developed and responsible security practices. And then we vetted it against this diverse community of contributors that we had access to. And as I said, went through several iterations. And I think one thing I'd really like to highlight is we're still going through iterations. We've posted the framework on GitHub and have solicited comments there. We are— we've made very clear from the outset that we intend this to be a living document, and we're going to continue to update it as we receive more input. And we have received further input, and we're already working to figure out how to how to update the framework with that input.

**24:05 Robert Hurlbut:** Great. And so now if we kind of once again switch gears and get into the actual document itself and the component pieces that we find here. And so just as I've been studying the document, I see that there's really kind of 6 different categories here. You've got functions, categories, subcategories, diagnostic statements, implementation notes, and informative references. And so Starting with functions, functions are really just your high-level kind of really large buckets of different pieces?

**24:39 Tommy Ross:** Yeah. I mean, the purpose of using the framework model is that everything should proceed logically. So what we tried to do is start with the big chunks that we wanted to think about when it comes to software development and put those in the function And we wanted to put them in as functions. And so the way we thought about this is that secure development, our first function, really covers everything from the inception of the idea for the software all the way until the product or service is deployed into the marketplace. So it includes coding, it includes testing and verification, it includes supply chain risk management, It includes the security and integrity of the development environment itself. The last function, secure lifecycle, covers everything after the product or service is deployed into the marketplace. So traditionally, that's largely focused on vulnerability management. We've also included guidance on configuration and end of life. And then the middle function is a little bit different. The middle function is on secure capabilities. And I would say the first and last functions are largely oriented towards processes that are used to produce and maintain secure software. The middle function is one that we think is particularly important because it is a set of security outcomes that we believe should be associated with a specific software product or service.

**26:25 Chris Romeo:** Okay.

**26:26 Tommy Ross:** So they are characteristics of the software that comes out of the development process. The idea here is that it's not enough just to have a secure development lifecycle process in place. That process ought to yield outcomes that reflect security characteristics in the software itself, and we ought to be able to look at the software product or service and assess it according to those characteristics as it goes out into the marketplace.

**26:56 Robert Hurlbut:** Yeah, I kind of, as I'm continuing to flip through the document here, as we're chatting, it almost seems like the secure capabilities section is more of the functional security functional requirements, I guess what we call them in the days of old. And then the lifecycle and the secure development are more of the process or those things that would tie closer to the actual secure development lifecycle. process.

**27:20 Tommy Ross:** Exactly.

**27:21 Robert Hurlbut:** Great. Well, let's, um, let's jump right in and look at an example of one of these. I think it'd be nice to just walk across and talk through, you know, one of these categories that exists somewhere. So I guess, do you have a favorite one, Tommy?

**27:36 Tommy Ross:** Um, one of the ones that we spend a lot of time looking at is supply chain risk management. Um, that is obviously a hot topic as people think about how to ensure the security of third-party components that are being integrated into the software. And there's a lot of conversation in Washington among policymakers, but then in other governments and beyond government circles around how we can improve third-party component security. So that's a good one to look at, I think.

**28:08 Chris Romeo:** All right.

**28:09 Robert Hurlbut:** So that one sits in the secure development hierarchy, right? Are we looking at the category of supply chain.

**28:16 Tommy Ross:** Exactly.

**28:17 Robert Hurlbut:** Okay, and then if I look under— so the category is supply chain, the function is secure development, and if I look under the subcategory, I look at the first one, it says software development is informed by supply chain risk management. And then the diagnostic statement says an organizational supply chain management plan and processes for identification and reporting of supply chain incidents are established. And then you have those all-important pointers in the relevant standards. That's one of the things I love about NIST CSF. I just love to see those relevant standards and resources and things brought forward here. There's lots of OWASP documents I see. There's lots of other things that I see. Now that we've explained this example in supply chain, How do you see somebody using this? Let's use this requirement and say, what would my next step be after I kind of look at this? I've said, okay, this supply chain thing is important to me. How would somebody actually use this requirement?

**29:20 Tommy Ross:** Well, I think it depends on who is using it. If you're a developer, then this sort of lays out a series of of responsibilities for understanding and managing the supply chain as you go through the process. So it begins— most of our categories begin with something along the lines of the one you read, which is that there needs to be some sort of overarching strategy or plan that identifies the key moving parts and puts in place processes and guidance for how to, how to keep those moving parts moving in the desired direction. So that's sort of the overarching statement there in the example you gave. But then it gets in, as you go through that category, it gets into increasing detail about what specific processes or safeguards or controls should be put in place to manage supply chain. So if you look at the next one, the subcategory is about ensuring visibility, traceability, and security of third-party components. And then it lays out 3, or I'm sorry, 4 different specific responsibilities in that respect. And so for a developer, it says, you should, as you're working on your software development lifecycle, or you're developing software within the guidance that you've put in place for your organization, it is reasonable to expect that you will be able to identify all the third-party components that you're integrating into your software, and that you're able to identify and inventory the subcomponents of those integrated components to the greatest extent feasible, recognizing that it's not always feasible to identify subcomponents that you yourself have not directly integrated. So it sort of lays out those and other responsibilities relating to visibility, traceability, and security, enabling the developer to sort of know what should be expected in that specific instance and how to tool a software, a secure development lifecycle around it. A lot of those things can be done with automated tools. And so some of it is a matter of matching the automated tools to the diagnostic statements. But in other cases, there are organizational processes that need to be in place to account for them. If you're a policymaker, on the other hand, it lays out a series of security outcomes that you can look to, to understand how confident you ought to be in the security of a software product or service. And so if you're a policymaker looking at the same category, it gives you a set of questions to be able to ask software development organizations Hey, can you produce an inventory of the third-party components that have been integrated into this software? If so, that's useful information. If not, why not? What's the risk associated with the lack of an inventory in that case? And so on. So it provides some kind of prompts for a more sophisticated conversation about the product or service. Yeah, and this is just an—

**32:51 Robert Hurlbut:** we just took an example example from the supply chain area, I just want to make sure that folks know, like, even within secure development, there are a series of other categories that exist, including secure coding, testing and verification, process and documentation. There's supply chain that we've been talking about. There's toolchain, identity and access management. So, there's a lot of different moving pieces of this document, and I really think it's worth folks that are involved either from the program side or even individual developers that have an interest in security, I think it's very worthwhile to take a look at this document and understand it because there's just a lot of good stuff. As somebody who's done this for a lot of years, I'm going through going, yep, I agree with that, I agree with that, I agree with that. I'm sure I can find something to argue with, but for the most part, I'm agreeing with what I'm seeing coming through here, and I love the way that it's, it's been systematized into this this framework here. And so, I guess the million-dollar question is, where do people get this document from if they want to grab a copy?

**33:53 Tommy Ross:** Well, our website, bsa.org, is the easiest place to go. We do have it posted on our website. We do have it posted on GitHub as well. And I'm sure we have it posted on various social media outlets as well. But the BSA website is probably the easiest way to get it.

**34:14 Robert Hurlbut:** Okay, and there's no— one of the things, other things I love, just so my listeners know here, I didn't have to put in any information or anything. I just went to the website and there was a PDF available. So, there's no hidden download, put in all your information, and you don't have to do that. It's just available there.

**34:30 Tommy Ross:** So, Tommy, what would be your final takeaway then for our listeners to kind of summarize what we talked about and maybe an action, call to action or something that they can do coming out of Well, I think for me, what I increasingly think about and what our companies increasingly think about is that software vulnerabilities are growing really rapidly, and they are one of the more common ways that malicious actors exploit networks and devices and critical infrastructure in ways that are increasingly alarming. We've seen an increase in supply chain attacks. We've, of course, seen the Internet of Things become a huge target of attacks, and a lot of it goes back to software vulnerabilities. In 2017, for example, 77% of malware attacks exploited vulnerabilities in software that were already installed on the target system. So this is a huge challenge that we need to take on as a community. And I guess our message is that the BSA framework is a first-of-its-kind tool to allow organizations to have meaningful conversations about the security choices that are being made as products and services are being developed, and to allow customers, policymakers, and software development organizations themselves achieve a level of confidence in the security profile of software. And that's a win for consumers. It's a win for enterprises. It's a win for governments. So we're really excited about the framework. and are hoping to further engage with stakeholders, your listeners, and others out there on how we can improve it and how we can make sure that it is widely used by software development organizations and others throughout the ecosystem.

**36:25 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbunt. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/tommy-ross-the-bsa-framework-for-secure-software/