SEPTEMBER 2020  |   VERSION 1.

The BSA Framework

for Secure Software
A NEW APPROACH TO SECURING
THE SOFTWARE LIFECYCLE

SECURE SECURE SECURE

DEVELOPMENT CAPABILITIES LIFECYCLE

www.bsa.org
CONTENTS

I. Executive Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

II. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Defining “Software Security”. . . . . . . . . . . . . . . . . . . . . . . . . 4

Framework Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Framework Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Implementing the Framework for Secure Software. . . . . . . 12

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

III. BSA Framework for Secure Software . . . . . . . . . . . . . . . 14

IV. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

I. Executive Summary

Developments over the last several years have resulted in the dramatic expansion of software-
powered capabilities from traditional computers and industrial control systems into diverse
personal devices, widely deployed sensors, smart appliances, connected vehicles, robotic systems,
and beyond. These innovations are driving the creation of a new, connected digital economy
and can yield tremendous economic and social benefits. Yet, because these technologies also
have the potential to create economic, legal, and even physical risk, software developers must
have the joint goals of building software securely and ensuring that it can be securely maintained
throughout its lifecycle.

Software development organizations, their customers, (3) help software developers, vendors, and customers
and policymakers are increasingly seeking ways of communicate internally and externally about software
assessing and encouraging security across the software security; and
lifecycle. While standards and guidelines exist to aid
and inform developers in achieving these goals, there (4) help software customers evaluable and compare the
is no consolidated framework that brings together best security of individual software products and services.
practices in a manner that can be effectively measured, The Framework is intended to focus on software products
regardless of the development environment or the (including Software-as-a-Service) by considering both the
purpose of the software. BSA | The Software Alliance has process by which a software development organization
developed The BSA Framework for Secure Software (the develops and manages software products and the
“Framework”) to fill that gap. security capabilities of those products. It is intended
Specifically, the Framework is intended to be used to: to complement guidance for overall organizational
risk management processes. To the greatest extent
(1) help software development organizations describe possible, it seeks alignment with recognized international
the current state and target state of software security standards and to remain flexible, adaptable, outcome-
in individual software security products and services; focused, and risk-based.

(2) help software development organizations identify The Framework is intended to be a living document,
opportunities for improvement in development and updated and improved based on ongoing feedback from
lifecycle management processes, and assess progress BSA’s members and other relevant stakeholders.1
toward target states;

1
Version 1.0 of the Framework was originally released April 29, 2019.

www.bsa.org 1
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

II. Introduction

Modern society is built on software. Software powers personal technologies, critical infrastructure,
scientific research, and industries across every sector. It drives emerging innovations such as
the Internet of Things (IoT), blockchain, and artificial intelligence (AI). As software becomes
increasingly central to our lives, making it secure and reliable becomes ever more critical in the
face of an evolving and expansive cybersecurity threat landscape.

From within the software community, best practices security that is flexible, adaptable, outcome-focused, risk-
are emerging that help software developers address based, cost-effective, and repeatable. Eschewing a one-
important aspects of software security, including size-fits-all solution, this voluntary framework will provide
security-by-design principles, secure development a common organization and structure to capture multiple
lifecycle processes, and internationally recognized approaches to software security by identifying standards,
standards for key security elements such as identity guidelines, and practices that can help software
management, encryption, and secure coding. Although development organizations achieve desired security
attention to each specific security consideration can outcomes while accounting for the wide spectrum of
achieve marginal security gains, effective security intended uses, risk profiles, and technological solutions
requires a comprehensive and risk-informed approach among software products and services.
that combines individual considerations into a holistic,
lifecycle-long framework. And a comprehensive approach Recent technological developments illustrate the
must be tailored to address the nuanced, diverse, and increasing ubiquity of software and the need for a
evolving challenges associated with different types of flexible, comprehensive software security framework.
software and connected devices, from the “bare metal” Software-powered capabilities continue to expand into
to the most advanced. every corner of personal lives and business activities,
including diverse personal devices, widespread sensors,
Building on best practices pioneered by many of its smart appliances, diverse business applications,
members, BSA | The Software Alliance has developed a connected vehicles, and robots. As these capabilities
software security framework to bring consistency to these evolve, software development is growing increasingly
complex challenges. The BSA Framework for Secure diverse and complex.
Software is intended to establish an approach to software

The BSA Framework for Secure Software is intended to establish an approach to software security
that is flexible, adaptable, outcome-focused, risk-based, cost-effective, and repeatable.

2 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Consider the different ways software is used in several emerging technologies:

Internet of Things Software-as-a-Service (SaaS) Artificial Intelligence

Software is at the core of the Many software applications are AI also brings new considerations
IoT, and secure software must now being operated as services to software development, along
be at the core of IoT security. from a cloud-based architecture in with new security challenges.
IoT devices have different which code is segmented across AI software often integrates
forms, functions, and levels of multiple container environments, multiple software components,
complexity. At the low end, updated constantly and in real- frameworks, and platforms,
some “bare metal” sensors lack time, and accessed via Internet potentially introducing new risk
even a basic operating system connections rather than installed with each additional element.
and contain only software code locally. Some SaaS applications Moreover, AI generally must
sufficient to perform one or two are updated dozens or even ingest and process enormous
simple functions. More complex hundreds of times each day, with data sets, introducing risk
devices may include operating little or no disruption to the user through the exposure of the data
systems, AI algorithms, or the experience. How can we craft a itself. Combined, these risks
hundreds of millions of lines of software security framework that demonstrate the importance of
code needed to operate many of accounts for the new technical software security for AI products.
today’s connected vehicles. How approaches to software security Yet, at the same time, AI products
can we achieve confidence in that SaaS development may are creating promising new
the security of software products demand, while at the same approaches to integrating security
across this spectrum? time driving secure outcomes in into software development.
traditional software development? How can we address the risks —
and harness the benefits — for
security in AI software?

These diverse and constantly evolving software relevant framework for software security. By adopting
development techniques and products demonstrate a flexible, outcome-focused approach rooted in
the need for an outcome-focused approach that can industry best practices and international standards, the
consistently ensure security across a broad array of Framework is structured to be applicable to the entire
technical considerations. Additionally, static, inflexible spectrum of (1) software development organizations and
approaches will either disrupt innovation or fail to keep vendors, whether individual entrepreneurs, large-scale,
pace with evolving threats because software is constantly multi-national businesses, the open source community,
changing. or others; (2) software development methods, from
traditional to DevOps; and (3) software products, from
The intent of the Framework is to provide the entire simple IoT sensors to complex AI algorithms.
software industry with a comprehensive, adaptable, and

www.bsa.org 3
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Software security encompasses what a software development organization does to protect a

software product and the associated critical data from vulnerabilities, internal and external threats,
critical errors, or misconfigurations that can affect performance or expose data.

Defining “Software Security” from vulnerabilities, either intentionally designed into the
software or accidentally inserted at any time during its
Software security encompasses what a software lifecycle, and that the software functions in the intended
development organization does to protect a software manner.” It has also been defined3 as “the development
product and the associated critical data from and implementation of methods and processes for
vulnerabilities, internal and external threats, critical ensuring that software functions as intended and is free
errors, or misconfigurations that can affect performance of design defects and implementation flaws.” While
or expose data. It comprises both organizational such definitions may suggest that the level of security
processes and product capabilities. associated with a given software product could be
ascertained simply by measuring the presence and extent
Organizational processes include governance
of defects or vulnerabilities in its code base, software
structures, strategies, guidance, and clearly defined
security is rarely that straightforward.
procedures that guide the development of software
in a manner that identifies and incorporates security One challenge is that — at least currently — it is
objectives throughout a product’s lifecycle, protects impractical to expect all software code to be entirely free
the integrity of the development environment, of vulnerabilities. Indeed, according to some estimates,
applies resources to incident and vulnerability software products currently average roughly 1–5 defects
management, and manages the supply chain that per 1,000 lines of code, with many complex software
supports the software development project. products incorporating tens or hundreds of millions of
lines of code in total.4 While defect-free code should
Product security capabilities are technical aspects
always be a developer’s goal, it is not a realistic industry
of specific software products that are useful in
standard. Instead, the goal should be the widespread
enabling the products to address common security
adoption of practices and processes that minimize code
challenges, such as protecting data, preventing
defects, and particularly known software vulnerabilities,
unauthorized access or use, tracking incidents and
and to maintain a proactive security posture oriented
vulnerabilities, and managing unforeseen events.
to identifying and addressing problems before they
Both organizational processes and product security can be exploited. In fact, researchers have documented
capabilities are vital elements of software security. substantial improvements in average software defect
density among leading software developers through
Software security is often discussed in relation to the implementation of secure development lifecycle
software assurance. Software assurance has been approaches and other software security best practices.
defined2 as the “level of confidence that software is free

2
https://www.hsdl.org/?view&did=7447
3
https://safecode.org/wp-content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Development_March_2018.pdf
4
https://resources.sei.cmu.edu/asset_files/Webinar/2014_018_100_295971.pdf

4 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

A second challenge is that any approach to software Other models exist for informing or assessing
security that is distilled into a test or series of tests at a software security. Some of these models, including
single point in time is inherently flawed. As developers SAFECode’s Fundamental Practices for Secure Software
increasingly adopt iterative approaches to development, Development, the Software Assurance Maturity Model,
incorporate third-party components, and face evolving and various secure software development lifecycle
security threats, a software product may change methodologies, serve as important starting points
continually and substantially over its lifecycle. Testing for the Framework described in this document. They
methodologies undergo evolution as well; for example, provide detailed guidance, informed by broad industry
the set of known software vulnerabilities assessed best practices, on a wide range of considerations
by certain testing methodologies may be frequently organizations should address to maximize their ability
updated to include newly discovered flaws. Security to produce secure software in a verifiable, repeatable,
is a persistent requirement; while software testing is a transparent manner. However, in many cases, these
critical element of secure development, it is not a stand- guidance documents lack specificity and are primarily
in for a sustained, security-focused approach to lifecycle targeted toward organizations, focusing almost
management. exclusively on organizational approaches, processes,

SDL GOVERNANCE
The foundation for secure software development is the creation of a culture of security, and an organization’s
governance practices are a key contributor to creating such a culture. Because software development
organizations are diverse with regard to size, organization, and methods, different governance practices will
be more or less effective for different organizations. For example, for larger organizations, measures like
identifying a security champion or separating security teams from coding teams may make sense, whereas
smaller organizations may be more efficient by collocating security and development roles. Focusing on
security outcomes associated with specific software products and services, the Framework does not attempt
to establish measurable diagnostic statements to holistically evaluate an organization’s security governance.
Nonetheless, implicit in the Framework is a robust commitment to coherent, committed, effective governance
practices and processes to guide software development.

