What makes BSA's secure software development framework unique?

Security frameworks are everywhere -- an abundance owed as much to the dangers of insecure systems and software as to the increasing recognition that secure software is crucial for individuals and organizations of all sizes to carry on their day-to-day activities.

BSA | The Software Alliance, a trade group for software publishers based in Washington, D.C., recently rolled out a secure software development framework that gives enterprise software developers a set of security best practices.

In this Q&A, Tommy Ross, senior director for policy at BSA, spoke about why BSA's secure software development framework is unique and how to incorporate security in the software development process.

Editor's note: This interview has been edited for length and clarity.

What was behind BSA's move to publish this new secure software development framework?

Tommy Ross: BSA is a trade association representing the software industry and largely the enterprise software industry. Our members consist of major software companies, including the companies that everyone's heard of like Microsoft and Apple and IBM and Oracle, but also born-in-the-cloud companies like Salesforce and Workday and Splunk.

Tommy Ross

In terms of cybersecurity, and particularly in terms of software security, we have an interesting group of members; some are pioneers in software development that started out developing software on floppy disks or even punch cards back in the day. They have evolved their processes, their approaches to software development, over the years and have pioneered some of the secure software development approaches, the secure development lifecycle.

We also have a number of companies that have emerged in an era of software development where there's a lot more emphasis on speed and agility and that have continuous integration, continuous deployment and DevOps.

Software as a service has changed software development quite significantly. The range of the ways in which software is developed and deployed and maintained across our companies is pretty diverse; we've had an interesting set of experiences to draw upon in developing this software security framework. It's important to have the ability to look at best practices that work in a lot of different environments and the ability to talk with companies that have learned hard lessons about security over the years and been really focused on trying to improve their secure development lifecycles.

We started the effort over a year ago for a few reasons: One is that we have a number of companies that are really committed to software security and to improving security across the software ecosystem, so it's an innate commitment that shapes their policy interests. And this is something that they wanted to take on as an opportunity for thought leadership.

We do see a rising number of software-focused threats, threats focused on taking advantage of vulnerabilities that already exist in software products that are deployed and threats that focus on trying to exploit vulnerabilities in the software supply chain. The second motivation is we've seen policymakers around the world respond to this rising number of software-focused cybersecurity threats with a variety of different policy initiatives.

Our feeling was that there is not sufficient guidance out there in the form of internationally recognized standards, in the form of best practice literature, to help policymakers understand how to approach software security. Because software development is so diverse in terms of the development methodologies, the coding languages, the intended uses of the software and the development tools, we think it's a really important area to get right. Getting it wrong means creating real disruptions in how software is developed and how companies are able to innovate.

In this context of growing threats and increasing policy efforts underway around the world, we wanted to show what we believe to be a robust, responsible approach to software security that is workable across all these different diverse facets of software development.

Given the abundance of security frameworks available now, what makes the BSA security framework unique?

Ross: The NIST critical infrastructure framework has been a paradigm that we looked to in developing our framework. What makes that such an important paradigm is that it's not a checklist. Good security frameworks don't provide compliance checklists; what they do is provide a series of security outcomes and pathways for relevant companies or organizations to meet those outcomes. The frameworks become tools for smart conversations about the level of security associated with a particular organization or network or product or service.

That's the model that we tried to follow. In addition to being outcome-focused and providing some flexible pathways for organizations to meet those outcomes, it's important that they account for risk, because there is such a diversity of risk profiles across different systems and different organizations. Frameworks allow organizations to make smart choices about how to address the most important risks.

Another important aspect of the framework model -- at least in the NIST paradigm -- is that it's technologically neutral, so the security outcomes are spelled out with a lot of different technical approaches you can take to get to that security outcome, but it doesn't prejudge any sort of technology necessary to get there.

How does the BSA secure software development framework differ from some of the other prominent frameworks currently in use -- some of which are mentioned in the BSA framework as information resources?

Ross: In terms of security frameworks, there are a number of things out there, but they take on different aspects of cybersecurity.

The NIST framework is focused on critical infrastructure organizations, but more than that it's really focused on networks so it doesn't really touch on how to develop and deploy secure software. It focuses on how network administrators should configure their networks and architect their networks to maximize their cybersecurity and minimize risk. Likewise, the ISO 27000 standards focus on information security broadly. It is applicable to software, but it is not detailed and specific with regard to software -- same thing with NIST 800-63.

Many of the security frameworks that are out there are really more focused on networks and systems. With software, there are a number of best practice guidance documents so we relied really heavily on SAFECode, for example. SAFECode produces really good literature around best practices in relation to secure development. But those documents tend to be more narrative, they don't provide the specific diagnostic statements that we try to include in the framework and so they don't really provide any basis for assessing the security of an individual product or service.

The best practice literature tends to focus on certain elements of software security. SAFECode has done a wonderful job over the years building out best practice literature around the secure development lifecycle. But if you look at our framework, one of the things that we're trying to assert is that the secure development lifecycle is one important thing to consider in relation to software security, but it's kind of the input side. It outlines the processes through which organizations should be integrating security into their software development. We also need to think about the output side, when you look at the product or service that comes out of the secure development lifecycle. What are the characteristics of that product or service that are important to assessing that product or service's security? We try to tackle that as well.

It is the first framework or guidance or tool that provides specific, measurable guidance specifically for software-related security considerations.

How can software developers prepare to use or start using the BSA security framework?

Ross: We'd like to see it become a basis for organizations to design their secure development lifecycle. One of the reasons we link to information resources throughout the document is so each one of the diagnostic statements and subcategory statements make assertions about what software developers should be doing. We want to provide as much information as possible on how they can do it.

Ultimately, we'd like to see software development organizations design their software development lifecycles in ways that address each of the diagnostic statements throughout the relevant portions of the framework, and, again, that's the input side. On the output side, we think it's important that software development organizations be able to account for how they address each of the security considerations, particularly in the secure capabilities function of the framework in relation to each of the products and services they produce.