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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Framework Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Implementing the Framework for Secure Software. . . . . . . 10

III. BSA Framework for Secure Software . . . . . . . . . . . . . . . 12

IV. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
 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, The Framework is intended to focus on software
and policymakers are increasingly seeking ways of products (including Software-as-a-Service) by considering
assessing and encouraging security across the software both the process by which a software development
lifecycle. While standards and guidelines exist to aid organization develops and manages software products
and inform developers in achieving these goals, there and the security capabilities of those products. It is
is no consolidated framework that brings together best intended to complement, rather than replace, guidance
practices in a manner that can be effectively measured, for organizational risk management processes. To
regardless of the development environment or the the greatest extent possible, it seeks alignment with
purpose of the software. BSA | The Software Alliance has recognized international standards and to remain flexible,
developed The BSA Framework for Secure Software (the adaptable, outcome-focused, and risk-based.
“Framework”) to fill that gap.
The Framework is intended to become a living
Specifically, the Framework is intended to be used to document, to be updated and improved based on
help software development organizations: ongoing feedback from BSA’s members and other
(1) describe the current state of software security in relevant stakeholders.
individual software products;
(2) describe the target state of software security in
individual software products;
(3) identify and prioritize opportunities for improvement
in development and lifecycle management
processes;
(4) assess progress toward the target state; and
(5) communicate among internal and external
stakeholders about software security and security
risks.

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 based, cost-effective, and repeatable. Eschewing a one-
are emerging that help software developers address size-fits-all solution, this voluntary framework will provide
important aspects of software security, including a common organization and structure to capture multiple
security-by-design principles, secure development approaches to software security by identifying standards,
lifecycle processes, and internationally recognized guidelines, and practices that can help software
standards for key security elements such as identity development organizations achieve desired security
management, encryption, and secure coding. Although outcomes while accounting for the wide spectrum of
attention to each specific security consideration can intended uses, risk profiles, and technological solutions
achieve marginal security gains, effective security among software products.
requires a comprehensive and risk-informed approach
that combines individual considerations into a holistic, Recent technological developments illustrate the
lifecycle-long framework. And a comprehensive approach increasing ubiquity of software and the need for a
must be tailored to address the nuanced, diverse, and flexible, comprehensive software security framework.
evolving challenges associated with different types of Software-powered capabilities are rapidly expanding
software and connected devices, from the “bare metal” from desktop computers and industrial systems into
to the most advanced. nearly every corner of personal lives and business
activities, including diverse personal devices, widespread
Building on best practices pioneered by many of its sensors, 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
security that is flexible, adaptable, outcome-focused, risk-

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

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

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” such definitions may suggest that the level of security
associated with a given software product could be
Software security encompasses what a software ascertained simply by measuring the presence and extent
development organization does to protect a software of defects or vulnerabilities in its code base, software
product and the associated critical data from security is rarely that straightforward.
vulnerabilities, internal and external threats, critical
errors, or misconfigurations that can affect performance One challenge is that — at least currently — it is
or expose data. It comprises both organizational impractical to expect complex software code to be
processes and product capabilities. entirely free of vulnerabilities. Indeed, according to some
estimates, software products currently average roughly
Organizational processes include governance 1–5 defects per 1,000 lines of code, with many complex
structures, strategies, guidance, and clearly defined software products incorporating tens or hundreds of
procedures that guide the development of software millions of lines of code in total.3 While defect-free code
in a manner that identifies and incorporates security should always be a developer’s goal, it is not a realistic
objectives throughout a product’s lifecycle, protects industry standard. Instead, the goal should be the
the integrity of the development environment, widespread adoption of practices and processes that
applies resources to incident and vulnerability minimize code defects, and particularly known software
management, and manages the supply chain that vulnerabilities, and to maintain a proactive security
supports the software development project. posture oriented to identifying and addressing problems
before they can be exploited. In fact, researchers have
Product security capabilities are technical aspects
documented substantial improvements in average
of specific software products that are useful in
software defect density among leading software
enabling the products to address common security
developers through the implementation of secure
challenges, such as protecting data, preventing
development lifecycle approaches and other software
unauthorized access or use, tracking incidents and
security best practices.
vulnerabilities, and managing unforeseen events.
A second challenge is that any approach to software
Both organizational processes and product security
security that is distilled into a test or series of tests at a
capabilities are vital elements of software security.
single point in time is inherently flawed. As developers
Software security is often discussed in relation to increasingly adopt iterative approaches to development,
software assurance. Software assurance has been incorporate third-party components, and face evolving
defined1 as the “level of confidence that software is free security threats, a software product may change
from vulnerabilities, either intentionally designed into the continually and substantially over its lifecycle. Testing
software or accidentally inserted at any time during its methodologies undergo evolution as well; for example,
lifecycle, and that the software functions in the intended the set of known software vulnerabilities assessed
manner.” It has also been defined2 as “the development by certain testing methodologies may be frequently
and implementation of methods and processes for updated to include newly discovered flaws. Security
ensuring that software functions as intended and is free is a persistent requirement; while software testing is a
of design defects and implementation flaws.” While critical element of secure development, it is not a stand-