Governance includes:

» Building commitment across an organization’s leadership to software security and secure development.

» Establishing clear expectations and standards for integrating security into the software development
lifecycle and establishing processes for achieving them.

» Establishing clear policies, as well as processes for elevating and accepting exceptions to those policies
based on risk analysis.

» Ensuring every individual involved in software development and software security is aware of his or her role
and is prepared to perform it.

» Identifying metrics to enable consistent evaluation and adjustment of secure development lifecycle
processes to improve outcomes and integrate lessons learned.

www.bsa.org 5
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Through an examination of risk, software development organizations will apply the Diagnostic
Statements appropriate for their environment and product, and identify cases in which Diagnostic
Statements are inapplicable or irrelevant.

and methodologies that collectively constitute the input Framework Basics

of software development. They offer limited guidance
on security considerations in relation to the output of The Framework identifies best practices relating to
software development; that is, the software product. both organizational processes and product capabilities
across the entire software lifecycle. It is organized into
The Framework takes the approach of defining software six columns: Functions, Categories, Subcategories,
security by considering both input and output; that is, Diagnostic Statements, Implementation Notes, and
it includes considerations of organizational processes Informative References.
that guide how vendors approach the development and
maintenance of a software product as well as security Functions organize fundamental software security
capabilities and considerations relevant to the product activities at their highest level, consistent with the
itself. Moreover, it provides this guidance at a level of software lifecycle. The Functions are:
detail that is specific enough to be measurable, without
compromising the flexibility necessary to ensure that all SECURE DEVELOPMENT
organizations can tailor the guidance according to the
type, use, and associated risk of a software product.
Secure development addresses security in the phase
The Framework is intended to apply to all types of of software development when a software project
software. Yet, because of the tremendous diversity in is conceived, initiated, developed, and brought to
types of software, software development processes, and market
risks, some security considerations will be more relevant
to certain types of software than others. Moreover, SECURE CAPABILITIES
organizations will vary in how they customize approaches
to achieving the outcomes described in the Framework.
Secure capabilities identify key security characteristics
The Framework is intended as a tool to create a common
recommended for a software product
language for discussions about how software approaches
security, enabling stakeholders to hone in on the security
outcomes most relevant to the circumstances. Rather SECURE LIFECYCLE
than serving as a box-checking exercise, a common
language enables organizations to describe how they Secure lifecycle addresses considerations for
approach a specific security outcome or why that maintaining security in a software product from its
outcome may not be applicable to their product. development through the end of its life

Categories divide a Function into distinct considerations

and disciplines relevant to the Function. Many Categories
are fundamentally interwoven with other Categories;
for example, the “Vulnerability Management” and

6 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

“Vulnerability Notification and Patching” Categories are Informative References are resources that identify and
conceptually closely related, as successful vulnerability describe best practices, guidelines, or further information
management necessarily involves vulnerability for the implementation of an associated Diagnostic
notification and patching. However, the Categories Statement. They may describe methods for achieving
seek to distill best practices into distinct subjects or the described outcome, provide technical specifications
disciplines; in this example, “Vulnerability Management” or related best practices, and offer further clarity and
provides guidance for organizational processes to specificity on the security benefits of the described
identify, prioritize, and mitigate vulnerabilities, whereas outcome. Informative References include internationally
“Vulnerability Notification and Patching” identifies best recognized technical standards, best practice manuals
practices for developing and issuing patches, mitigations, and guidelines, and references to Common Weakness
and notifications to customers. Categories within the Enumerators (CWEs). A current list of CWEs is maintained
same Function may involve different communities of at https://cwe.mitre.org/. In some cases, multiple
practices within the software development organization; standards may offer alternative approaches to achieve
for example, “Secure Coding” practices will may be most similar outcomes. Similarly, CWE references are drawn
relevant to a different part of a software development from a community-developed taxonomy of software
team than those members responsible for “Supply Chain weaknesses that serves as a common language for
Risk Management” practices. describing weaknesses and provides a baseline for
identification, mitigation, and prevention of such
Subcategories further divide a Category into distinct, weaknesses. Numerous CWE references may be related
unitary concepts that express identified software security in some form to a specific Diagnostic Statement; the
best practices. Framework attempts to identify the most relevant
Diagnostic Statements identify specific, verifiable weaknesses resulting when the Diagnostic Statement
outcomes. They provide a set of results that help is incompletely or improperly addressed. In all cases,
support achievement of the outcomes in each Category. Informative References are illustrative and are not
Diagnostic Statements are not intended as an exhaustive intended to be either exhaustive or prescriptive.
list of best practices, but as a set of desired outcomes The Framework’s Subcategories and Diagnostic
that are relevant to enhancing security across as many Statements are often focused on the individuals and
classes and types of software as possible. The Framework team that actually develop software. In practice, entities
does not intend that every Diagnostic Statement will developing software are complex organizations that
apply to every development environment or software often include separate software development teams
product. Instead, through an examination of risk, that interact with security teams, corporate governance
software development organizations will apply the structures, and external requirements, each of which play
Diagnostic Statements appropriate for their environment key roles in driving the security outcomes the Framework
and product, and identify cases in which Diagnostic describes. By “software development organizations,” the
Statements are inapplicable or irrelevant. This approach Framework intends to address all parts of an organization
is consistent with other risk-based frameworks that seek involved in the design, development, deployment,
to encourage and guide secure activities while avoiding and maintenance of software, recognizing that each
becoming simple checklists. organization must determine how it can assign roles
Implementation Notes provide additional information, and responsibilities to most effectively achieve desired
where necessary, such as examples of how organizations security outcomes.
may achieve security outcomes described in the There are numerous approaches to software development,
Diagnostic Statements, interpretations of how Diagnostic with Agile and Waterfall being two of the most common.
Statements may apply in different development The Framework does not recommend any specific
environments, and guidance on aligning implementation approach and encourages software development
with risk. organizations to consider the Categories, Subcategories,
and Diagnostic Statements in the context of whatever
method they are using.

www.bsa.org 7
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Framework Purpose

The Framework is intended to be used to:

1 2 3 4
Help software Help software Help software Help software
development development developers, vendors, customers evaluable
organizations organizations identify and customers and compare the
describe the current opportunities for communicate security of individual
state and target state improvement in internally and software products
of software security development and externally about and services.
in individual software lifecycle management software security.
security products processes, and assess
and services. progress toward
target states.

The Framework is intended to focus on software Risk-Based.

products (including Software-as-a-Service), by
Software is enormously diverse, ranging from
considering both the process by which a software
applications that perform only a few basic functions
development organization develops and manages
to highly sophisticated AI programs, and it is used in
software products and the security capabilities of
an enormously diverse array of contexts, from home
products. It is intended to complement, rather than
computing networks to the very backbone of the
replace, guidance for organizational risk management
Internet. The different types and uses of software carry
processes. To the greatest extent possible, it seeks
different risks; for example, the software behind a mobile
alignment with recognized international standards.
phone game may pose far less threat to cyber or physical
The Framework is intended to become a living security than the software operating an electricity grid’s
document, to be updated and improved based on control system.
ongoing feedback from BSA’s members and other
To manage the risks associated with software,
relevant stakeholders.
organizations should build software development
processes around careful analysis of the risks associated
with their products, the potential resulting impacts, and
Guiding Principles
their organization’s risk tolerance. With an understanding
The Framework is based on five key principles: of risk tolerance, organizations can prioritize security
activities in their software development and lifecycle
» Risk-based
management processes, enabling informed decisions
» Outcome-focused about where to prioritize improvements and how to align
» Flexible financial and human resources.
» Adaptable
» Aligned with Internationally Recognized Standards

8 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Many elements of the Framework are intentionally structured to provide software development
organizations with the flexibility to tailor their approaches based on the risk profile of the product.

Risk informs the Framework throughout its three software security must be flexible enough to enable
Functions and is intended to guide software software developers to develop new approaches to new
development organizations and vendors to address challenges, and to deliver innovative products to the
security considerations in operational processes and customers who depend on them.
product security capabilities according to the level of
risk associated with the product. The Framework approaches this vital principle by
ensuring that it specifies outcomes that are neutral with
For example, consider the first Subcategory articulated regard to coding language, development process, and
in the Framework which reads: “Threat modeling and risk technical approach. Similarly, the Framework recognizes
analysis are employed during software design to identify that some Diagnostic Statements may be more important
threats and potential mitigations.” This risk analysis is to some organizations than others. For example,
designed to guide software development organizations companies securing SaaS products will find statements
toward adopting the security controls most appropriate relating to securing containers, such as TC.1-6, more
to the type and uses of their products. Understanding applicable to their software development environment
of the risk subsequently informs the development of a than businesses providing mostly out-of-the-box
plan to address security considerations in the software’s software. Likewise, organizations developing out-of-the-
development and deployment. box software may find Diagnostic Statements relating
to anti-tamper techniques, like SM.4-1, more useful.
The Framework is structured in a way such that each
Outcome-Focused.
Diagnostic Statement is intended to maintain flexibility
The Framework communicates best practices in their while remaining applicable to software of all types,
most detailed form through Diagnostic Statements languages, and development processes.
that identify specific, measurable outcomes. These
statements are intended to be neutral with respect to Many elements of the Framework are intentionally
coding language, development process, and technical structured to provide software development
approach. Rather than dictating specific security organizations with the flexibility to tailor their approaches
techniques, the Framework focuses on the outcomes based on the risk profile of the product. For example, the
software development organizations and vendors ideally “Support for Identity Management and Authentication
should achieve to enhance the security profile of the (SI)” category recognizes that not all software products
software. will require an identity management and authentication
mechanism but includes clear guidelines for those
that do. It directs that software “avoids hard-coded
Flexible. passwords” and “avoids authentication mechanisms
Software development as a discipline is constantly that allow insufficiently complex passwords, insufficient
evolving based on innovations in efficiency and password aging management, unlimited log-on
management, emerging customer demands, new attempts, commonly used password topologies, or
approaches to coding languages or software unverified password changes.” For some software
development tools, and technical breakthroughs. products, these guidelines will mean adopting strong
Moreover, cybersecurity requires constant innovation
to keep pace with changing threats. Any approach to

www.bsa.org 9
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

EXAMPLE

Preventing SQL Injection Attacks.

Hackers may use SQL injection — a code injection technique in which malicious SQL statements are inserted
into an entry field for execution — to compromise the confidentiality, integrity, and/or availability of data
used in a software program. SQL injection attacks are particularly common in database-driven applications
and are among the common types of malicious cyber activity.

Concatenation of untrusted data with string constants (string concatenation, or the combining of multiple
strings of untrusted data into a single string) is a common and dangerous weakness that SQL injection
attacks can take advantage of. To mitigate the risk of SQL injection attacks, the Framework includes the
following diagnostic statements in the Secure Coding category of the Secure Development function:

SC.3-1. Software avoids, or includes documented mitigations for, known security

vulnerabilities in included functions and libraries.

SC.3-2. Software development organizations validate input and output to mitigate

common vulnerabilities in software.

By focusing on secure outcomes, the Framework avoids mandating specific technical approaches to
structuring SQL statements, such as prescribing certain stored procedures or whitelisting techniques. SQL
statements can be created and parameterized using many different programming languages, libraries, and
frameworks; the Framework establishes clear security outcomes that are targeted and meaningful but retains
the flexibility to enable its achievement through each of these differing languages, libraries, and frameworks.
In each case, the outcome specified in the diagnostic statement is linked to references to informative
material that provides further detail on achieving the outcome, including references specifying techniques to
prevent SQL injection attacks.

Not all software products are at risk of SQL injection attacks, and not all software products utilize dynamic
SQL statements. The security outcomes specified by the Framework are met equally by the software product
that develops properly parameterized SQL statements as by the software product that excludes dynamic
SQL statements altogether. The appropriate approach to meeting the specified security outcome will be
based on a risk-informed software design and security architecture.

identity management and authentication mechanisms, Adaptable.

such as multi-factor authentication, single sign-on
In today’s development context, software is constantly
technologies, and log-on limits. For others, they will
changing. Many products are continually updated
mean ensuring that third-party identity management
with new features and additional security measures
and authentication tools meet those guidelines before
long after their original market deployment. For that
they are incorporated. For still others, they will mean
reason, software security must be conceptualized in a
validating that such measures are not needed based on
way that is adaptable to this lifecycle, as well as to the
the product’s risk and architecture.
constant innovation of new technologies, processes,

10 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

EXAMPLE

Vulnerability Advisories to SaaS Customers.

To ensure that users are properly informed of relevant security information associated with software updates,
the Vulnerability Notification and Patching category of the Secure Lifecyle function includes the following
diagnostic statement:

VN.3-1. Users are notified of a significant security issue when a

remediation is in place for each supported version of the affected product.

As important as such notifications can be when users are asked to install updates that could potentially
have broader impacts to their own devices or systems, it may not be feasible for notifications to accompany
every software update in some contexts. For example, many SaaS vendors operate in a continuous delivery
environment, meaning software is produced in short cycles of testing, staging, pre-production, and
production. Because SaaS is a web-based model in which software is maintained on remote servers rather
than installed on user devices, SaaS software updates are also generally not installed on user devices.
Continuous integration and continuous delivery methodologies make it possible to quickly deploy new
versions of, or security updates to, a SaaS application without customer disruptions or losses of service.
Sophisticated SaaS vendors may deploy dozens, or even hundreds, of software updates to an application
each day.

By focusing on information relevant to significant security issues, the Framework avoids onerous notification
requirements, which may be impossible to meet in a SaaS environment, while ensuring customers are well-
informed regarding the security of their products and services.

and standards in the software industry. For that reason, for defining and implementing effective approaches
approaches to software security that mandate specific to cybersecurity and facilitate common approaches
technical measures or that endeavor to subject software to common challenges, thus enabling collaboration
products to batteries of tests that assess security at and interoperability. Industry leaders have developed
a single point in time will fail to keep pace with the a range of international standards and best practices
constant evolution of software. Instead, this Framework for secure-by-design software development. To ensure
provides a tool to assess the characteristics of software international interoperability and express consensus best
security throughout a software product’s lifecycle, practices, the Framework seeks to align, to the greatest
using outcome-focused Diagnostic Statements that are extent possible, with internationally recognized technical
adaptable to diverse and evolving technical approaches. standards wherever they exist. Currently, two notable
examples relevant to secure software development
are the ISO/IEC 27034 and ISO/IEC 62443 series of
Aligned with Internationally Recognized
standards, which sets out guidance on “integrating
Standards. security seamlessly throughout the lifecycle” of software
Internationally recognized standards provide widely applications.
vetted, consensus-based information and guidance

www.bsa.org 11
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Using the Framework as a cybersecurity risk management tool, an organization can establish a
holistic secure development lifecycle that identifies likely risks, enables conscientious decisions
about risk mitigation and risk tolerance, improves software quality, and prepares the organization
to address emerging security considerations throughout the software’s lifecycle.

Implementing the Framework for the Framework into internal training and awareness
modules. In addition, the Framework may provide
Secure Software a useful tool for educating executives about how
The Framework is designed to support the systematic security is addressed in the development process,
processes used by software development organizations how resources are aligned to security considerations,
to identify, assess, and minimize cybersecurity risk and how individual products incorporate
throughout the lifecycle of software products. Using cybersecurity.
the Framework as a cybersecurity risk management
» Tracking and assessment. Software development
tool, an organization can establish a holistic secure
organizations may wish to use the Framework as a
development lifecycle that identifies likely risks, enables
tool to track a product as it is developed or to assess
conscientious decisions about risk mitigation and risk
its security profile according to concrete metrics.
tolerance, improves software quality, and prepares the
For example, software development lifecycles often
organization to address emerging security considerations
establish release gates that require a project to meet
throughout the software’s lifecycle. Specifically, software
an established measure or obtain a waiver before
development organizations may find the Framework
advancing; elements of the Framework may be
to be a useful tool for the following purposes, among
incorporated into release gate criteria. Additionally,
others:
the Framework may help an organization identify
» Development process guidance. A software metrics that define and measure software security for
development organization should publish definitive its products.
direction on the policies and processes that
» Vendor relations. A software development
development of a new software product is expected
organization should implement measures to ensure
to follow in order to ensure that all involved
the integrity of its supply chain. Organizations may
stakeholders understand roles, responsibilities,
choose to use the Framework to guide purchasing
and expectations. Organizations may choose
decisions and/or the development of vendor contracts
to amend software development processes and
that ensure third-party software components will not
process guidance to ensure the elements of the
jeopardize the organization’s security objectives and
Framework are accounted for throughout the product
compliance requirements.
development lifecycle.
» Public security narrative. Software development
» Training and awareness. A software development
organizations may wish to communicate information
organization may consider developing internal
about a product’s security features and its approach to
training and education programs to build a culture of
mitigating cybersecurity risk to a public audience. The
security and to ensure that stakeholders are trained
Framework may be useful in enabling organizations
in responsibilities and methodologies appropriate
to build a narrative about their secure development
to their roles in the software development lifecycle.
lifecycle and product security.
Organizations may choose to incorporate elements of

12 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

As customer and policymaker interest in evaluating

security in software products and services continues
to rise, an important use for the Framework will be to
enable software development organizations to represent
how their products and services align with certain
standards and guidance, and to enable customers
to assess potential software purchases against such
guidance. Version 1.1 of the Framework maps each task
included in the NIST Secure Software Development
Framework (SSDF) to one or more diagnostic statements,
thus providing software development organizations,
customers, and other entities a tool to evaluate how a
software product or service aligns with the SSDF. BSA
is committed to working with NIST and other software
development stakeholders to ensure that future iterations
of the Framework will incorporate new guidance and
standards as they emerge or are updated.

Conclusion
The BSA Framework for Secure Software provides
software development organizations, software vendors,
and software customers with a risk-based, adaptable
tool to evaluate security outcomes in individual software
products and services. Its focus on products and
services, instead of the development lifecycles of the
organizations producing them, is unique: the Framework
allows stakeholders to evaluate not just whether
security is integrated into software development, but
also whether software effectively implements essential
security capabilities. Its risk-informed, framework-based
model enables stakeholders to tailor their evaluations to
the specific functions, risks, and operating environments
of the individual software products and services being
evaluated. Stakeholders can apply the Diagnostic
Statements included in the Framework where appropriate
for their environment and product. Through thoughtful
and detailed application of the Framework, stakeholders
can gain trust that the software they develop, sell,
purchase, or use will enhance the cybersecurity of their
organization and the broader digital ecosystem.

www.bsa.org 13
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

III. BSA Framework for Secure Software

The Framework does not intend that every Diagnostic

Statement will apply to every development environment or
software product. Software development organizations will
identify and apply the Diagnostic Statements appropriate for
their environment and product based on analysis of risk.

SECURE SECURE SECURE

DEVELOPMENT CAPABILITIES LIFECYCLE

14 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Secure Coding SC.1. Threat SC.1-1. Software Threat modeling attempts ISO/IEC 27034; OWASP
(SC) modeling and development to identify and prioritize the Application Security
risk analysis are organizations document potential threats against a Verification Standard;
employed during likely threats. software product or component SAFECode “Fundamental
software design in order to guide software Practices”; SAFECode
to identify threats development decisions that “Tactical Threat Modeling”;
and potential defend against identified threats. SAMM; BSIMM; CWSS;
mitigations. Some software developers work CAPEC; OWASP Threat
in accordance with “zero trust” Modeling Cheat Sheet;
principles, which assume a NIST SSDF PO.1.1, PW.1.1
pervasively hostile environment.
Yet, even with zero trust
approaches, threat modeling is
important for identifying sensitive
data and prioritizing threats for
mitigation. Developers should
consider the risk profile of the
product when determining the
level of detail to provide in such
documentation.

SC.1-2. Threats are rated ISO/IEC 27034; SAFECode

and prioritized according “Fundamental Practices”;
to risk. SAMM; CWSS; CAPEC;
OWASP Threat Modeling
Cheat Sheet; NIST SSDF
PW.1.1

SC.1-3. Software ISO/IEC 27034; SAFECode

development “Fundamental Practices”;
organizations SAMM; CWSS; CAPEC;
apply common OWASP Threat Modeling
threat modeling Cheat Sheet; SAFECode
methodologies. “Tactical Threat Modeling”;
NIST SSDF PW.1.1

SC.1-4. Compensating ISO/IEC 27034; SAFECode

controls are identified “Fundamental Practices”;
and mapped to threats. SAMM; CWSS; CAPEC;
OWASP Threat Modeling
Cheat Sheet; NIST SSDF
PW.1.1

SC.2. Software SC.2-1. Standards are ISO/IEC TS 17961; SEI

is developed formally identified and CERT C Coding Standard;
according to documented. SEI CERT C++ Coding
recognized, Standard; SEI CERT Java
enforceable coding Coding Standard; NCSC;
standards. NIST SSDF PO.1.1, PW.5.1

SC.2-2. Software uses SAFECode “Fundamental

canonical data formats. Practices”; CWE-1219;
CWE-22; CWE-35; CWE-36;
CWE-37; CWE-38; CWE-39;
CWE-40; NIST SSDF PW.5.1