1
https://www.hsdl.org/?view&did=7447
2
https://safecode.org/wp-content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Development_March_2018.pdf
3
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

in for a sustained, security-focused approach to lifecycle Framework Basics

management.
The Framework identifies best practices relating to
Other models exist for informing or assessing both organizational processes and product capabilities
software security. Some of these models, including across the entire software lifecycle. It is organized into
SAFECode’s Fundamental Practices for Secure Software six columns: Functions, Categories, Subcategories,
Development, the Software Assurance Maturity Model, Diagnostic Statements, Implementation Notes, and
and various secure software development lifecycle Informative References.
methodologies, serve as important starting points
for the Framework described in this document. They Functions organize fundamental software security
provide detailed guidance, informed by broad industry activities at their highest level, consistent with the
best practices, on a wide range of considerations software lifecycle. The Functions are:
organizations should address to maximize their ability
to produce secure software in a verifiable, repeatable, SECURE DEVELOPMENT
transparent manner. However, in many cases, these
guidance documents lack specificity and are primarily
Secure development addresses security in the phase
targeted toward organizations, focusing almost
of software development when a software project
exclusively on organizational approaches, processes,
is conceived, initiated, developed, and brought to
and methodologies that collectively constitute the input
market
of software development. They offer limited guidance
on security considerations in relation to the output of
software development; that is, the software product. SECURE CAPABILITIES

The Framework takes the approach of defining software

Secure capabilities identify key security characteristics
security by considering both input and output; that is,
recommended for a software product
it includes considerations of organizational processes
that guide how vendors approach the development and
maintenance of a software product as well as security SECURE LIFECYCLE
capabilities and considerations relevant to the product
itself. Moreover, it provides this guidance at a level of Secure lifecycle addresses considerations for
detail that is specific enough to be measurable, without maintaining security in a software product from its
compromising the flexibility necessary to ensure that all development through the end of its life
organizations can tailor the guidance according to the
type, use, and associated risk of a software product.
Categories divide a Function into distinct considerations
The Framework is intended to apply to all types of and disciplines relevant to the Function. Many Categories
software. Yet, because of the tremendous diversity in are fundamentally interwoven with other Categories;
types of software, software development processes, and for example, the “Vulnerability Management” and
risks, some security considerations will be more relevant “Vulnerability Notification and Patching” Categories are
to certain types of software than others. Moreover, conceptually closely related, as successful vulnerability
organizations will vary in how they customize approaches management necessarily involves vulnerability
to achieving the outcomes described in the Framework. notification and patching. However, the Categories
The Framework is intended as a tool to create a common seek to distill best practices into distinct subjects or
language for discussions about how software approaches disciplines; in this example, “Vulnerability Management”
security, enabling stakeholders to hone in on the security provides guidance for organizational processes to
outcomes most relevant to the circumstances. Rather identify, prioritize, and mitigate vulnerabilities, whereas
than serving as a box-checking exercise, such a common “Vulnerability Notification and Patching” identifies best
language enables organizations to describe how they practices for developing and issuing patches, mitigations,
approach a specific security outcome or why that and notifications to customers. Categories within the
outcome may not be applicable to their product. same Function may involve different communities of

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

By “software development organizations,” the Framework intends to address all parts of an

organization involved in the design, development, deployment, and maintenance of software,
recognizing that each organization must determine how it can assign roles and responsibilities to
most effectively achieve desired security outcomes.

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

6 BSA | The Software Alliance

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

Framework Purpose

The Framework is intended to be used to help software development organizations:

1 2 3 4 5
Describe the Describe the Identify and Assess progress Communicate
current state of target state of prioritize toward the among internal
software security software security opportunities target state. and external
in individual in individual for improvement stakeholders
software software in development about software
products. products. and lifecycle security and
management security risks.
processes.

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

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

8 BSA | The Software Alliance

 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.

validating that such measures are not needed based on constant innovation of new technologies, processes,
the product’s risk and architecture. and standards in the software industry. For that reason,
approaches to software security that mandate specific
technical measures or that endeavor to subject software
Adaptable.
products to batteries of tests that assess security at
In today’s development context, software is constantly a single point in time will fail to keep pace with the
changing. Many products are continually updated constant evolution of software. Instead, this Framework
with new features and additional security measures provides a tool to assess the characteristics of software
long after their original market deployment. For that security throughout a software product’s lifecycle,
reason, software security must be conceptualized in a using outcome-focused diagnostic statements that are
way that is adaptable to this lifecycle, as well as to the adaptable to diverse and evolving technical approaches.

www.bsa.org 9
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.