www.bsa.org 15
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Secure Coding SC.3. The SC.3-1. Software avoids, Software should avoid known NIST NVD; CWE/SANS
(SC) software is secure or includes documented vulnerabilities to the greatest Top 25 Most Dangerous
(continued) against known mitigations for, known extent possible. In some Software Errors; OWASP
vulnerabilities, security vulnerabilities in instances, there may be reasons Top 10; CWE-1006; CWE-
unsafe functions, included functions and for software to incorporate 242; NIST SSDF PW.3.2,
and unsafe libraries. libraries. functions or libraries known PW.5.1
to include vulnerabilities;
such functions or libraries
should only be incorporated
when developers include
documented mitigations that
ensure the vulnerabilities are not
exploitable.

SC.3-2. Software SAFECode “Fundamental

validates input and Practices”; OWASP Input
output to mitigate Validation Cheat Sheet;
common vulnerabilities CWE-20; CWE-89; CWE-
in software. 119; CWE-120; CWE-183;
CWE-184; CWE-242; CWE-
625; CWE-675; CWE-805;
NIST SSDF PW.5.1

SC.3-3. Software SAFECode “Fundamental

encodes data and/ Practices”; CWE-79; NIST
or uses anti-cross site SSDF PW.5.1
scripting (XSS) libraries.

SC.4. Standard SC.4-1. The software SAFECode “Fundamental

software assurance employs segmentation Practices”; CWE-265; NIST
measures are through sandboxing, SSDF PW.5.1
employed in containerization, or
the software similar methodologies.
architecture and
design.

SC.4-2. The software DoD-PPP; OWASP

employs system element Application Security
isolation mechanisms. Verification Standard; NIST
SSDF PW.5.1

SC.4-3. Software Where errors in integer SAFECode “Fundamental

uses robust integer computation cannot result in Practices”; CWE-129;
operations for dynamic security-relevant errors, use of CWE-131; CWE-190; CWE-
memory allocations and robust integer operations may 680; CWE-805; NIST SSDF
array offsets. not be necessary. PW.5.1

16 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Testing and TV.1. Analysis TV.1-1. Attack surface is OWASP Attack Surface
Verification and validation identified and mapped. Analysis Cheat Sheet,
(TV) of the software SAMM; NIST SSDF PW.1.1
attack surface is
conducted.

TV.1-2. Analysis is SAFECode “Fundamental

informed by threat Practices”; OWASP Attack
model(s) and risk Surface Analysis Cheat
analysis. Sheet; NIST SSDF PW.1.1

TV.2. Code review TV.2-1. Code review To the extent possible, SAFECode “Fundamental
using manual and/ release gates are automated tools should be Practices”; BSIMM; SAMM;
or automated tools established and implemented and integrated OWASP Testing Guide;
is conducted. enforced to guide with the software development OWASP Code Review
software development. process to ensure rigor and Guide; NIST SSDF PO.4.1,
consistency. Manual tools can PW.3.2, PW.7.2
be substituted in cases where
automation isn’t feasible.

TV.3. A TV.3-1. Test plan is SAFECode “Fundamental

comprehensive test based on threat model(s) Practices”; OWASP Testing
plan for testing the and risk analysis. Guide; NIST SSDF PW.7.2,
functionality and PW.8.1, PW.8.2
security of software
is established and TV.3-2. The software is SAFECode “Fundamental
implemented. tested in a least privilege Practices”; NIST SSDF
environment. PW.8.2

TV.4. Software ISO/IEC 27034; SAFECode

security controls “Fundamental Practices”;
are properly tested SAMM; BSIMM; OWASP
with appropriate Testing Guide
techniques.

TV.5. Software TV.5-1. Software SAFECode “Fundamental

is subjected to development Practices”; SAMM; NIST
adversarial security organizations establish SSDF PO.4.1, PW.2.1,
testing techniques. security testing release PW.8.2
gates.

TV.5-2. Software is Though it is not applicable in ISO/IEC 27034; SAFECode

subjected to adversarial all circumstances, fuzzing, or “Fundamental Practices”;
testing techniques, fuzz testing, is recognized as an SAMM; BSIMM; OWASP
including penetration important tool for identifying Testing Guide; NIST SSDF
testing. coding vulnerabilities and PW.8.2
implementation bugs. Fuzz
testing is a recommended testing
technique where applicable.

www.bsa.org 17
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Process and PD.1. Secure PD.1-1. Security Developers should consider the SAMM; Microsoft SDL;
Documentation development requirements for the risk profile of the product when NIST SSDF PO.1.1, PW.8.2
(PD) processes are software are gathered determining the level of detail to
documented from stakeholders and provide in such documentation.
throughout software documented.
development.

PD.1-2. Security SAMM; Microsoft SDL;

guidance for the NIST SSDF PO.1.1
development of the
software is documented.

PD.1-3. Security SAFECode “Fundamental

guidance for the Practices”; BSIMM; NIST
development of software SSDF PO.1.1, RV.3.4
is updated to reflect
the results of root
cause analyses of new
vulnerabilities.

PD.1-4. Testing and SAFECode “Fundamental

validation activities, Practices”; NIST IR 7622;
including results, are NIST SSDF PW.7.2, PW.8.2
documented.

PD.1-5. Software Depending on the development NIST SSDF PO.3.3, PO.4.2,

development process, software developers PO.3.1
organizations maintain may opt to maintain changelogs
an up-to-date product or change histories manually,
history that documents or use automated tools such as
changes to elements and project management software,
configurations. source code management tools,
and configuration management
tools. It is increasingly recognized
as a best practice for software
developers to use automated
tools that are capable of
tracking the origin of code (date,
time, rationale, responsible
individual) on a line-by-line basis.
Developers should consider the
risk profile of the product when
determining the level of detail to
provide in such documentation.

PD.2. Software PD.2-1. A security Microsoft SDL; NIST SSDF

development advisor is assigned to the PO.2.1
personnel are software development
accountable for team.
software security.

PD.2-2. Software BSIMM; SAMM; NIST SSDF

development personnel PO.1.1, PO.2.2
are trained on identified
coding standards
and role-specific best
practices.

18 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Supply Chain SM.1. Software SM.1-1. An NIST IR 7622; NIST SP 800-

(SM) development organizational supply 53; NIST SSDF PW.3.1
is informed by chain management
supply chain risk plan and processes
management. for identification and
reporting of supply
chain incidents are
established.

SM.2. Approved SM.2-1. Information Relevant information may SAFECode “Software

acquisition about providers of third- include the provider’s processes Supply Chain Integrity
measures are in party components is for controlling access to Framework”; BSIMM; NIST
place to ensure the identified and collected. software components, product Interagency Report 7622;
visibility, traceability, development and testing NIST SP 800-53; CWE-505;
and security standards, supply chain risk CWE-506; CWE-507; CWE-
of third-party management practices, 510; CWE-511
components. development environment,
and vulnerability management
processes.

SM.2-2. Software SAFECode “Software

development Supply Chain Integrity
organization employs Framework”; NIST IR 7622;
measures to document NIST SP 800-53; CWE-699;
and, to the extent CWE-506; CWE-507; CWE-
feasible, trace to their 510; CWE-511; NIST SSDF
original source all PW.3.1, PW.4.1
third-party components
directly acquired and
incorporated into
the software by the
developer.

SM.2-3. To the SAFECode “Software

maximum feasible Supply Chain Integrity
through the use of Framework”; NIST IR 7622;
manual and automated NIST SP 800-53; CWE-699;
technologies, CWE-506; CWE-507; CWE-
subcomponents 510; CWE-511; NIST SSDF
integrated in third- PW.4.1
party components
are documented,
and their lineage and
dependencies traced.

SM.2-4. Security SAMM; BSIMM; NIST IR

requirements are 7622; NIST SP 800-53; NIST
incorporated into SSDF PW.3.1
contracts, policies, and
standards for vendors
supplying software
components.

www.bsa.org 19
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Supply Chain SM.3. Supply chain SM.3-1. Supply chain NIST IR 7622
(SM) data — including data is protected at rest.
(continued) information about
software elements,
design, testing,
evaluation, threat
assessments,
delivery processes,
and agreements
language — is
protected against
unauthorized
disclosure, access,
modification,
dissemination,
destruction, and
use.

SM.3-2. Supply chain NIST IR 7622

data is protected
in transit against
unauthorized access.

SM.4. Software SM.4-1. Software SAMM; BSIMM; NIST IR

incorporates includes mechanisms 7622; NIST SP 800-53; NIST
measures to prevent to ensure the integrity SSDF PS.1.1
counterfeiting and of the software, such
tampering. as code-signing, anti-
reverse engineering, or
anti-tamper mechanisms.

SM.4-2. Software BSIMM; NIST IR 7622; NIST

includes supplier SSDF PS.2.1
source certification
or authentication
indicators and protects
those indicators
against tampering and
counterfeiting.

SM.4-3. Identification NIST IR 7622; BSIMM; NIST

markers unique to SP 800-53; NIST SSDF
the software’s specific PS.2.1
version are applied to
each delivered product.

SM.5. The software SM.5-1. The software Descriptive information should ISO/IEC 19770-2; SPDX
is identifiable includes descriptive generally include the software’s Version 2.1; NIST IR 8060;
through clear, information about the name, creator, version, licensing NIST SSDF PS.2.1
discoverable software’s identity. details and, where possible,
information information about the software’s
communicated dependencies.
in a standardized
format.

20 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Supply Chain SM.6. Deployment SM.6-1. The software NIST IR 7622; NIST SSDF
(SM) procedures ensure includes mechanisms to PS.2.1
(continued) that the proper reduce the likelihood
usages of software that it is installed on
are established. unauthorized hardware
or by unauthorized users,
such as validating code-
signing, authentication,
or credentialing.

Development DE.1. The software DE.1-1. Security NIST CSF; ISO 27001; SSAE
Environment development controls and best
(DE) environment, practices are applied
including to the development
information environment based on
systems and data, risk-based frameworks.
is protected against
security threats.

DE.1-2. Internal
code repositories are
protected through
access controls,
monitoring, verification
procedures, and other
best practices.

DE.1-3. Keys for

cryptographic services
used in development,
such as code-signing
tools, are protected
[encrypted] against
compromise.

DE.2. Software is DE.2-1. Software is SAFECode “Fundamental

developed using developed using up-to- Practices”; Microsoft SDL;
tools configured for date versions of all tools OWASP C-Based Tool
security. and platform elements Chain Hardening Cheat
within the development Sheet; CWE-691; CWE-908;
environment. NIST SSDF PO.3.1, PO.3.2,
PW.6.1, PW.6.2, PW.9.1

DE.2-2. Development NCSC; NIST SSDF PO.3.1

frameworks used in
developing software use
secure configurations.

DE.2-3. Compilers are Microsoft SDL; OWASP

configured to prevent Development Guide; CWE-
common vulnerabilities 1038; NIST SSDF PW.6.1,
and weaknesses. PW.6.2

DE.2-4. Compilers are Microsoft SDL; OWASP

configured to avoid Development Guide; CWE-
unintentional removal or 733; CWE-1038; NIST SSDF
modification of security- PW.6.1, PW.6.2
critical code.

www.bsa.org 21
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Development DE.2. Software is DE.2-5. Compilers Microsoft SDL; OWASP

Environment developed using are configured to Development Guide; CWE-
(DE) tools configured for automatically add 1038; NIST SSDF PW.6.1,
(continued) security. defense code. PW.6.2

DE.2-6. Containers BSIMM; NIST SSDF PO.3.2

and other virtualization
technologies used
in deploying the
software use secure
configurations.

Identity IA.1. Throughout IA.1-1. Strong Strong authentication is NCSC: NIST SP 800-53;
and Access the supply chain authentication methods generally understood to describe NIST IR 7622; NIST SSDF
Management and product are required for access mechanisms that require PS.1.1
(IA) lifecycle, to the development authentication factors from at
the software environment. least two of three categories
development (knowledge, or something
environment a user knows; ownership, or
uniquely identifies something a user has; and
and authenticates inherence, or something a user
users. is), but may also utilize contextual
information (e.g., geolocation
or device information) and
other factors to confirm a user’s
identity. Diagnostic Statements in
the IA Category address identity
and access management in the
development environment. See
the SI and AA Categories for
information regarding security
capabilities in software products
themselves.

IA.1-2. User credentials NCSC; NIST SSDF PS.1.1

are stored securely and
revoked or disabled
when no longer needed.

IA.2. Policies to IA.2-1. Specific access SAMM; DHS/DACS; NIST

control access to controls for creation, SSDF PS.1.1
data and processes read access, update,
for all users deletion, and execution
and operators are applied based on
are developed, clearly identified and
documented, and approved user and
applied throughout operator roles.
the development
environment.

22 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE DEVELOPMENT

Identity IA.2. Policies to IA.2-2. Access controls SAMM; DHS/DACS; DoD-

and Access control access to are set for individual PPP; NIST SSDF PS.1.1
Management data and processes users and operators
(IA) for all users that provide only the
(continued) and operators necessary privileges
are developed, required to perform an
documented, and assigned task and only
applied throughout for the necessary time
the development required to perform it.
environment.

IA.2-3. All changes OWASP Logging Cheat

or deletions to code, Sheet; DHS/DACS; NIST IR
development artifacts, 7622; CWE-778; NIST SSDF
and tools are logged, PS.1.1
and unauthorized
changes or deletions are
prevented.

www.bsa.org 23
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Support SI.1. The software SI.1-1. The software ISO/IEC 9798; OWASP
for Identity avoids architectural avoids hard-coded Authentication Cheat
Management weaknesses that passwords. Sheet; CWE-259; CWE-798;
and create risk of NIST SSDF PW.5.1
Authentication authentication
(SI) failure.

SI.1-2. Software source Secrets may include credentials NIST SSDF PW.5.1
code does not contain or keys.
secrets.

SI.1-3. Authentication Industry standard security ISO/IEC 9798; OWASP

mechanisms used by techniques and common Authentication Cheat
the software employ weaknesses are rapidly Sheet; NIST SP 800-63;
industry standard evolving; software development CWE-521; CWE-262; CWE-
security techniques and organizations should stay abreast 263; CWE-620; CWE-308;
avoid common security of current best practices. Current NIST SSDF PW.4.3
weaknesses. common security weaknesses
include allowing insufficiently
complex passwords, insufficient
password aging management,
unlimited log-on attempts,
commonly used password
topologies, and unverified
password changes.

SI.1-4. The software NCSC

does not store
sensitive authentication
information, which may
include passwords or
keys, in source code
or publicly accessible
infrastructure.

SI.1-5. Any passwords or Best practices for password OWASP Password Storage
sensitive authentication storage are rapidly evolving; Cheat Sheet
information stored by software development
the software is stored in organizations should stay abreast
accordance with current of current best practices.
best practices.

SI.2. The SI.2-1. The software ISO/IEC 9798; SAFECode

software supports implements features, “Fundamental Practices”;
strong identity configurations, and NIST SSDF PW.4.3
management and protocols that establish
authentication. or support standard,
tested authentication
services.

SI.2-2. The software OAuth 2.0; OIDC; SAML

is interoperable with 2.0; WS-FED; UAF; U2F;
applicable common SAFECode “Fundamental
industry standards for Practices”; NIST SSDF
identity management PW.4.3
and authentication.

24 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Support SI.2. The SI.2-3. Authentication When authentication controls fail OWASP Secure Coding
for Identity software supports controls fail securely. securely, they prevent access by Practices; NIST SSDF
Management strong identity unauthenticated users even after PW.4.3
and management and encountering an error.
Authentication authentication.
(SI)
(continued)

Patchability PA.1. Software is PA.1-1. Software is The Patchability Category refers NTIA “Voluntary
(PA) capable of receiving capable of validating the to technical aspects relating Framework for Enhancing
secure updates and integrity of a transmitted to the ability of the software Update Process Security”;
security patches. patch or update. to receive secure updates and NIST SP 800-147; CWE-924
patches. Activities of software
developers relating to the
development and dissemination
of updates and patches are
discussed in the Secure Lifecycle
Function.

PA.1-2. Software NTIA “Voluntary

includes a mechanism to Framework for Enhancing
notify end users of patch Update Process Security”
or update installation.

PA.1-3. Software reverts NTIA “Voluntary

to a known-good state Framework for Enhancing
upon failed installation Update Process Security”
of updates or security
patches.

Cryptographic CS.1. Software CS.1-1. Software Software development SAFECode “Fundamental

Services (CS) is developed in enables the use of organizations should stay Practices”; NIST SP 800-
accordance with an encryption to protect abreast of current best practices 57; CWE-311; NIST SSDF
encryption strategy sensitive data from in cryptography and adopt a PW.4.3
that defines what unauthorized disclosure “crypto agile” approach to
data should be or modification. encryption. This ensures that
encrypted and cryptographic modules can
which encryption be replaced or updated as
mechanisms should techniques and vulnerabilities
be used. evolve. Industry publications such
as Microsoft’s SDL Cryptographic
Recommendations provide
information on current industry
best practices.

CS.1-2. Software enables

the use of encryption
to protect the software
itself from tampering.

CS.1-3. Software does OWASP Secure Coding

not expose sensitive Practices; CWE-636; FIPS
data upon failure of 140-2
encryption mechanisms.

www.bsa.org 25
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Cryptographic CS.2. Software CS.2-1. Software avoids In unique circumstances when ISO/IEC 18033-1; ISO/IEC
Services (CS) avoids weak custom encryption a developer identifies a need 19790; FIPS 140-2; FIPS
(continued) encryption. algorithms and to use a custom algorithm or 186-4; FIPS 197; FIPS 202;
implementations. implementation, the developer SAFECode “Fundamental
should establish and document a Practices”; NIST SP 800-
robust procedure to validate the 57; CWE-325; CWE-326;
security of the custom algorithm CWE-327
or implementation prior to
deployment.

CS.2-2. Software enables ISO/IEC 19772; NIST SP

the use of authenticated 800-57; CWE-326; CWE-327
encryption.

CS.2-3. Cryptography Standards for strong algorithms ISO/IEC 18033-1; ISO/IEC

employed by the change over time; in general, 19790; FIPS 140-2; FIPS
software enables strong strong algorithms will have 186-4; FIPS 197; FIPS 202;
algorithms. no structural weaknesses, will SAFECode “Fundamental
maintain key sizes of sufficient Practices”; NIST SP 800-57;
length to defeat brute force CWE-326; CWE-327; CWE-
attacks, and will have been 330; CWE-331; CWE-338
standardized and deployed
across a reasonably sized user
base.

CS.2-4. Cryptography Standards for strong key lengths ISO/IEC 18033-1; ISO/IEC
employed by the will change over time based on 19790; FIPS 140-2; FIPS
software enables strong advancements in computing 186-4; FIPS 197; FIPS 202;
key lengths. power and factoring techniques; SAFECode “Fundamental
in general, strong key lengths Practices”; NIST SP 800-57;
are of sufficient length to ensure CWE-326; CWE-327; CWE-
brute force attacks are infeasible. 330; CWE-331; CWE-338

CS.2-5. Encryption ISO/IEC 18033-1; ISO/IEC

capabilities employed 19790; FIPS 140-2; FIPS
by the software are 186-4; FIPS 197; FIPS 202;
configured to select SAFECode “Fundamental
strong cipher modes and Practices”; NIST SP 800-57;
exclude weak ciphers by CWE-326; CWE-327; CWE-
default. 330; CWE-331; CWE-338

CS.2-6. Software is It may be necessary for CWE-326; CWE-327; CWE-

configured to disable or software to support weak 330; CWE-331; CWE-338;
prevent the use of weak encryption algorithms and NIST SSDF PW.5.1
encryption algorithms key lengths for reasons of
and key lengths. backward compatibility. Where
such support is required,
the implementation should
be carefully engineered and
thoroughly reviewed to ensure
that it does not allow an attacker
to bypass the default or user
selection of strong encryption.

26 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Cryptographic CS.3. Software CS.3-1. Software ensures ISO/IEC 18033-1; ISO/IEC

Services (CS) protects and that cryptographic keys 19790; FIPS 140-2; FIPS
(continued) validates encryption can be securely stored 186-4; FIPS 197; FIPS 202;
keys. and managed, separate SAFECode “Fundamental
from encrypted data. Practices”; NIST SP 800-57

CS.3-2. Software Mechanisms for managing key ISO/IEC 18033-1; ISO/IEC

includes a mechanism and certificate lifecycles may 19790; FIPS 140-2; FIPS
to manage key and include use of third-party key 186-4; FIPS 197; FIPS 202;
certificate lifecycles. management systems. SAFECode “Fundamental
Practices”; NIST SP 800-57;
CWE-324

CS.3-3. Software Not all software uses certificates; CWE-347

includes a mechanism to however, it is imperative
validate certificates. that software that does use
certificates is able to validate the
authenticity of those certificates.
This Diagnostic Statement should
be applied consistent with the
encryption strategy described in
CS.1.

Authorization AA.1. Software AA.1-1. The software SAFECode “Fundamental

and Access design reflects the operates using only Practices”; DoD-PPD;
Controls (AA) principle of least those privileges or CWE-250; CWE-271; CWE-
privilege. permissions necessary 272; CWE-274; NIST SSDF
for software to run PW.2.1
correctly.