Aligned with Internationally Recognized standards, which sets out guidance on “integrating
Standards. security seamlessly throughout the lifecycle” of software
applications.
Internationally recognized technical standards provide
widely vetted, consensus-based information and
guidance for defining and implementing effective Implementing the Framework for
approaches to cybersecurity and facilitate common
approaches to common challenges, thus enabling
Secure Software
collaboration and interoperability. Industry leaders have The Framework is designed to support the systematic
developed a range of international standards and best processes used by software development organizations
practices for secure-by-design software development. to identify, assess, and minimize cybersecurity risk
To ensure international interoperability and express throughout the lifecycle of software products. Using
consensus best practices, the Framework seeks to align, the Framework as a cybersecurity risk management
to the greatest extent possible, with internationally tool, an organization can establish a holistic secure
recognized technical standards wherever they exist. development lifecycle that identifies likely risks, enables
Currently, the most notable example relevant to secure conscientious decisions about risk mitigation and risk
software development is the ISO/IEC 27034 series of tolerance, improves software quality, and prepares the

10 BSA | The Software Alliance

 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.

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

www.bsa.org 11
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.

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
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

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”

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

12 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.2. Software SC.2-1. Standards are ISO/IEC TS 17961; SEI
(SC) is developed formally identified and CERT C Coding Standard;
(continued) according to documented. SEI CERT C++ Coding
recognized, Standard; SEI CERT Java
enforceable coding Coding Standard; NCSC
standards.

SC.2-2. Software uses SAFECode “Fundamental

canonical data formats. Practices”; CWE-21; CWE-
22; CWE-35; CWE-36;
CWE-37; CWE-38; CWE-39;
CWE-40

SC.3. The SC.3-1. Software avoids, Software should avoid known NIST NVD; CWE/SANS
software is secure or includes documented vulnerabilities to the greatest Top 25 Most Dangerous
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
and unsafe libraries. libraries. functions or libraries known
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

SC.3-3. Software SAFECode “Fundamental

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

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

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

SC.4-2. The software DoD-PPP

employs fault isolation
mechanisms.

www.bsa.org 13
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.4. Standard SC.4-3. The software DoD-PPP; OWASP

(SC) software assurance employs system element Application Security
(continued) measures are isolation mechanisms. Verification Standard
employed in
the software SC.4-4. Software Where errors in integer SAFECode “Fundamental
architecture and uses robust integer computation cannot result in Practices”; CWE-129; CWE-
design. operations for dynamic security-relevant errors, use of 131; CWE-190; CWE-680;
memory allocations and robust integer operations may CWE-805
array offsets. not be necessary.

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
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

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 to guide implemented and integrated OWASP Testing Guide;
is conducted. software development. with the software development OWASP Code Review
process to ensure rigor and Guide
consistency. Manual tools can
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
functionality and
security of software TV.3-2. The software is SAFECode “Fundamental
is established. tested in a least privilege Practices”
environment.

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
adversarial security organizations establish
testing techniques. security testing release
gates.

TV.5-2. Software is ISO/IEC 27034; SAFECode