AA.1-2. Privileges are SAFECode “Fundamental

set in a configuration Practices”; DoD-PPD;
that is resistant to CWE-250
unauthorized changes.

AA.1-3. An authorization SAFECode “Fundamental

strategy that applies Practices”; CWE-285; CWE-
authorization policies, 862; CWE-863
access controls, and
design principles
to classes of data is
implemented in the
software.

AA.2. The AA.2-1. The software DHS/DACS; NIST SSDF

software’s avoids functions that PW.5.1
design supports enable unauthorized
authorization and privilege escalations.
access controls.

AA.2-2. In the case of OWASP Secure Coding

failure, the software Practices; NIST SSDF
does not grant access PW.5.1
to unauthorized or
unauthenticated users.

www.bsa.org 27
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Logging (LO) LO.1. Software LO.1-1. Software Monitoring logs record data SAFECode “Fundamental
implements logging differentiates between relevant to analyzing usage and Practices”; CWE-779
of all critical security monitoring logs and performance, troubleshooting,
incident and event auditing logs. and informing ongoing software
information. development. Auditing logs
support analysis of and response
to security events.

LO.1-2. Software is Software development OWASP Secure Coding

capable of logging all organizations should determine Practices; OWASP Logging
security-relevant failures, what information is security- Cheat Sheet; CWE-778;
errors, and exceptions. relevant as part of threat- CWE-223
modeling (see SC.1) and risk
assessment.

LO.1-3. Software is SAFECode “Fundamental

capable of logging Practices”; OWASP
timestamp and Logging Cheat Sheet;
identifying information CWE-778
associated with security
incidents and events.

LO.2. Software LO.2-1. Access to logs is OWASP Secure Coding

security incident restricted to authorized Practices; OWASP Logging
and event individuals. Cheat Sheet
information logging
mechanisms are
implemented
securely.

LO.2-2. Logging SAFECode “Fundamental

mechanisms include anti- Practices”; OWASP
tamper protections. Logging Cheat Sheet

LO.2-3. Logs do OWASP Secure Coding

not store sensitive Practices; OWASP Logging
information, such Cheat Sheet; CWE-532
as unnecessary user
information, system
details, session
identifiers, or passwords.

LO.2-4. Software OWASP Secure Coding

logging mechanisms Practices; OWASP Logging
employ input validation Cheat Sheet; CWE-117;
and output encoding. NIST SSDF PW.5.1

28 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE CAPABILITIES

Error and EE.1. Software EE.1-1. Software DHS/DACS; OWASP

Exception integrates error and identifies predictable Code Review Guide: Error
Handling (EE) exception handling exceptions and errors Handling; SAFECode
capabilities. that could occur during “Fundamental Practices”;
software execution CWE-388; CWE-390; CWE-
and defines how the 391; CWE-396; CWE-397;
software will handle each CWE-544; NIST SSDF
instance. PW.5.1

EE.1-2. Software DHS/DACS; OWASP

defines how it will Code Review Guide: Error
handle unpredicted Handling; SAFECode
exceptions and errors “Fundamental Practices”;
and safeguards against CWE-388; CWE-390; CWE-
continued execution in 391; CWE-396; CWE-397;
an insecure state. CWE-544; NIST SSDF
PW.5.1

EE.1-3. Notifications of DHS/DACS; OWASP

errors and exceptions Code Review Guide:
do not disclose sensitive Error Handling; OWASP
technical or human Secure Coding Practices;
information. SAFECode “Fundamental
Practices”; CWE-209

EE.2. Software EE.2-1. Software is DHS/DACS; CWE-636;

fails securely; if a designed to continue NIST SSDF PW.5.1
program is forced operating in a degraded
to terminate manner until a threshold
unexpectedly, it is reached that
shuts down in a safe triggers orderly, secure
and responsible termination.
manner.

EE.2-2. In the case CWE-636; NIST SSDF

of failure, software PW.5.1
reverts to secure default
states that preserve
confidentiality and
integrity.

www.bsa.org 29
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE LIFECYCLE

Vulnerability VM.1. The vendor VM.1-1. The ISO/IEC 29147; ISO/

Management maintains an up-to- vulnerability IEC 30111; SAFECode
(VM) date vulnerability management plan “Fundamental Practices”;
management plan. outlines policies, SAMM; NIST SSDF RV.1.3,
responsibilities, and RV.2.2
expectations for both
internal and external
stakeholders throughout
the following phases
of vulnerability
management: (1) the
vendor’s identification or
receipt of a vulnerability,
(2) verification of
the vulnerability,
(3) remediation or
mitigation of the
vulnerability, (4) release
of a solution, and (5)
post-release.

VM.1-2. The NIST SSDF RV.1.2

vulnerability
management plan
addresses security
testing and vulnerability
identification
methodologies to be
applied throughout a
product’s lifecycle.

VM.1-3. The SAFECode “Fundamental

vulnerability Practices”; SAMM; NIST
management plan SSDF RV.1.1
includes a process for
gaining timely awareness
of and managing
vulnerabilities that are
discovered in third-party
components of the
software.

VM.2. VM.2-1. Upon ISO/IEC 30111; SAFECode

Vulnerabilities identification, “Fundamental Practices”;
are identified and vulnerabilities are SAMM; NIST SSDF RV.1.3,
resolved rapidly and verified and subjected RV.2.1, RV.3.1, RV.3.3
comprehensively, to root cause and risk
according to risk- analysis.
based prioritization.

VM.2-2. Vulnerabilities ISO/IEC 30111; SAFECode

are assigned a unique “Fundamental Practices”;
identification number. NIST SSDF RV.2.1

30 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE LIFECYCLE

Vulnerability VM.2. VM.2-3. Vulnerabilities CVSS; NIST SSDF RV.1.3,

Management Vulnerabilities are assigned a severity RV.2.2
(VM) are identified and value based on risk,
(continued) resolved rapidly and using a standardized
comprehensively, scoring methodology.
according to risk-
based prioritization. VM.2-4. Remediation ISO/IEC 30111; SAFECode
and mitigation “Fundamental Practices”;
activities are informed SAMM; NIST SSDF RV.2.2
by the severity of the
vulnerability.

VM.3. The VM.3-1. The vendor ISO 29147; SAFECode

vendor maintains establishes a clearly “Fundamental Practices”;
a coordinated defined and easily SAMM; ENISA Good
vulnerability accessible intake Practice Guide on
disclosure program. mechanism to accept Vulnerability Disclosure;
vulnerability information IoT Security Foundation
(email, portal, etc.). Vulnerability Disclosure
Best Practice Guidelines;
NIST SSDF RV.1.1

VM.3-2. A vendor’s ISO 29147; SAFECode

intake mechanism “Fundamental Practices”;
provides for secure IoT Security Foundation
and confidential Vulnerability Disclosure
communication of Best Practice Guidelines;
sensitive vulnerability NIST SSDF RV.1.1
information.

VM.3-3. The vendor ISO 29147; ENISA Good

publishes, in simple Practice Guide on
and clear language, its Vulnerability Disclosure;
policies for interacting IoT Security Foundation
with vulnerability Vulnerability Disclosure
reporters, addressing, Best Practice Guidelines
at minimum: (1) how the
vendor would like to be
contacted, (2) options for
secure communication,
(3) expectations for
communication from
the vendor regarding
the status of a reported
vulnerability, (4) desired
information regarding a
potential vulnerability,
(5) issues that are out of
scope of the vulnerability
disclosure program,
(6) how submitted
vulnerability reports
are tracked, and (7)
expectations for whether
and how a reporter will
be credited.

www.bsa.org 31
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE LIFECYCLE

Vulnerability VM.3. The VM.3-4. The vendor ISO 29147; NIST SSDF
Management vendor maintains maintains a system to RV.2.1
(VM) a coordinated record and track all
(continued) vulnerability reports of potential
disclosure program. vulnerabilities.

VM.3-5. The vendor ISO 29147; NIST SSDF

notifies vulnerability RV.1.1
reporters of when
reported vulnerabilities
are remediated or
mitigated.

Configuration CF.1. The software CF.1-1. The software DHS/DACS; NIST SSDF
(CF) is deployed with documentation specifies PW.9.1
configurations configuration parameters
and configuration that are as restrictive
guidance that as feasible, to make
facilitate secure sure the software is as
installation and resistant as possible to
operation. anticipated attacks and
exploits.

CF.1-2. The software BSIMM; DHS/DACS; NIST

documentation SSDF PW.9.2
describes secure
installation procedures
for initial installation and
installation for additional
components, updates,
and patches.

CF.1-3. The software NIST SSDF PW.9.2

documentation
describes configurations
and procedures for
secure configuration
under normal operation.

CF.1-4. The software DHS/DACS; NIST SSDF

prompts users to change PW.5.1
any default passwords
before the software
becomes operational.

CF.1-5. Configuration NIST Special Publication

guidance statements 800-126; NIST SSDF PW.9.2
and configuration
controls are clearly
communicated and
automated wherever
possible.

32 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE LIFECYCLE

Configuration CF.1. The software CF.1-6. Software User configuration may not NIST SSDF PW.9.1; PW.9.2
(CF) is deployed with configuration settings always be possible or necessary.
(continued) configurations can be altered to tailor However, where viable, the
and configuration security settings to the software should be delivered in a
guidance that operating environment. configuration that is as secure as
facilitate secure possible based on its anticipated
installation and usage, and should support the
operation. ability of users to modify security
settings to accommodate
changing environments or
requirements.

Vulnerability VN.1. Vendors VN.1-1. Patches or ISO/IEC 30111; SAFECode

Notification disseminate updates are developed “Fundamental Practices”;
and Patching timely patches or and disseminated DHS/DACS; Microsoft SDL;
(VN) updates to address based on risk-informed SAMM; NIST SSDF RV.2.2
identified security prioritization, in
issues. accordance with the
vendor’s vulnerability
management program.

VN.1-2. Patches or DHS/DACS; Microsoft SDL;

updates are subjected to NIST SSDF RV.2.2
testing for functionality
and security prior to
release.

VN.1-3. All patches DHS/DACS; NIST SSDF

and updates are RV.2.2
documented.

VN.1-4. Development ISO/IEC 30111; FIRST

and dissemination of “Guidelines and Practices
patches or updates for Multi-Party Vulnerability
are coordinated with Coordination and
other vendors where Disclosure”; NIST SSDF
appropriate to address RV.1.1; RV.2.2
multi-vendor security
issues or supply chain
security issues.

VN.2. Patches VN.2-1. Patches or NTIA “Voluntary

or updates are updates are transmitted Framework for Enhancing
disseminated in a manner that Update Process Security”
securely. prevents exposure of the
software image.

VN.2-2. The patch or ISO/IEC 29147; NTIA

update deliverable is “Voluntary Framework for
cryptographically signed Enhancing Update Process
to ensure its integrity Security”
and authenticity.

www.bsa.org 33
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Relevant Standards and

Category Subcategory Diagnostic Statement Comments on Implementation Informative Resources

SECURE LIFECYCLE

Vulnerability VN.3. Patches VN.3-1. Users are SAFECode “Fundamental

Notification or updates for notified of a significant Practices”
and Patching security issues are security issue when a
(VN) accompanied by remediation is in place
(continued) advisory messages for each supported
informing users version of the affected
of relevant product.
information.
VN.3-2. Advisory ISO/IEC 29147; SAFECode
messages notifying “Fundamental Practices”
users of security issues
include information
on affected products,
applicable versions,
and platforms; a unique
identification number;
and a brief description of
the vulnerability and its
potential impact.

End-of-Life (EL) EL.1. Vendor EL.1-1. Vendor

maintains consistent communicates realistic
lifecycle guidance. assumptions and
expectations regarding
the nature and lifespan
of product support
in tandem with initial
software delivery.

EL.1-2. Vendor clearly

communicates decisions
to terminate support
for a software product
to customers and users,
identifying the expected
support termination
date; the anticipated
risk of continued
product use beyond the
termination of support;
possible mitigation
actions; and options for
technical migration to
replacement products.

EL.1-3. Software is
continually monitored
to ensure that third-
party components have
not reached end-of-
life milestones or are
removed or otherwise
remediated.

34 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

IV. References

Definitions
Access Control. Means to ensure that access to assets is Patch. A modification made directly to an object
authorized and restricted based on business and security program without reassembling or recompiling from the
requirements. (Source: ISO/IEC 27000: 2018) source program, or a software component that, when
installed, directly modifies files or device settings related
Algorithm. A finite set of well-defined rules for the to a different software component without changing the
solution of a problem in a finite number of steps, version number or release details for the related software
sequence of operations for performing a specific task, or component. (Source: ISO/IEC 19770-2: 2015)
finite ordered set of well-defined rules for the solution of
a problem. (Source: ISO/IEC/IEEE 24765: 2017) Penetration testing. A test method in which the security
of a computer program or network is subjected to
Authentication. Provision of assurance that a claimed deliberate simulated attack. (Source: Microsoft Security
characteristic of an entity is correct. (Source: ISO/IEC Development Lifecycle Process Guidance Version 5.2)
27000: 2018)
Release gate. A specific point established in the
Control. A measure that is modifying risk. Controls software development lifecycle where a project may not
include any process, policy, device, practice, or other move forward until it meets certain security conditions
actions that modify risk. (Source: ISO/IEC 27000: 2018) established by an organization at the project’s inception.
Error. Discrepancy between a computed, observed, or (Adapted from Software Assurance Maturity Model,
measured value or condition and the true, specified, or Version 1.0)
theoretically correct value or condition. (Source: ISO/IEC Risk. An expression of the effect of uncertainty on
15026-1: 2019) cybersecurity objectives, as understood through the
Exception. An event that causes suspension of normal analysis of identified threats to a product or system,
program execution, or an indication that an operation the known vulnerabilities of that product or system,
request was not performed successfully. (Source: ISO/ and the potential consequences of the compromise
IEC/IEEE 24765: 2017) of the product or system. (Source: BSA International
Cybersecurity Policy Framework)
Fault isolation. The ability of a subsystem to prevent a
fault within the subsystem from causing consequential Sandboxing. A restricted, controlled execution
faults in other subsystems. (Source: ISO/IEC/IEEE 24765: environment that prevents potentially malicious
2017) software, such as mobile code, from accessing any
system resources except those for which the software
Fuzzing. A means of testing that causes a software is authorized. (Source: Committee on National Security
program to consume deliberately malformed data to Systems No. 4009)
see how the program reacts. (Source: Microsoft Security
Development Lifecycle Process Guidance Version 5.2) Software. All or part of the programs that process or
support the processing of digital information. (Source:
Lifecycle. States involved in the management of an asset; ISO/IEC 12207: 2017)
evolution of a system, product, service, project, or other
human-made entity from conception through retirement. Third-party components. Components of a software
(Sources: ISO/IEC 12207: 2017; ISO/IEC 27034: 2011) project of external origin, including open-source
components, purchased commercial off-the-shelf
Mitigation. The process of remediating a weakness, software, and online services used by the software
leaving the software in a more secure state. (Source: project. (Adapted from Software Assurance Maturity
Common Weakness Enumeration/MITRE) Model, Version 1.5)

www.bsa.org 35
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Threat modeling. A systematic exploration technique to Vulnerability. Weakness of software, hardware, or online
expose any circumstance or event having the potential service that can be exploited. (Source: ISO/IEC 30111:
to cause harm to a system in the form of destruction, 2013)
disclosure, modification of data, or denial of service.
(Source: ISO/IEC/IEEE 24765: 2017) Weakness. A type of mistake in software that, in proper
conditions, could contribute to the introduction of
vulnerabilities within that software. (Source: Common
Weakness Enumeration/MITRE)

Acronyms
BSIMM Building Security in Maturity Model, NIST SP NIST Special Publication
Version 11
NTIA National Telecommunications and
CAPEC Common Attack Pattern Enumeration Information Administration
and Classification
NVD National Vulnerability Database
CVSS Common Vulnerability Scoring
System OAuth Initiative for Open Authentication

CWSS Common Weakness Scoring System OIDC OpenID Connect

DHS/DACS Department of Homeland Security/ OWASP Open Web Application Security

Data & Analysis Center for Software, Project
Enhancing the Development Life
SAFECode SAFECode Fundamental Practices
Cycle to Produce Secure Software,
“Fundamental for Secure Software Development,
Version. 2.0
Practices” Version 3.0
DoD-PPP Department of Defense, “Software
SAML Security Assertion Markup Language
Assurance Countermeasures in
Program Protection Planning” SAMM Software Assurance Maturity Model,
Version 1.5
FIPS Federal Information Processing
Standards SEI Carnegie Mellon University’s Software
Engineering Institute
ISO/IEC International Organization for
Standardization/International SPDX Software Package Data Exchange,
Electrotechnical Commission Version 2.1
Microsoft SDL Microsoft’s Security Development SSAE AICPA, Statement on Standards for
Lifecycle Process Guidance, Version Attestation Engagements, No. 18
5.2
SSDF NIST, Secure Software Development
NCSC United Kingdom National Cyber Framework (White Paper)
Security Centre Secure Development
and Deployment Guidance U2F Universal Second Factor

NIST National Institute for Standards and UAF Universal Authentication Framework
Technology
WS-FED Web Services Federation Language,
NIST IR NIST Interagency Report Version 1.2

36 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

Sources
Adobe, Adobe Secure Engineering Overview, March FIDO Alliance, Universal Authentication Framework
2018. https://www.adobe.com/content/dam/acom/en/ Architectural Overview, Version 1.1, February 2, 2017.
security/pdfs/adobe-secure-engineering-wp.pdf. https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/
fido-uaf-overview-v1.1-id-20170202.html.
American Institute of Certified Professional Accountants
(AICPA) Auditing Standards Board, Statement on Forum for Incident Response and Security Teams,
Standards for Attestation Engagements (SSAE), No. 18, Common Vulnerability Scoring System: Specification
April 2016. https://www.aicpa.org/content/dam/aicpa/ Document, Version 3.0. https://www.first.org/cvss/cvss-
research/standards/auditattest/downloadabledocuments/ v30-specification-v1.8.pdf.
ssae-no-18.pdf.
Forum for Incident Response and Security Teams,
Box, Box Platform Guidelines and Security. https:// Guidelines and Practices for Multi-Party Vulnerability
developer.box.com/docs/security-guidelines. Coordination and Disclosure, Version 1.0, Summer
2017. https://www.first.org/global/sigs/vulnerability-
BSA | The Software Alliance, BSA International coordination/multiparty/FIRST-Multiparty-Vulnerability-
Cybersecurity Policy Framework. https://bsacybersecurity. Coordination-latest.pdf?20180320.
bsa.org/wp-content/uploads/2018/04/BSA_
cybersecurity-policy.pdf. Howard, Michael and Steve Lipner, The Security
Development Lifecycle: A Process for Developing
Carnegie Mellon University Software Engineering Demonstrably More Secure Software, 2006, Redmond,
Institute, SEI CERT C Coding Standard: Rules for WA: Microsoft Press.
Developing Safe, Reliable, and Secure Systems, 2016
Edition, June 2016. https://resources.sei.cmu.edu/library/ IBM, Security in Development: The IBM Secure
asset-view.cfm?assetID=454220. Engineering Framework, 2010. https://www.redbooks.
ibm.com/redpapers/pdfs/redp4641.pdf.
Carnegie Mellon University Software Engineering
Institute, SEI CERT C++ Coding Standard: Rules for Initiative for Open Authentication, OAuth 2.0, October
Developing Safe, Reliable, and Secure Systems, 2016 2012. https://oauth.net/2/.
Edition, March 2017. https://resources.sei.cmu.edu/
library/asset-view.cfm?assetID=494932. International Organization of Standardization,
Information Technology—IT Asset Management—Parts
Carnegie Mellon University Software 1–2, ISO/IEC 19770 (1: 2017–2: 2015).
Engineering Institute, SEI CERT Oracle Coding
Standard for Java, October 11, 2016. https:// International Organization of Standardization, Information
wiki.sei.cmu.edu/confluence/display/java/ Technology—Security Techniques—Information Security
SEI+CERT+Oracle+Coding+Standard+for+Java. Management Systems—Overview and Vocabulary, ISO/
IEC 27000: 2018.
Committee on National Security Systems (CNSS),
Committee on National Security Systems Glossary, CNSS International Organization of Standardization,
Instruction No. 4009, April 6, 2015. Information Technology—Security Techniques—Entity
Authentication—Parts 1–3, ISO/IEC 9798- (1: 2010–3:
European Union Agency for Network and Information 2019).
Security, Good Practice Guide on Vulnerability
Disclosure, January 18, 2016. https://www.enisa.europa. International Organization of Standardization,
eu/publications/vulnerability-disclosure. Information Technology—Programming Languages, Their
Environments and System Software Interfaces—C Secure
FIDO Alliance, Universal 2nd Factor Overview, April Coding Rules, ISO/IEC TS 17961: 2013.
11, 2017. https://fidoalliance.org/specs/fido-u2f-v1.2-
ps-20170411/fido-u2f-overview-v1.2-ps-20170411.pdf. International Organization of Standardization,
Information Technology—Security Techniques—
Encryption Algorithms—Parts 1–5, ISO/IEC 18033 (1:
2015–5: 2015).