subjected to penetration “Fundamental Practices”;
testing. SAMM; BSIMM; OWASP
Testing Guide

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

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
(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
development of the
software is documented.

PD.1-3. Security SAFECode “Fundamental

guidance for the Practices”; BSIMM
development of software
is updated to reflect
the results of root
cause analyses of new
vulnerabilities.

PD.1-4. Security Microsoft SDL

documentation outlining
best practices for
software use by end-
users and developers
is made available
electronically.

PD.1-5. Testing and SAFECode “Fundamental

validation activities, Practices”; NIST IR 7622
including results, are
documented.

PD.1-6. Software Depending on the development

development process, software developers
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.

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

Process and PD.2. Software PD.2-1. A security Microsoft SDL

Documentation development advisor is assigned to the
(PD) personnel are software development
accountable for team.
software security.

PD.2-2. Software BSIMM; SAMM

development personnel
are trained on identified
coding standards
and role-specific best
practices.

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

(SM) development organizational supply 800-53
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-505;
and, to the extent CWE-506; CWE-507; CWE-
feasible, trace to their 510; CWE-511
original source all
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-505;
technologies, CWE-506; CWE-507; CWE-
subcomponents 510; CWE-511
integrated in third-
party components
are documented,
and their lineage and
dependencies traced.

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

Supply Chain SM.2. Approved SM.2-4. Security SAMM; BSIMM; NIST IR

(SM) acquisition requirements are 7622; NIST SP 800-53
(continued) measures are in incorporated into
place to ensure the contracts, policies, and
visibility, traceability, standards for vendors
and security supplying software
of third-party components.
components.

SM.3. Supply chain SM.3-1. Supply chain NIST IR 7622

data — including data is protected at rest.
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
measures to prevent to ensure the integrity
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

includes supplier
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
the software’s specific
version are applied to
each delivered product.

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

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

SM.6. Deployment SM.6-1. The software NIST IR 7622

procedures ensure includes mechanisms to
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.

Tool Chain (TC) TC.1. Software is TC.1-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.

TC.1-2. Development NCSC

frameworks used in
developing software use
secure configurations.

TC.1-3. Compilers are Microsoft SDL; OWASP

configured to prevent Development Guide; CWE-
common vulnerabilities 1038
and weaknesses.

TC.1-4. Compilers are Microsoft SDL; OWASP

configured to avoid Development Guide; CWE-
unintentional removal or 733; CWE-1038
modification of security-
critical code.

TC.1-5. Compilers Microsoft SDL; OWASP

are configured to Development Guide; CWE-
automatically add 1038
defense code.

TC.1-6. Containers BSIMM

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

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

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
Management and product are required for access mechanisms that require
(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 and operators. 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 and NCSC

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

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

control access to controls for creation,
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.

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

are set for individual PPP
users and operators
that provide only the
necessary privileges
required to perform an
assigned task and only
for the necessary time
required to perform it.

IA.2-3. Unauthorized OWASP Logging Cheat

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

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 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
Authentication authentication
(SI) failure.

SI.1-2. Software source Secrets may include credentials

code does not contain or keys.
secrets.

SI.1-3. Authentication Typical techniques and common ISO/IEC 9798; OWASP

mechanisms used by the weaknesses are rapidly Authentication Cheat
software employ typical evolving; software development Sheet; NIST SP 800-63;
security techniques and organizations should stay abreast CWE-521; CWE-262; CWE-
avoid common security of current best practices. Current 263; CWE-620; CWE-308
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
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”
identity management
and authentication.

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 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
Management strong identity unauthenticated users even after
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.

Encryption (EN) EN.1. Software EN.1-1. Software SAFECode “Fundamental

is developed in enables the use of Practices”; OWASP
accordance with an encryption to protect Cryptographic Storage
encryption strategy sensitive data from Cheat Sheet; NIST SP 800-
that defines what unauthorized disclosure. 57; CWE-311
data should be
encrypted and
which encryption
mechanisms should
be used.

EN.1-2. Software
enables the use of
encryption to protect
the software itself from
tampering.

EN.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 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 CAPABILITIES

Encryption (EN) EN.2. Software EN.2-1. Software avoids In unique circumstances when ISO/IEC 18033-1; ISO/IEC
(continued) avoids weak custom encryption a developer identifies a need 19790; FIPS 140-2; FIPS
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”; OWASP
robust procedure to validate the Cryptographic Storage
security of the custom algorithm Cheat Sheet; NIST SP 800-
or implementation prior to 57; CWE-325; CWE-326;
deployment. CWE-327

EN.2-2. Software ISO/IEC 19772; OWASP

enables the use Cryptographic Storage
of authenticated Cheat Sheet; NIST SP 800-
encryption. 57; CWE-326; CWE-327

EN.2-3. Encryption 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”; OWASP
length to defeat brute force Cryptographic Storage
attacks, and will have been Cheat Sheet; NIST SP
standardized and deployed 800-57; CWE-326; CWE-
across a reasonably sized user 327; CWE-330; CWE-331;
base. CWE-338

EN.2-4. Encryption 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”; OWASP
are of sufficient length to ensure Cryptographic Storage
brute force attacks are infeasible. Cheat Sheet; NIST SP
800-57; CWE-326; CWE-
327; CWE-330; CWE-331;
CWE-338

EN.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”; OWASP
exclude weak ciphers by Cryptographic Storage
default. Cheat Sheet; NIST SP
800-57; CWE-326; CWE-
327; CWE-330; CWE-331;
CWE-338

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 CAPABILITIES

Encryption (EN) EN.2. Software EN.2-6. Software is It may be necessary for CWE-326; CWE-327; CWE-
(continued) avoids weak configured to disable or software to support weak 330; CWE-331; CWE-338
encryption. prevent the use of weak encryption algorithms and
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.

EN.3. Software EN.3-1. Software ISO/IEC 18033-1; ISO/IEC

protects and ensures that 19790; FIPS 140-2; FIPS
validates encryption cryptographic keys can 186-4; FIPS 197; FIPS 202;
keys. be securely stored and SAFECode “Fundamental
managed, separate from Practices”; OWASP
encrypted data. Cryptographic Storage
Cheat Sheet; NIST SP
800-57

EN.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”; OWASP
Cryptographic Storage
Cheat Sheet; NIST SP 800-
57; CWE-324

EN.3-3. Software Not all software uses certificates; OWASP Cryptographic

includes a mechanism to however, it is imperative Storage Cheat Sheet;
validate certificates. that software that does use CWE-347
certificates is able to validate the
authenticity of those certificates.
This diagnostic statement should
be applied consistent with the
encryption strategy described in
EN.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
for software to run
correctly.

AA.1-2. Privileges are SAFECode “Fundamental

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

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

Authorization AA.1. Software AA.1-3. An authorization SAFECode “Fundamental

and Access design reflects the strategy that applies Practices”; CWE-285; CWE-
Controls (AA) principle of least authorization policies, 862; CWE-863
(continued) privilege. access controls, and
design principles
to classes of data is
implemented in the
software.

AA.2. The AA.2-1. The software DHS/DACS

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

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

failure, the software Practices
does not grant access
to unauthorized or
unauthenticated users.

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

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

Logging (LO) LO.2. Software LO.2-3. Logs do OWASP Secure Coding

(continued) security incident not store sensitive Practices; OWASP Logging
and event information, such Cheat Sheet; CWE-532
information logging as unnecessary user
mechanisms are information, system
implemented details, session
securely. 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.

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
instance.

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

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
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

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

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 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
responsibilities, and
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
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
management plan
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
resolved rapidly and verified and subjected
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.

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 LIFECYCLE

Vulnerability VM.2. VM.2-3. Vulnerabilities CVSS

Management Vulnerabilities are assigned a severity
(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
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

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
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 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 LIFECYCLE

Vulnerability VM.3. The VM.3-4. The vendor ISO 29147

Management vendor maintains maintains a system to
(VM) a coordinated record and track all
(continued) vulnerability reports of potential
disclosure program. vulnerabilities.

VM.3-5. The vendor ISO 29147

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

Configuration CF.1. The software CF.1-1. The software DHS/DACS

(CF) is deployed with documentation specifies
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

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

CF.1-3. The software

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

CF.1-4. The software DHS/DACS

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

CF.1-5. Configuration NIST Special Publication

guidance statements 800-126
and configuration
controls are clearly
communicated and
automated wherever
possible.

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 LIFECYCLE

Configuration CF.1. The software CF.1-6. Software User configuration may not
(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
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
testing for functionality
and security prior to
release.

VN.1-3. All patches DHS/DACS

and updates are
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”
appropriate to address
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 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 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

maintain 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.

30 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 Mitigation. The process of remediating a weakness,
authorized and restricted based on business and security leaving the software in a more secure state. (Source:
requirements. (Source: ISO/IEC 27000: 2018) Common Weakness Enumeration/MITRE)

Algorithm. A finite set of well-defined rules for the Patch. A modification made directly to an object
solution of a problem in a finite number of steps, program without reassembling or recompiling from the
sequence of operations for performing a specific task, or source program, or a software component that, when
finite ordered set of well-defined rules for the solution of installed, directly modifies files or device settings related
a problem. (Source: ISO/IEC/IEEE 24765: 2017) to a different software component without changing the
version number or release details for the related software
Authentication. Provision of assurance that a claimed component. (Source: ISO/IEC 19770-2: 2015)
characteristic of an entity is correct. (Source: ISO/IEC
27000: 2018) Penetration testing. A test method in which the security
of a computer program or network is subjected to
Control. A measure that is modifying risk. Controls deliberate simulated attack. (Source: Microsoft Security
include any process, policy, device, practice, or other Development Lifecycle Process Guidance Version 5.2)
actions that modify risk. (Source: ISO/IEC 27000: 2018)
Release gate. A specific point established in the
Error. Discrepancy between a computed, observed, or software development lifecycle where a project may not
measured value or condition and the true, specified, or move forward until it meets certain security conditions
theoretically correct value or condition. (Source: ISO/IEC established by an organization at the project’s inception.
15026-1: 2019) (Adapted from Software Assurance Maturity Model,
Exception. An event that causes suspension of normal Version 1.0)
program execution, or an indication that an operation Risk. An expression of the effect of uncertainty on
request was not performed successfully. (Source: ISO/ cybersecurity objectives, as understood through the
IEC/IEEE 24765: 2017) analysis of identified threats to a product or system,
Fault isolation. The ability of a subsystem to prevent a the known vulnerabilities of that product or system,
fault within the subsystem from causing consequential and the potential consequences of the compromise
faults in other subsystems. (Source: ISO/IEC/IEEE 24765: of the product or system. (Source: BSA International
2017) Cybersecurity Policy Framework)

Fuzzing. A means of testing that causes a software Sandboxing. A restricted, controlled execution
program to consume deliberately malformed data to environment that prevents potentially malicious
see how the program reacts. (Source: Microsoft Security software, such as mobile code, from accessing any
Development Lifecycle Process Guidance Version 5.2) system resources except those for which the software
is authorized. (Source: Committee on National Security
Lifecycle. States involved in the management of an asset; Systems No. 4009)
evolution of a system, product, service, project, or other
human-made entity from conception through retirement. Software. All or part of the programs that process or
(Sources: ISO/IEC 12207: 2017; ISO/IEC 27034: 2011) support the processing of digital information. (Source:
ISO/IEC 12207: 2017)

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

Third-party components. Components of a software disclosure, modification of data, or denial of service.

project of external origin, including open-source (Source: ISO/IEC/IEEE 24765: 2017)
components, purchased commercial off-the-shelf
software, and online services used by the software Vulnerability. Weakness of software, hardware, or online
project. (Adapted from Software Assurance Maturity service that can be exploited. (Source: ISO/IEC 30111:
Model, Version 1.5) 2013)

Threat modeling. A systematic exploration technique to Weakness. A type of mistake in software that, in proper
expose any circumstance or event having the potential conditions, could contribute to the introduction of
to cause harm to a system in the form of destruction, vulnerabilities within that software. (Source: Common
Weakness Enumeration/MITRE)

Acronyms
BSIMM Building Security in Maturity Model, NIST IR NIST Interagency Report
Version 9
NIST SP NIST Special Publication
CAPEC Common Attack Pattern Enumeration
and Classification NTIA National Telecommunications and
Information Administration
CVSS Common Vulnerability Scoring
System NVD National Vulnerability Database

CWSS Common Weakness Scoring System OAuth Initiative for Open Authentication

DHS/DACS Department of Homeland Security/ OIDC OpenID Connect

Data & Analysis Center for Software,
OWASP Open Web Application Security
Enhancing the Development Life
Project
Cycle to Produce Secure Software,
Version. 2.0. SAFECode SAFECode Fundamental Practices
“Fundamental for Secure Software Development,
DoD-PPP Department of Defense, “Software
Practices” Version 3.0
Assurance Countermeasures in
Program Protection Planning” SAML Security Assertion Markup Language
FIPS Federal Information Processing SAMM Software Assurance Maturity Model,
Standards Version 1.5
ISO/IEC International Organization for SEI Carnegie Mellon University’s Software
Standardization/International Engineering Institute
Electrotechnical Commission
SPDX Software Package Data Exchange,
Microsoft SDL Microsoft’s Security Development Version 2.1
Lifecycle Process Guidance, Version
5.2 U2F Universal Second Factor

NCSC United Kingdom National Cyber UAF Universal Authentication Framework

Security Centre Secure Development
WS-FED Web Services Federation Language,
and Deployment Guidance
Version 1.2
NIST National Institute for Standards and
Technology

32 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 Forum for Incident Response and Security Teams,
2018. https://www.adobe.com/content/dam/acom/en/ Common Vulnerability Scoring System: Specification
security/pdfs/adobe-secure-engineering-wp.pdf. Document, Version 3.0. https://www.first.org/cvss/cvss-
v30-specification-v1.8.pdf.
Apple, Secure Coding Guide. https://developer.apple.
com/library/archive/documentation/Security/Conceptual/ Forum for Incident Response and Security Teams,
SecureCodingGuide/Introduction.html. Guidelines and Practices for Multi-Party Vulnerability
Coordination and Disclosure, Version 1.0, Summer
Box, Box Platform Guidelines and Security. https:// 2017. https://www.first.org/global/sigs/vulnerability-
developer.box.com/docs/security-guidelines. coordination/multiparty/FIRST-Multiparty-Vulnerability-
BSA | The Software Alliance, BSA International Coordination-latest.pdf?20180320.
Cybersecurity Policy Framework. https://bsacybersecurity. Howard, Michael and Steve Lipner, The Security
bsa.org/wp-content/uploads/2018/04/BSA_ Development Lifecycle: A Process for Developing
cybersecurity-policy.pdf. Demonstrably More Secure Software, 2006, Redmond,
Carnegie Mellon University Software Engineering WA: Microsoft Press.
Institute, SEI CERT C Coding Standard: Rules for IBM, Security in Development: The IBM Secure
Developing Safe, Reliable, and Secure Systems, 2016 Engineering Framework, 2010. https://www.redbooks.
Edition, June 2016. https://resources.sei.cmu.edu/library/ ibm.com/redpapers/pdfs/redp4641.pdf.
asset-view.cfm?assetID=454220.
Initiative for Open Authentication, OAuth 2.0, October
Carnegie Mellon University Software Engineering 2012. https://oauth.net/2/.
Institute, SEI CERT C++ Coding Standard: Rules for
Developing Safe, Reliable, and Secure Systems, 2016 International Organization of Standardization,
Edition, March 2017. https://resources.sei.cmu.edu/ Information Technology—IT Asset Management—Parts
library/asset-view.cfm?assetID=494932. 1–2, ISO/IEC 19770 (1: 2017–2: 2015).

Carnegie Mellon University Software International Organization of Standardization, Information

Engineering Institute, SEI CERT Oracle Coding Technology—Security Techniques—Information Security
Standard for Java, October 11, 2016. https:// Management Systems—Overview and Vocabulary, ISO/
wiki.sei.cmu.edu/confluence/display/java/ IEC 27000: 2018.
SEI+CERT+Oracle+Coding+Standard+for+Java.
International Organization of Standardization,
Committee on National Security Systems (CNSS), Information Technology—Security Techniques—Entity
Committee on National Security Systems Glossary, CNSS Authentication—Parts 1–3, ISO/IEC 9798- (1: 2010–3:
Instruction No. 4009, April 6, 2015. https://www.cnss. 2019).
gov/CNSS/issuances/Instructions.cfm.
International Organization of Standardization,
European Union Agency for Network and Information Information Technology—Programming Languages, Their
Security, Good Practice Guide on Vulnerability Environments and System Software Interfaces—C Secure
Disclosure, January 18, 2016. https://www.enisa.europa. Coding Rules, ISO/IEC TS 17961: 2013.
eu/publications/vulnerability-disclosure.
International Organization of Standardization,
FIDO Alliance, Universal 2nd Factor Overview, April Information Technology—Security Techniques—
11, 2017. https://fidoalliance.org/specs/fido-u2f-v1.2- Encryption Algorithms—Parts 1–5, ISO/IEC 18033 (1:
ps-20170411/fido-u2f-overview-v1.2-ps-20170411.pdf. 2015–5: 2015).

FIDO Alliance, Universal Authentication Framework International Organization of Standardization, Information

Architectural Overview, Version 1.1, February 2, 2017. Technology—Security Techniques—Authenticated
https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/ Encryption, ISO/IEC 19772: 2009.
fido-uaf-overview-v1.1-id-20170202.html.

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

International Organization of Standardization, MITRE Corporation, Common Weakness Scoring System,

Information Technology—Security Techniques—Security Version 1.0.1, September 5, 2014. https://cwe.mitre.org/
Requirements for Cryptographic Modules, ISO/IEC cwss/cwss_v1.0.1.html.
19790: 2012.
MITRE Corporation and the SANS Institute, CWE/SANS
International Organization of Standardization, Information Top 25 Most Dangerous Software Errors, Version 1.0.3,
Technology—Security Techniques—Application Security; September 13, 2011. https://cwe.mitre.org/top25/
Parts 1–7, ISO/IEC 27034 (1:2011–7:2018). archive/2011/2011_cwe_sans_top25.pdf.

International Organization of Standardization, Information OASIS, Security Assertion Markup Language, Version
Technology—Security Techniques—Vulnerability 2.0, March 25, 2008. http://docs.oasis-open.org/security/
Disclosure, ISO/IEC 29147: 2018, October 23, 2018. saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.pdf.

International Organization of Standardization, Information OASIS, Web Services Federation Language, Version
Technology—Security Techniques—Vulnerability 1.2, May 22, 2009. http://docs.oasis-open.org/wsfed/
Handling Processes, ISO/IEC 30111: 2013(E), November federation/v1.2/os/ws-federation-1.2-spec-os.html.
1, 2013.
Okta, Okta Security Technical White Paper. https://
International Organization of Standardization, Systems www.okta.com/sites/default/files/Okta%20Technical%20
and Software Engineering—Software Lifecycle Processes, Security%20Whitepaper.pdf.
ISO/IEC/IEEE 12207: 2017.
Open ID Foundation, Open ID Connect, Version 1.0,
International Organization of Standardization, Systems November 8, 2014. https://openid.net/connect/.
and Software Engineering—Systems and Software
Assurance—Part 1: Concepts and Vocabulary, ISO/IEC/ Open Web Application Security Project (OWASP),
IEEE 15026 (1: 2019). Application Security Verification Standard, Version 3.0,
October 2015. https://www.owasp.org/images/6/67/
International Organization of Standardization, Systems OWASPApplicationSecurityVerificationStandard3.0.pdf.
and Software Engineering—Vocabulary, ISO/IEC/IEEE
24765: 2017. Oracle, Security Practices: Oracle Software Security
Assurance. https://www.oracle.com/corporate/security-
IoT Security Foundation, Vulnerability Disclosure: practices/assurance/.
Best Practice Guidelines, Release 1.1, December
2017. https://iotsecurityfoundation.org/wp-content/ OWASP, Attack Surface Analysis Cheat Sheet. https://
uploads/2017/01/Vulnerability-Disclosure.pdf. github.com/OWASP/CheatSheetSeries/blob/master/
cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md.
The Linux Foundation, Software Package Data Exchange,
Specification Version 2.1, 2016. https://spdx.org/sites/ OWASP, Authentication Cheat Sheet. https://github.com/
cpstandard/files/pages/files/spdxversion2.1.pdf. OWASP/CheatSheetSeries/blob/master/cheatsheets/
Authentication_Cheat_Sheet.md.
McGraw, Gary, Sammy Migues, and Jacob West, Building
Security in Maturity Model (BSIMM), Version 9, 2018. OWASP, C-Based Toolchain Hardening Cheat Sheet.
https://www.bsimm.com. https://github.com/OWASP/CheatSheetSeries/blob/
master/cheatsheets/C-Based_Toolchain_Hardening_
Microsoft, Security Development Lifecycle: SDL Process Cheat_Sheet.md.
Guidance, Version 5.2, May 23, 2012. https://www.
microsoft.com/en-us/download/details.aspx?id=29884. OWASP, Code Review Guide, Version 2.0, July 2017.
https://www.owasp.org/images/5/53/OWASP_Code_
MITRE Corporation, Common Attack Pattern Review_Guide_v2.pdf.
Enumeration and Classification, Version 3.0. https://
capec.mitre.org/data/index.html. OWASP, Cryptographic Storage Cheat Sheet. https://
github.com/OWASP/CheatSheetSeries/blob/master/
MITRE Corporation, Common Weakness Enumeration, cheatsheets/Cryptographic_Storage_Cheat_Sheet.md.
Version 3.2. https://cwe.mitre.org/data/index.html.

34 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 45.0, January
Logging_Cheat_Sheet.md. 30, 2019. https://resources.docs.salesforce.com/218/
latest/en-us/sfdc/pdf/secure_coding.pdf.
OWASP, OWASP Top 10 — 2017: The Ten Most
Critical Web Application Security Risks, 2017. https:// Symantec, “Executive Summary: Symantec Software
www.owasp.org/images/7/72/OWASP_Top_10- Security Process,” 2019. https://www.symantec.com/
2017_%28en%29.pdf.pdf. content/dam/symantec/docs/other-resources/symantec_
software_security_process.pdf.
OWASP, Password Storage Cheat Sheet. https://
github.com/OWASP/CheatSheetSeries/blob/master/ United Kingdom National Cyber Security Centre Secure,
cheatsheets/Password_Storage_Cheat_Sheet.md. Guidance for Secure Development and Deployment,
December 11, 2017. https://www.ncsc.gov.uk/guidance/
OWASP, Secure Coding Practices Quick Reference secure-development-and-deployment.
Guide, Version 2.0, November 2010. https://www.owasp.
org/images/0/08/OWASP_SCP_Quick_Reference_Guide_ United States Department of Defense, “Software
v2.pdf. Assurance Countermeasures in Program Protection
Planning,” March 2014. https://www.acq.osd.mil/se/
OWASP, Software Assurance Maturity Model, Version 1.5, docs/swa-cm-in-ppp.pdf.
April 2017. https://owaspsamm.org/v1-5/downloads/.
United States Department of Homeland Security/
OWASP, Testing Guide, Version 4.0, September 2014. Data & Analysis Center for Software, Enhancing the
https://www.owasp.org/images/1/19/OTGv4.pdf. Development Life Cycle to Produce Secure Software,
OWASP, Threat Modeling Cheat Sheet. https:// Version. 2.0, October 2008. http://www.seas.upenn.
github.com/OWASP/CheatSheetSeries/blob/master/ edu/~lee/09cis480/papers/DACS-358844.pdf.
cheatsheets/Threat_Modeling_Cheat_Sheet.md. United States National Institute for Standards
SAFECode, Fundamental Practices for Secure Software and Technology, BIOS Protection Guidelines:
Development, Third Edition, March 2018. https:// Recommendations of the National Institute of Standards
safecode.org/wp-content/uploads/2018/03/SAFECode_ and Technology, Special Publication 800-147, April
Fundamental_Practices_for_Secure_Software_ 2011. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
Development_March_2018.pdf. nistspecialpublication800-147.pdf.

SAFECode, Fundamental Practices for Secure Software United States National Institute for Standards and
Development, Second Edition, February 2011. https:// Technology, Digital Identity Guidelines, Special
safecode.org/publication/SAFECode_Dev_Practices0211. Publication 800-63-3, June 2017. https://nvlpubs.nist.
pdf. gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf.

SAFECode, Managing Security Risks Inherent in the Use United States National Institute for Standards and
of Third-Party Components, 2017. https://safecode. Technology, Federal Information Processing Standards.
org/wp-content/uploads/2017/05/SAFECode_TPC_ https://www.nist.gov/standardsgov/compliance-faqs-
Whitepaper.pdf. federal-information-processing-standards-fips.

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

United States National Institute for Standards and

Technology, Guidelines for the Creation of Interoperable
Software Identification (SWID) Tags, Interagency Report
8060, April 2016. https://nvlpubs.nist.gov/nistpubs/
ir/2016/NIST.IR.8060.pdf.

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
4, January 2016. https://nvlpubs.nist.gov/nistpubs/
SpecialPublications/NIST.SP.800-57pt1r4.pdf.

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.

36 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 65 Petty France
Suite 800 #25-08 The Concourse Ground Floor
Washington, DC 20001 Singapore 199555 London, SW1H 9EU
United Kingdom
+1.202.872.5500 +65.6292.2072
+44.207.340.6080
@BSAnews @BSAnewsAPAC
@BSAnewsEU
@BSATheSoftwareAlliance