www.bsa.org 37
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

International Organization of Standardization, Information MITRE Corporation, Common Weakness Enumeration,

Technology—Security Techniques—Authenticated Version 3.2. https://cwe.mitre.org/data/index.html.
Encryption, ISO/IEC 19772: 2009.
MITRE Corporation, Common Weakness Scoring System,
International Organization of Standardization, Version 1.0.1, September 5, 2014. https://cwe.mitre.org/
Information Technology—Security Techniques—Security cwss/cwss_v1.0.1.html.
Requirements for Cryptographic Modules, ISO/IEC
19790: 2012. MITRE Corporation and the SANS Institute, CWE/SANS
Top 25 Most Dangerous Software Errors, Version 1.0.3,
International Organization of Standardization, Information September 13, 2011. https://cwe.mitre.org/top25/
Technology—Security Techniques—Application Security; archive/2011/2011_cwe_sans_top25.pdf.
Parts 1–7, ISO/IEC 27034 (1:2011–7:2018).
OASIS, Security Assertion Markup Language, Version
International Organization of Standardization, Information 2.0, March 25, 2008. http://docs.oasis-open.org/security/
Technology—Security Techniques—Vulnerability saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.pdf.
Disclosure, ISO/IEC 29147: 2018, October 23, 2018.
OASIS, Web Services Federation Language, Version
International Organization of Standardization, 1.2, May 22, 2009. http://docs.oasis-open.org/wsfed/
Information Technology—Security Techniques— federation/v1.2/os/ws-federation-1.2-spec-os.html.
Vulnerability Handling Processes, ISO/IEC 30111: 2019,
October 1, 2019. Okta, Okta Security Technical White Paper. https://
www.okta.com/sites/default/files/Okta%20Technical%20
International Organization of Standardization, Systems Security%20Whitepaper.pdf.
and Software Engineering—Software Lifecycle Processes,
ISO/IEC/IEEE 12207: 2017. Open ID Foundation, Open ID Connect, Version 1.0,
November 8, 2014. https://openid.net/connect/.
International Organization of Standardization, Systems
and Software Engineering—Systems and Software Open Web Application Security Project (OWASP),
Assurance—Part 1: Concepts and Vocabulary, ISO/IEC/ Application Security Verification Standard, Version 3.0,
IEEE 15026 (1: 2019). October 2015. https://www.owasp.org/images/6/67/
OWASPApplicationSecurityVerificationStandard3.0.pdf.
International Organization of Standardization, Systems
and Software Engineering—Vocabulary, ISO/IEC/IEEE Oracle, Security Practices: Oracle Software Security
24765: 2017. Assurance. https://www.oracle.com/corporate/security-
practices/assurance/.
IoT Security Foundation, Vulnerability Disclosure:
Best Practice Guidelines, Release 1.1, December OWASP, Attack Surface Analysis Cheat Sheet. https://
2017. https://iotsecurityfoundation.org/wp-content/ github.com/OWASP/CheatSheetSeries/blob/master/
uploads/2017/01/Vulnerability-Disclosure.pdf. cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md.

The Linux Foundation, Software Package Data Exchange, OWASP, Authentication Cheat Sheet. https://github.com/
Specification Version 2.1, 2016. https://spdx.org/sites/ OWASP/CheatSheetSeries/blob/master/cheatsheets/
cpstandard/files/pages/files/spdxversion2.1.pdf. Authentication_Cheat_Sheet.md.

Microsoft, Security Development Lifecycle: SDL Process OWASP, C-Based Toolchain Hardening Cheat Sheet.
Guidance, Version 5.2, May 23, 2012. https://www. https://github.com/OWASP/CheatSheetSeries/blob/
microsoft.com/en-us/download/details.aspx?id=29884. master/cheatsheets/C-Based_Toolchain_Hardening_
Cheat_Sheet.md.
Migues, Sammy, John Steven, and Mike Ware, Building
Security In Maturity Model (BSIMM), Version 11, 2020. OWASP, Code Review Guide, Version 2.0, July 2017.
https://www.bsimm.com. https://www.owasp.org/images/5/53/OWASP_Code_
Review_Guide_v2.pdf.
MITRE Corporation, Common Attack Pattern
Enumeration and Classification, Version 3.0. https://
capec.mitre.org/data/index.html.

38 BSA | The Software Alliance

 The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

OWASP, Development Guide, Version 2.0.1, June SAFECode, The Software Supply Chain Integrity
2014. https://github.com/OWASP/DevGuide/tree/ Framework: Defining Risks and Responsibilities for
dc5a2977a4797d9b98486417a5527b9f15d8a251/ Securing Software in the Global Supply Chain, July
DevGuide2.0.1. 21, 2009. http://safecode.org/publication/SAFECode_
Supply_Chain0709.pdf.
OWASP, Input Validation Cheat Sheet. https://
github.com/OWASP/CheatSheetSeries/blob/master/ SAFECode, Tactical Threat Modeling, May 2017. https://
cheatsheets/Input_Validation_Cheat_Sheet.md. safecode.org/wp-content/uploads/2017/05/SAFECode_
TM_Whitepaper.pdf.
OWASP, Logging Cheat Sheet. https://github.com/
OWASP/CheatSheetSeries/blob/master/cheatsheets/ Salesforce, Secure Coding Guide, Version 49.0, August
Logging_Cheat_Sheet.md. 20, 2020. https://resources.docs.salesforce.com/latest/
latest/en-us/sfdc/pdf/secure_coding.pdf.
OWASP, OWASP Top 10 — 2017: The Ten Most
Critical Web Application Security Risks, 2017. https:// United Kingdom National Cyber Security Centre Secure,
www.owasp.org/images/7/72/OWASP_Top_10- Guidance for Secure Development and Deployment,
2017_%28en%29.pdf.pdf. December 11, 2017. https://www.ncsc.gov.uk/guidance/
secure-development-and-deployment.
OWASP, Password Storage Cheat Sheet. https://
github.com/OWASP/CheatSheetSeries/blob/master/ United States Department of Defense, “Software
cheatsheets/Password_Storage_Cheat_Sheet.md. Assurance Countermeasures in Program Protection
Planning,” March 2014. https://www.acq.osd.mil/se/
OWASP, Secure Coding Practices Quick Reference docs/swa-cm-in-ppp.pdf.
Guide, Version 2.0, November 2010. https://www.owasp.
org/images/0/08/OWASP_SCP_Quick_Reference_Guide_ United States Department of Homeland Security/
v2.pdf. Data & Analysis Center for Software, Enhancing the
Development Life Cycle to Produce Secure Software,
OWASP, Software Assurance Maturity Model, Version 1.5, Version. 2.0, October 2008. http://www.seas.upenn.
April 2017. https://owaspsamm.org/v1-5/downloads/. edu/~lee/09cis480/papers/DACS-358844.pdf.
OWASP, Testing Guide, Version 4.0, September 2014. United States National Institute for Standards
https://www.owasp.org/images/1/19/OTGv4.pdf. and Technology, BIOS Protection Guidelines:
OWASP, Threat Modeling Cheat Sheet. https:// Recommendations of the National Institute of Standards
github.com/OWASP/CheatSheetSeries/blob/master/ and Technology, Special Publication 800-147, April
cheatsheets/Threat_Modeling_Cheat_Sheet.md. 2011. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-147.pdf.
SAFECode, Fundamental Practices for Secure Software
Development, Third Edition, March 2018. https:// United States National Institute for Standards and
safecode.org/wp-content/uploads/2018/03/SAFECode_ Technology, Digital Identity Guidelines, Special
Fundamental_Practices_for_Secure_Software_ Publication 800-63-3, June 2017. https://nvlpubs.nist.
Development_March_2018.pdf. gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf.

SAFECode, Fundamental Practices for Secure Software United States National Institute for Standards and
Development, Second Edition, February 2011. https:// Technology, Federal Information Processing Standards.
safecode.org/publication/SAFECode_Dev_Practices0211. https://www.nist.gov/standardsgov/compliance-faqs-
pdf. federal-information-processing-standards-fips.

SAFECode, Managing Security Risks Inherent in the Use United States National Institute for Standards and
of Third-Party Components, 2017. https://safecode. Technology, Guidelines for the Creation of Interoperable
org/wp-content/uploads/2017/05/SAFECode_TPC_ Software Identification (SWID) Tags, Interagency Report
Whitepaper.pdf. 8060, April 2016. https://nvlpubs.nist.gov/nistpubs/
ir/2016/NIST.IR.8060.pdf.

www.bsa.org 39
The BSA Framework for Secure Software: A New Approach to Securing the Software Lifecycle

United States National Institute for Standards

and Technology, Mitigating the Risk of Software
Vulnerabilities by Adopting a Secure Software
Development Framework, White Paper, April 23, 2020.

United States National Institute for Standards and

Technology, National Vulnerability Database. https://nvd.
nist.gov/.

United States National Institute for Standards and

Technology, Notional Supply Chain Risk Management
Practices for Federal Information Systems, Interagency
Report 7622, October 2012. https://csrc.nist.gov/
publications/detail/nistir/7622/final.

United States National Institute for Standards and

Technology, Recommendation for Key Management:
Part I: General, Special Publication 800-57, Revision 5,
May 2020. https://csrc.nist.gov/publications/detail/
sp/800-57-part-1/rev-5/final.

United States National Institute for Standards and

Technology, Security and Privacy Controls for Federal
Information Systems and Organizations, Special
Publication 800-53, Revision 4, April 2013. https://
nvlpubs.nist.gov/nistpubs/specialpublications/nist.
sp.800-53r4.pdf.

United States National Institute for Standards and

Technology, The Technical Specification for the Security
Content Automation Protocol, Special Publication 800-
126, Revision 3, February 2018. https://nvlpubs.nist.gov/
nistpubs/SpecialPublications/NIST.SP.800-126r3.pdf.

United States National Telecommunications and

Information Administration, Voluntary Framework for
Enhancing Update Process Security, October 31, 2017.
https://www.ntia.doc.gov/files/ntia/publications/ntia_iot_
capabilities_oct31.pdf.

40 BSA | The Software Alliance

www.bsa.org

BSA Worldwide Headquarters BSA Asia-Pacific BSA Europe, Middle East & Africa
20 F Street, NW 300 Beach Road 44 Avenue des Arts
Suite 800 #25-08 The Concourse Brussels 1040
Washington, DC 20001 Singapore 199555 Belgium

+1.202.872.5500 +65.6292.2072 +32.2.274.13.10

@BSAnews
@BSATheSoftwareAlliance