Bsimm10 PDF

Sammy Migues, John Steven,
& Mike Ware

BSIMM10 LICENSE
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license,
visit http://creativecommons.org/licenses/by-sa/3.0/legalcode or send a letter to Creative Commons, 171 Second Street,
Suite 300, San Francisco, California, 94105, USA.
PAGE 2 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

EXECUTIVE SUMMARY
KEY TAKEAWAYS FOR BSIMM10:
1. The BSIMM data show DevOps adoption is now far enough along to affect the way we approach software
security as an industry.
2. Engineering-led security culture has shown itself to be a means of establishing and growing meaningful
software security efforts in some organizations, whereas it struggled to do so even just a few years ago.
3. We adjusted the descriptions of several activities to reflect what we observed firms doing to integrate software
security within their digital transformation and also added three new activities related to these efforts.
4. The three activities added for BSIMM10 show a clear arc: software-defined lifecycle governance, software-
assisted monitoring of software-defined asset creation, and automated verification of software-defined
infrastructure, which show that some organizations are actively working on ways to speed up security to
match the speed with which the business delivers functionality to market.
5. Organizations demonstrably improve over time, and many achieve a level of maturity where they focus on the
depth, breadth, and scale of the activities they’re conducting rather than always striving for more activities.
6. In this BSIMM release, we use observation data to demonstrate a path from emerging through maturing to
optimizing a software security initiative over time.
The BSIMM is the result of a multiyear study of real-world software security initiatives (SSIs). We present the BSIMM10
model as built directly out of data observed in 122 firms. These firms are listed in the Acknowledgments section.
The BSIMM is a measuring stick for software security. The best way to use it is to compare and contrast your own
initiative with the data about what other organizations are doing. You can identify your own goals and objectives, then
refer to the BSIMM to determine which additional activities make sense for you.
The purpose of the BSIMM is to quantify the activities carried out by various kinds of SSIs. Because these initiatives
use different methodologies and different terminology, the BSIMM requires a framework that allows us to describe
any initiative in a uniform way. Our software security framework (SSF) and activity descriptions provide a common
vocabulary for explaining the salient elements of an SSI, thereby allowing us to compare initiatives that use different
terms, operate at different scales, exist in different parts of the organizational chart, operate in different vertical markets,
or create different work products.
The BSIMM data show that high maturity initiatives are well-rounded, carrying out numerous activities in all 12 of the
practices described by the model. The data also show how maturing SSIs evolve, change, and improve over time.
We classify the BSIMM as a maturity model because improving software security almost always means changing the
way an organization works, which doesn’t happen overnight. We understand that not all organizations need to achieve
the same security goals, but we believe all organizations can benefit from using a common measuring stick. The BSIMM
is not a traditional maturity model where a set of activities are repeated at multiple levels of depth and breadth—do
something at level 1, do it more at level 2, do it better at level 3, and so on. Instead, the BSIMM comprises a single set of
unique activities, and the activity levels are used only to distinguish the relative frequency with which the activities are
observed in organizations. Frequently observed activities are designated as “level 1,” less frequently observed activities are
designated “level 2,” and infrequently observed activities are designated “level 3.”
We hold the scorecards for individual firms in confidence, but we publish aggregate data describing the number of times
we have observed each activity (see the BSIMM10 Scorecard in Part Two). We also publish observations about subsets
(such as industry verticals) when our sample size for the subset is large enough to guarantee anonymity.
BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 3

ACKNOWLEDGMENTS
Our thanks to the 122 executives from the world-class software security initiatives we studied from
around the world to create BSIMM10, including those who choose to remain anonymous.
Adobe Depository Trust & Medtronic

Aetna Clearing Corporation Morningstar
Alibaba Eli Lilly Navient
Ally Bank Ellucian NCR
Amadeus Experian NetApp
Amgen F-Secure News Corp
Autodesk Fannie Mae NVIDIA
Axway Fidelity PayPal
Bank of America Freddie Mac Principal Financial Group
Betfair General Electric Royal Bank of Canada
BMO Financial Group Genetec Scientific Games
Black Duck Software Global Payments Synopsys
Black Knight Financial Services HCA Healthcare TD Ameritrade
Box Highmark Health Solutions The Home Depot
Canadian Imperial Bank Horizon Healthcare Services, Inc. The Vanguard Group
of Commerce HSBC Trainline
Capital One iPipeline Trane
City National Bank Johnson & Johnson U.S. Bank
Cisco JPMorgan Chase & Co. Veritas
Citigroup Lenovo Verizon
Citizen’s Bank LGE Wells Fargo
Comerica Bank McKesson Zendesk
Dahua
Our thanks also to the more than 100 individuals who helped gather the data for the BSIMM.
In particular, we thank Matthew Chartrand, Sagar Dongre, Michael Doyle, Eli Erlikhman, Jacob Ewers, Stephen
Gardner, Nabil Hannan, Iman Louis, Daniel Lyon, Nick Murison, Alistair Nash, Kevin Nassery, Donald Pollicino, and
Denis Sheridan. In addition, we give a special thank you to Kathy Clark-Fisher, whose behind-the-scenes work keeps the
BSIMM science project, conferences, and community on track.
Data for the BSIMM were captured by Synopsys. Resources for BSIMM10 data analysis were provided by ZeroNorth.
BSIMM1–BSIMM3 were authored by Gary McGraw, Ph.D., Brian Chess, Ph.D., and Sammy Migues. BSIMM4–
BSIMM9 were authored by Gary McGraw, Ph.D., Sammy Migues, and Jacob West. BSIMM10 was authored
by Sammy Migues, Mike Ware, and John Steven.

BSIMM10 TABLE OF CONTENTS
PART ONE: BACKGROUND
BSIMM History.........................................................6 Deployment............................................................ 58

The Model .................................................................6 • Deployment: Penetration Testing (PT)
• Deployment: Software Environment (SE)
Creating BSIMM10 from BSIMM9........................... 7
• Deployment: Configuration Management &
Roles in a Software Security Initiative......................8 Vulnerability Management (CMVM)
• Executive Leadership
• Software Security Group (SSG) APPENDIX
• Satellite Building a Model for Software Security..................63
• Everybody Else
The BSIMM as a Longitudinal Study.......................65
Measuring Your Firm with the BSIMM................... 12
Charts, Graphs, and Scorecards............................. 70
Using the BSIMM to Start or Improve an SSI......... 14
Comparing Verticals................................................. 81
• How to Use This Section
• SSI Cultures 119 BSIMM Activities at a Glance.......................... 85
• Waypoints Along Your Journey
• Governance-led Cultures
• Maturing Governance-led SSIs BSIMM10 LIST OF TABLES
• Emerging Engineering-led Cultures BSIMM10 ExampleFirm Scorecard........................................... 13
• Maturing Engineering-led SSIs BSIMM10 Scorecard.................................................................. 33
BSIMM Numbers Over Time.................................................... 64
PART TWO: BSIMM10 BSIMM10 Reassessments Scorecard
The BSIMM10 Framework. ...................................... 27 Round 1 vs. Round 2............................................................. 65
The BSIMM10 Skeleton...........................................28 BSIMM10 Reassessments Scorecard
Round 1 vs. Round 3............................................................. 68
What BSIMM10 Tells Us..........................................32 BSIMM Skeleton Expanded Version......................................... 70
BSIMM10 and Industry Verticals Analysis. . ............35 Most Common Activities Per Practice..................................... 78
Emerging Trends in the BSIMM10 Data.................39 Top 20 Activities by Observation Count...................................79
Vertical Comparison Scorecard.................................................. 81
PART THREE: BSIMM10 ACTIVITIES
Governance............................................................. 40 BSIMM10 LIST OF FIGURES
• Governance: Strategy & Metrics (SM) ExampleFirm Spider Chart......................................................... 14
• Governance: Compliance & Policy (CP) BSIMM10 Participants............................................................... 32
• Governance: Training (T) AllFirms Spider Chart................................................................. 34
Intelligence..............................................................47 Cloud vs. Internet of Things vs. Tech Spider Chart.................. 35
• Intelligence: Attack Models (AM) Financial vs. Healthcare vs. Insurance Spider Chart................ 36
• Intelligence: Security Features & Design (SFD) Tech vs. Healthcare Spider Chart...............................................37
• Intelligence: Standards & Requirements (SR) AllFirms vs. Retail Spider Chart................................................ 38
Round 1 AllFirms vs. Round 2 AllFirms Spider Chart............. 66
SSDL Touchpoints....................................................53 Round 1 AllFirms vs. Round 3 AllFirms Spider Chart............. 69
• SSDL Touchpoints: Architecture Analysis (AA) BSIMM Score Distribution........................................................80
• SSDL Touchpoints: Code Review (CR)
• SSDL Touchpoints: Security Testing (ST)

PART ONE: BACKGROUND
The BSIMM is now in its tenth iteration. In this section, we talk about its history and the underlying model, as well as
the changes we made for BSIMM10. We describe the roles we typically see in an SSI and some related terminology.
We conclude this section with guidance on how to use the BSIMM to start, mature, and measure your own SSI.
BSIMM HISTORY
We built the first version of the BSIMM a little over a decade ago (Fall 2008) as follows:
• We relied on our own knowledge of software security practices to create the software security framework
(SSF, found in Part Two).
• We conducted a series of in-person interviews with nine executives in charge of software security initiatives
(SSIs). From these interviews, we identified a set of common activities, which we organized according to
the SSF.
• We then created scorecards for each of the nine initiatives that showed which activities the initiatives carry
out. To validate our work, we asked each participating firm to review the framework, the practices, and the
scorecard we created for their initiative.
Today, we continue to evolve the model by looking for new activities as participants are added and as current participants
are remeasured. We also adjust the model according to observation rates for each of the activities.
THE MODEL
The BSIMM is a data-driven model that evolves over time. We have added, deleted, and adjusted the levels of various
activities based on the data observed as the project has evolved. To preserve backward compatibility, we make all changes
by adding new activity labels to the model, even when an activity has simply changed levels (e.g., we add a new CRx.x
label for both new and moved activities in the Code Review practice). When considering whether to add a new activity,
we analyze whether the effort we’re observing is truly new to the model or simply a variation on an existing activity. When
considering whether to move an activity between levels, we use the results of an intralevel standard deviation analysis and
the trend in observation counts.
We use an in-person interview technique to conduct BSIMM assessments, done with a total of 185 firms so far. In
addition, we conducted assessments for nine organizations who have rejoined the data pool after once aging out. In 46
cases, we assessed the software security group (SSG) and one or more business units as part of creating the corporate
SSI view.
For most organizations, we create a single aggregated scorecard, whereas in others, we create individual scorecards for
the SSG and each business unit. However, each firm is represented by only one set of data in the model published here.
(Table 3, “BSIMM Numbers Over Time” in the appendix, shows changes in the data pool over time.)
As a descriptive model, the only goal of the BSIMM is to observe and report. We like to say we visited a neighborhood to
see what was happening and observed that “there are robot vacuum cleaners in X of the Y houses we visited.” Note that
the BSIMM does not say, “all houses must have robot vacuum cleaners,” “robots are the only acceptable kind of vacuum
cleaners,” “vacuum cleaners must be used every day,” or any other value judgements. Simple observations simply reported.
Our “just the facts” approach is hardly novel in science and engineering, but in the realm of software security, it has not
previously been applied at this scale. Other work around modeling SSIs has either described the experience of a single
organization or offered prescriptive guidance based purely on a combination of personal experience and opinion.

CREATING BSIMM10 FROM BSIMM9
BSIMM10 is the tenth major version of the model. It includes updated activity descriptions, data from 122 firms in multiple vertical
markets, and a longitudinal study. For BSIMM10, we added 19 firms and removed 17, resulting in a data pool of 122 firms.
We used the resulting observation counts to refine activity placement in the framework, which resulted in moving two activities
to different levels. In addition, we added three newly observed activities, resulting in a total of 119 activities in BSIMM10.
The following are the five changes we made for BSIMM10:

• [T1.6 Create and use material specific to company history] became T2.8
• [SR2.3 Create standards for technology stacks] became SR3.4
• [SM3.4 Integrate software-defined lifecycle governance] added to the model
• [AM3.3 Monitor automated asset creation] added to the model
• [CMVM3.5 Automate verification of operational infrastructure security] added to the model
We also carefully considered but did not adjust [AM2.2 Create technology-specific attack patterns] at this time; we
will do so if the observation rate continues to decrease. Similarly, we considered and did not adjust [CR2.5 Assign tool
mentors] but will do so if the observation rate continues to increase.
As concrete examples of how the BSIMM functions as an observational model, consider the activities that are now
SM3.3 and SR3.3, which both started as level 1 activities. The BSIMM1 activity [SM1.5 Identify metrics and use them
to drive budgets] became SM2.5 in BSIMM3 and is now SM3.3 due to its decreased observation rate. Similarly, the
BSIMM1 activity [SR1.4 Use coding standards] became SR2.6 in BSIMM6 and is now SR3.3. To date, no activity has
migrated from level 3 to level 1.
We noted in BSIMM7 that, for the first time, an activity ([AA3.2 Drive analysis results into standard architecture
patterns]) was not observed in the current dataset, and there were no new observations of AA3.2 for BSIMM8. AA3.2
did have two observations in BSIMM9 and one observation in BSIMM10; there are currently no activities with zero
observations (except for the three just added).
We continue to ponder the question, “Where do activities go when no one does them anymore?” In addition to
SM3.3 and SR3.3 mentioned above, we’ve noticed that the observation rate for other seemingly useful activities
has decreased significantly in recent years:
• [T3.5 Establish SSG office hours] – observed in 11 of 42 firms in BSIMM3 and 1 of 122 firms in BSIMM10
• [AA3.2 Drive analysis results into standard architecture patterns] – observed in 20 of 67 firms in BSIMM-V
and 4 of 122 firms in BSIMM10
• [CR3.5 Enforce coding standards] – observed in 13 of 51 firms in BSIMM4 and 2 of 122 firms in BSIMM10
We, of course, keep a close watch on the BSIMM data pool and will make adjustments if and when the time comes, which
might include dropping an activity from the model.
Fifty of the current participating firms have been through at least two assessments, allowing us to study how their
initiatives have changed over time. Twenty-one firms have undertaken three BSIMM assessments, eight have done four,
and two have had five assessments.
BSIMM10 is our first study to formally reflect software security changes driven by engineering-led efforts, meaning
efforts originating bottom-up in the development and operations teams rather than originating top-down from a
centralized SSG. These results show up here in the form of new activities, in new examples of the way existing activities
are conducted, as well as in discussion of the paths organizations might follow to maturation over time.

ROLES IN A SOFTWARE
SECURITY INITIATIVE BSIMM TERMINOLOGY
Determining the right activities to focus on and clarifying who Nomenclature has always been a problem in
is responsible for the implementation are important parts of computer security, and software security is no
making any SSI work. exception. Several terms used in the BSIMM
have particular meaning for us. The following
EXECUTIVE LEADERSHIP list highlights some of the most important
Historically, security initiatives that achieve firm-wide impact terms used throughout this document:
are sponsored by a senior executive who creates an SSG Activity. Actions carried out or facilitated by
where testing and operations are distinctly separate from the software security group (SSG) as part of a
software delivery. The BSIMM empowers these individuals to practice. Activities are divided into three levels in
garner resources and provide political support while maturing the BSIMM based on observation rates.
their groups. Those security initiatives born within engineering
Champion. Interested and engaged developers,
and led solely by development management, by comparison,
architects, software managers, testers, and people
have historically had little lasting impact. Likewise, initiatives
in similar roles who have a natural affinity for
spearheaded by resources from an existing network security
software security and contribute to the security
group usually run into serious trouble when it comes time to
posture of the organization and its software.
interface with development groups.
Domain. One of the four categories our
By identifying a senior executive and putting him or her in
framework is divided into, i.e., governance,
charge of software security directly, the organization can
intelligence, secure software development lifecycle
address two “Management 101” concerns: accountability
(SSDL) touchpoints, and deployment.
and empowerment. It can also create a place where software
security can take root and begin to thrive. Whether a firm’s Practice. BSIMM activities are organized into
current SSI exists primarily in an engineering group or is 12 categories or practices. Each domain in the
centrally managed, the BSIMM serves a common purpose by software security framework (SSF) has three
providing leaders insight into the activities firms like their own practices.
have adopted and institutionalized. While vendors’ marketing
Satellite. A group of individuals, often called
and conference submission cycles generate a wealth of new
champions, that is organized and leveraged by a
ideas to try, the BSIMM study serves to reduce the guesswork
software security group (SSG).
necessary to separate durable activities from clever fads.
Secure software development lifecycle
Individuals in charge of day-to-day efforts in the SSIs we
(SSDL). Any software lifecycle with integrated
studied have a variety of titles. Examples include AVP
software security checkpoints and activities.
Corporate Security, Director AppSec, Director Security
Assurance, VP InfoSec, VP Application Risk Management, Software security framework (SSF). The basic
Senior Director Shared Services, Manager Software Security structure underlying the BSIMM, comprising 12
Engineering, Senior Director Enterprise Software, Senior practices divided into four domains.
Director Infrastructure and Security, Senior Director Global
Software security group (SSG). The internal
InfoSec Innovation, Global Head Security Testing, System
group charged with carrying out and facilitating
Manager Systems Development, Security Architect, Executive
software security. According to our observations,
Director Product Operations, Manager InfoSec Operations,
the first step of a software security initiative (SSI)
Information Systems Manager, and Embedded Systems and
is to form an SSG.
Cybersecurity Leader. We observe a fairly wide spread in
exactly where the SSG is situated. In particular, 71 of the 122 Software security initiative (SSI). An
participating firms have SSGs that are run by a CISO or report organization-wide program to instill, measure,
to a CISO as their nearest senior executive. Seventeen of the manage, and evolve software security activities in a
firms report through a CTO as their closest senior executive, coordinated fashion. Also known in some literature
while six report to a CIO, seven to a CSO, four to a COO, two as an Enterprise Software Security Program.
to a CRO, and one to a CAO. Fourteen of the SSGs report
through some type of technology or product organization.

We also observe what might be a new trend regarding CISOs in the SSI reporting chain. In BSIMM-V, we saw CISOs
as the nearest executive in 21 of 67 organizations (31.3%), which grew in BSIMM6 to 31 of 78 firms (39.7%), and again
for BSIMM7 with 52 of 95 firms (54.7%). Since then, the percentage has remained relatively flat at 54.1% (59 of 109 in
BSIMM8), 52.5% (63 of 120 firms in BSIMM9), and 58.2% (71 of 122 firms in BSIMM10). We also noted that, of the
last 50 firms dropped from the participant pool due to data aging, 16 (32%) had a CISO in the reporting chain.
SOFTWARE SECURITY GROUP (SSG)

The second most important role in an SSI after the senior executive is the SSG leader and the SSG itself. Each of the 122
initiatives we describe in BSIMM10 has an SSG—a true organizational group dedicated to software security. In fact, without
an SSG, successfully carrying out BSIMM activities across a software portfolio is very unlikely, so the creation of an SSG
is a crucial first step in working to adopt BSIMM activities. The best SSG members are software security people, but they
are often hard to find. If an organization must create a software security team from scratch, it should start with developers
and teach them about security. Starting with IT security engineers and attempting to teach them about software, compilers,
SDLCs, bug tracking, and everything else in the software universe usually fails to produce the desired results. Unfortunately,
no amount of traditional security knowledge can overcome a lack of experience building software.
SSGs come in a variety of shapes and sizes, but SSGs in the more mature SSIs appear to include both people with deep
coding experience and people with architectural skill. Code review is an important best practice, but to perform code
review, the team must actually understand code (not to mention the huge piles of security bugs therein). That said, the
best code reviewers sometimes make poor software architects, and asking them to perform an architecture risk analysis
will fail to produce useful findings. SSGs are often asked to mentor, train, and work directly with hundreds of developers,
so communication skills, teaching ability, and practical knowledge are must-haves for at least a portion of the SSG staff.
As the technology landscape changes, leading SSGs make a point of maintaining their depth in evolving disciplines such
as cloud, CI/CD, DevOps, privacy, supply chains, and so on. Finally, SSGs are groups of people—whether one person,
10, or 100—that must improve the security posture of the software portfolio, so management skills, risk management
perspectives, and an ability to break silos are critical success factors.
Although no two of the 122 firms we examined had exactly the same SSG structure, we did observe some commonalities
that are worth mentioning. At the highest level, SSGs come in five flavors: 1) organized to provide software security
services, 2) organized around setting policy, 3) designed to mirror business unit organizations, 4) organized with a hybrid
policy and services approach, and 5) structured around managing a network of others doing software security work. Some
SSGs are highly distributed across a firm whereas others are centralized. When we look across all of the SSGs in our
study, we do see several common SSG teams or communities: people dedicated to policy, strategy, and metrics; internal
“services” groups that (often separately) cover tools, penetration testing, and middleware development plus shepherding;
incident response groups; groups responsible for training development and delivery; externally-facing marketing and
communications groups; and vendor management groups.
In the evolving world of digital transformation, including the automation components in CI/CD and cultural components
in DevOps, we’re also beginning to see a structure that has a defined SSI with real commitment, but the SSG doesn’t
pop into existence as an assigned group (like building a team on an organizational chart). In these cases, the SSG starts
organically, almost always in the engineering organization, with various individuals taking on roles such as “BuildSec,”
“ContainerSec,” “DeploymentSec,” and so on. In the spirit of agility, engineers in these firms often contribute their
time first to prototyping specific capabilities—such as operations security and incident response, threat intelligence,
and vulnerability discovery tooling—and then to forming dedicated groups after they have direct experience with what’s
needed from a security perspective.
In the 122 BSIMM10 firms, we noted an average ratio of full-time SSG members to developers of 1.37%, meaning we
found one SSG member for every 73 developers when we averaged the ratios of each participating firm. For organizations
with 500 developers or fewer, the largest ratio observed was 20% and the smallest was 0.2%, with a median of 1.4%.
For organizations with more than 500 developers, the largest ratio observed was 5.0% and the smallest was 0.1%, with a
median of 0.4%. Average SSG size among the 122 firms is 13.1 people (smallest 1, largest 160, median 6).

SATELLITE
In addition to the SSG, many SSIs have identified a number of individuals (often developers, testers, and architects) who
share a basic interest in improving software security but are not directly employed in the SSG. When these individuals
carry out software security activities, we collectively refer to them as the satellite. Many organizations are now referring
to this group as their software security champions.
Satellite members are sometimes chosen for software portfolio coverage, with one or two members in each product
group, but are sometimes chosen for other reasons such as technology stack coverage or geographical reach. Sometimes
they’re more focused on specific issues such as cloud migration and IoT architecture. We are also beginning to see some
organizations use satellite members to bootstrap the “Sec” functions they require for transforming a given product team
from DevOps to DevSecOps.
In any case, the more successful satellite groups get together regularly to compare notes, learn new technologies, and
expand stakeholder understanding of the organizations’ software security state. Similar to a satellite, and mirroring
the community and culture of open source software, we are beginning to see motivated individuals in engineering-led
organizations sharing digital work products such as sensors, code, scripts, tools, and security features rather than, for
example, getting together to discuss enacting a new policy. Specifically, these engineers are working bottom-up and
delivering software security features and awareness through implementation regardless of whether guidance is coming
top-down from a traditional SSG.
To achieve scale and coverage, identifying and fostering a strong satellite is important to the success of many SSIs (but
not all of them). Some BSIMM activities target the satellite explicitly. Of particular interest, 30 of the 35 firms (86%)
with the highest BSIMM scores have a satellite, with an average satellite size of 175 people for those 30 firms. Outside
the top 35 firms, 27 of the remaining 87 have a satellite (31%), with an average satellite size of 43 for those 27 firms. Of
the 35 firms with the lowest BSIMM scores, only 6 have a satellite, and the bottom 9 have no satellite at all.
Sixty-seven percent of firms that have been assessed more than once have a satellite, while 66% of the firms on their
first assessment do not. Many firms that are new to software security take some time to identify and develop a satellite.
These data suggest that as an SSI matures, its activities become distributed and institutionalized into the organizational
structure, and perhaps into engineering automation, needing an expanded satellite to provide expertise and be the local
voice of the SSG. Among our population of 122 firms, initiatives tend to evolve from centralized and specialized in the
beginning to decentralized and distributed (with an SSG at the core orchestrating things).

EVERYBODY ELSE
SSIs are truly cross-departmental efforts that involve a variety of stakeholders:
• Builders, including developers, architects, and their managers, must practice security engineering, ensuring
that the systems they build are defensible and not riddled with security issues. The SSG will interact directly
with builders when they carry out the activities described in the BSIMM. Generally speaking, as an organization
matures, the SSG attempts to empower builders so they can carry out most BSIMM activities themselves,
with the SSG helping in special cases and providing oversight, such as with integrating various defect discovery
methods into CI/CD toolchains. In engineering-led organizations, SSG members often participate directly with
builders to deliver software in addition to empowering them to be self-sufficient. We often don’t explicitly point
out whether a given activity is to be carried out by the SSG, developers, or testers. Each organization should
come up with an approach that makes sense and accounts for its own workload and software lifecycles.
• Testers concerned with routine testing and verification should do what they can to keep an eye out for security
problems. Some BSIMM activities in the Security Testing practice can be carried out directly by QA. In many
organizations today, software is being built in anticipation of failure, and the associated test cases go directly
into regression suites run by QA groups or run directly through automation.
• Operations teams must continue to design, defend, and maintain resilient environments. As you will see in
the Deployment domain of the SSF, software security doesn’t end when software is “shipped.” In accelerating
trends, Development and Operations are collapsing into a DevOps team, and the business functionality
delivered is becoming very dynamic in the operational environment. This means an increasing amount of
security effort is becoming software-defined and happening in operations.
• Administrators must understand the distributed nature of modern systems, create and maintain secure builds,
and begin to practice the principle of least privilege, especially when it comes to the applications they host or
attach to as services in the cloud.
• Executives and middle management, including line of business owners and product managers, must understand
how early investment in security design and security analysis affects the degree to which users will trust their
products. Business requirements should explicitly address security needs, including security-related compliance
needs. Any sizeable business today depends on software to work, thus software security is a business necessity.
Executives are also the group that must provide resources for new digital transformation efforts that directly
improve software security.
• Vendors, including those who supply on-premise products, custom software, and software-as-a-service, are
increasingly subjected to SLAs and reviews (such as the upcoming PCI Secure Software Lifecycle Standard and
the BSIMMsc1) that help ensure products are the result of a secure SDLC. Of course, vendor or not, the open
source management process also requires close attention.
For a study of CISOs and their organizations, see https://www.synopsys.com/software-integrity/resources/analyst-reports/ciso.html

1

MEASURING YOUR FIRM WITH THE BSIMM
The most important use of the BSIMM is as a measuring stick to determine where your approach currently stands
relative to other firms. You can simply note which activities you already have in place, find them in the SSF, and then
build your scorecard. A direct comparison of all 119 activities is perhaps the most obvious use of the BSIMM. This can be
accomplished by building your own scorecard and comparing it to the BSIMM10 Scorecard.
As a summary, the BSIMM SSF comprises four domains—Governance, Intelligence, SSDL Touchpoints, and
Deployment. In turn, those four domains include 12 practices, which contain the 119 BSIMM activities. A BSIMM
scorecard indicates which activities were observed in an organization.
On the next page, Table 1 depicts an example firm that performs 39 BSIMM activities (noted as 1’s in its scorecard
columns), including 10 activities that are the most common in their respective practices (yellow boxes). Note the firm
does not perform the most commonly observed activities in the other two practices (red boxes) and should take some
time to determine whether these are necessary or useful to its overall SSI. The BSIMM10 FIRMS columns show the
number of observations (currently out of 122) for each activity, allowing the firm to understand the general popularity of
an activity among the 122 BSIMM10 firms.
Once you have determined where you stand with activities, you can devise a plan to enhance practices with other
activities included in the BSIMM, or perhaps scale current activities across more of the software portfolio. By providing
actual measurement data from the field, the BSIMM makes it possible to build a long-term plan for an SSI and track
progress against that plan. Note that there’s no inherent reason to adopt all activities in every level for each practice.
Adopt the activities that make sense for your organization and ignore those that don’t but revisit those choices
periodically. Once they’ve adopted an activity set, most organizations then begin to work on the depth, breadth, and
cost-effectiveness of each activity in accordance with their view of the associated risk.
In our own work using the BSIMM to assess initiatives, we found that creating a spider chart yielding a high-water mark
approach (based on the three levels per practice) is sufficient to obtain a low-resolution feel for maturity, especially when
working with data from a particular vertical. We assign the high-water mark with a simple algorithm. If we observed a level
3 activity in a given practice, we assign a “3” without regard for whether any level 2 or 1 activities were also observed. We
assign a high-water mark of 2, 1, or 0 similarity.
One meaningful use of this comparison is to chart your own high-water mark against the graphs we’ve published to
see how your initiative stacks up. In Figure 1, we have plotted data from the example firm against the BSIMM AllFirms
data. The breakdown of activities into levels for each practice is meant only as a guide and reflects only the observation
frequency for the activities. As such, the levels might illustrate a natural progression through the activities associated with
each practice, but it isn’t necessary to carry out all activities in a given level before moving on to activities at a higher level
(activities that are less commonly observed) in the same practice. That said, the levels we’ve identified hold water under
statistical scrutiny. Level 1 activities (often straightforward and universally applicable) are those that are most commonly
observed, level 2 (often more difficult to implement and requiring more coordination) are slightly less frequently
observed, and level 3 activities (usually more difficult to implement and not always applicable) are rarely observed. For
many organizations, maturity improves directly as a result of scaling activity efforts across more of the software portfolio
and the stakeholders as opposed to aiming specifically at implementing level 3 activities just because they’re level 3.

GOVERNANCE INTELLIGENCE SSDL TOUCHPOINTS DEPLOYMENT
BSIMM10 BSIMM10 BSIMM10 BSIMM10
FIRMS EXAMPLE FIRMS EXAMPLE FIRMS EXAMPLE FIRMS EXAMPLE
ACTIVITY ACTIVITY ACTIVITY ACTIVITY
(out of FIRM (out of FIRM (out of FIRM (out of FIRM
122) 122) 122) 122)
STRATEGY & METRICS ATTACK MODELS ARCHITECTURE ANALYSIS PENETRATION TESTING

[SM1.1] 81 1 [AM1.2] 80 [AA1.1] 103 1 [PT1.1] 109 1
[SM1.2] 66 [AM1.3] 36 [AA1.2] 29 1 [PT1.2] 94 1
[SM1.3] 73 1 [AM1.5] 51 1 [AA1.3] 23 1 [PT1.3] 82
[SM1.4] 107 1 [AM2.1] 8 [AA1.4] 62 [PT2.2] 25 1
[SM2.1] 49 [AM2.2] 7 1 [AA2.1] 18 [PT2.3] 22
[SM2.2] 53 [AM2.5] 16 1 [AA2.2] 14 1 [PT3.1] 11 1
[SM2.3] 52 [AM2.6] 11 1 [AA3.1] 7 [PT3.2] 5
[SM2.6] 51 [AM2.7] 10 [AA3.2] 1
[SM3.1] 21 [AM3.1] 3 [AA3.3] 4
[SM3.2] 6 [AM3.2] 2
[SM3.3] 14 [AM3.3] 0
[SM3.4] 0
COMPLIANCE & POLICY SECURITY FEATURES & DESIGN CODE REVIEW SOFTWARE ENVIRONMENT
[CP1.1] 81 1 [SFD1.1] 98 [CR1.2] 80 1 [SE1.1] 66
[CP1.2] 105 1 [SFD1.2] 69 1 [CR1.4] 85 1 [SE1.2] 111 1
[CP1.3] 76 1 [SFD2.1] 31 [CR1.5] 44 [SE2.2] 36 1
[CP2.1] 48 [SFD2.2] 40 [CR1.6] 44 1 [SE2.4] 27
[CP2.2] 47 [SFD3.1] 11 [CR2.5] 39 [SE3.2] 13
[CP2.3] 51 [SFD3.2] 12 [CR2.6] 21 [SE3.3] 4
[CP2.4] 44 [SFD3.3] 4 [CR2.7] 23 [SE3.4] 14
[CP2.5] 56 1 [CR3.2] 7 1 [SE3.5] 5
[CP3.1] 25 [CR3.3] 1 [SE3.6] 3
[CP3.2] 15 [CR3.4] 4 [SE3.7] 9
[CP3.3] 7 [CR3.5] 2
TRAINING STANDARDS & REQUIREMENTS SECURITY TESTING CONFIG. MGMT. & VULN. MGMT.
[T1.1] 77 1 [SR1.1] 83 1 [ST1.1] 100 1 [CMVM1.1] 103 1
[T1.5] 37 [SR1.2] 81 [ST1.3] 87 1 [CMVM1.2] 101
[T1.7] 46 1 [SR1.3] 85 1 [ST2.1] 32 1 [CMVM2.1] 91 1
[T2.5] 27 [SR2.2] 52 1 [ST2.4] 15 1 [CMVM2.2] 88
[T2.6] 28 [SR2.4] 46 [ST2.5] 9 [CMVM2.3] 64
[T2.8] 28 1 [SR2.5] 35 1 [ST2.6] 9 [CMVM3.1] 2
[T3.1] 3 [SR3.1] 22 [ST3.3] 2 [CMVM3.2] 9
[T3.2] 16 [SR3.2] 11 [ST3.4] 1 [CMVM3.3] 12
[T3.3] 15 [SR3.3] 9 [ST3.5] 2 [CMVM3.4] 13
[T3.4] 14 [SR3.4] 24 [CMVM3.5] 0
[T3.5] 5
[T3.6] 1
ACTIVITY 119 BSIMM10 activities, shown in 4 domains and 12 practices
BSIMM10 FIRMS Count of firms (out of 122) observed performing each activity
Most common activity within a practice
LEGEND
Most common activity in practice was not observed in this assessment
1 Most common activity in practice was observed in this assessment
A practice where firm’s high-water mark score is below the BSIMM10 average
Table 1. BSIMM ExampleFirm Scorecard. A scorecard is helful for understanding efforts currently underway and where to focus next.

CONFIGURATION STRATEGY
MANAGEMENT & & METRICS
VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS
SECURITY SECURITY FEATURES

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
ALLFIRMS (122) EXAMPLEFIRM
Figure 1. AllFirms vs. ExampleFirm Spider Chart. Charting high-water mark values provides a low-resolution view of maturity that can
be useful for comparisons between firms, between business units, and within the same firm over time.
By identifying activities from each practice that could work for you, and by ensuring proper balance with respect to domains,
you can create a strategic plan for your SSI moving forward. Note that most SSIs are multiyear efforts with real budget,
mandate, and ownership behind them. Although all initiatives look different and are tailored to fit a particular organization,
all initiatives share common core activities (see “Table 7. Most Common Activities Per Practice,” in the appendix).
USING THE BSIMM TO START OR IMPROVE AN SSI

The BSIMM is not a single-purpose SSI benchmarking tool—it also eases management and evolution for anyone in
charge of software security, whether that person is currently in a central governance-focused position or in a more local
engineering-focused team. Firms of all maturity levels, sizes, and verticals use the BSIMM as a reference guide when
building new SSIs from the ground up and when evolving the maturity of their initiatives over time.
HOW TO USE THIS SECTION

Though the BSIMM data and our analyses don’t dictate specific paths to SSI maturity, we have observed patterns in the
ways firms use the activities to improve their capabilities. This section of the document lays out a general framework for
using the BSIMM to determine which activities might best accompany your existing capabilities and improve the security
of your software portfolio.
Every organization is on its own unique software security journey. Evolving business and technology drivers, executive
expectations, security goals, and operational aspirations, as well as current organizational strengths and weaknesses, will
motivate different paths from your current state to your journey’s next waypoint.

Governance-led and emerging engineering-led approaches to software security improvement embody different
perspectives on risk management that might not correlate. Governance-led groups usually focus on rules and gates,
while emerging engineering-led efforts usually focus on feature velocity and software resilience. Success doesn’t require
identical viewpoints, but collectively they need to align in order to keep the firm safe. That means the groups must
collaborate on risk management concerns to build on their strengths and minimize their weaknesses.
Given these cultural differences, how does one go about building and maturing a firm-wide SSI that protects the entire
software portfolio? To use an analogy, imagine maturing your SSI just as a mountaineer might imagine scaling a mountain
range to a particular summit—that summit being the level of maturity that’s right for your organization. Reaching each
new peak along the way requires having a plan and resources to overcome new obstacles and challenges. You might reach
a plateau from which you’ll need to regroup and figure out where to go next. You might wander into a valley as you deal
with unfamiliar, complex problems and must find a way out. Only then can you see a path to the next peak, and off you
go. Today, aligning governance views and engineering views is a requirement for moving forward effectively.
SSI PHASES
No matter an organization’s culture, all firms strive to reach similar peaks on their journey. Over time, we find that SSIs
typically progress through three states:
• Emerging. An organization tasked with booting a new SSI from scratch or formalizing nascent or ad hoc
security activities into a holistic strategy. An emerging SSI has defined its initial strategy, implemented
foundational activities, acquired some resources, and might have a roadmap for the next 12 to 24 months of its
evolution. SSI leadership working on a program’s foundations are often resource-constrained on both people
and budget, and might use compliance requirements or other executive mandates as the initial drivers to
continue adding activities.
• Maturing. An organization with an existing or emerging software security approach connected to executive
expectations for managing software security risk and progressing along a roadmap for scaling security
capabilities. A maturing SSI works to cover a greater percentage of the firm’s technology stacks, software
portfolio, and engineering teams (in-house and supply chain). SSI leadership maturing a program might be
adding fewer activities while working on depth, breadth, and cost effectiveness of ongoing activities.
• Optimizing. An organization that’s fine-tuning and evolving its existing security capabilities (often with a
risk-driven approach), having a clear view into operational expectations and associated metrics, adapting to
technology change drivers, and demonstrating business value as a differentiator. The SSI leader optimizing their
program might also be undergoing an evolution from technology executive to business enabler.
It’s compelling to imagine that organizations could self-assess and determine that by doing X number of activities,
they qualify as emerging, maturing, or otherwise. However, experience shows that SSIs can reach a “maturing” stage
by conducting the activities that are right for them without regard for the total count. This is especially true when
considering software portfolio size and the relative complexity of maturing or optimizing some activities across 1, 10, 100,
and 1,000 applications.
In addition, organizations don’t always progress from emerging to optimizing in one direction or in a straight path. We
have seen SSIs form, break up, and re-form over time, so one SSI might go through the emerging cycle a few times
over the years. An SSI’s capabilities might not all progress through the same states at the same time. We’ve noted cases
where one capability—vendor management, for example—might be emerging while the defect management capability
is maturing, and the defect discovery capability is optimizing. There is constant change in tools, skill levels, external
expectations, attackers and attacks, resources, and everything else. Pay attention to the relative frequency with which
the BSIMM activities are observed across all the participants, but use your own metrics to determine if you’re making the
progress that’s right for you.

SSI CULTURES
Organizations choose the path by which they climb the software security mountain by tailoring methods, tools, and
approaches to their individual cultures. There have always been two distinct cultures in the BSIMM community. One
is organizations where the SSI was purposely started in a central corporate group (e.g., under a CISO) and focused on
compliance, testing, and risk management. This path is seen most often in regulated industries such as banking, insurance,
and healthcare but also in some ISV and technology firms. The other is organizations where the SSI was started by
engineering leadership (e.g., senior application architects), but the organization rather quickly created a centralized
group (e.g., under a CTO) to set some development process, create and manage security standards, and ensure the silos
of engineering, testing, and operations are aware of and adhere to security expectations. This path is seen most often in
technology firms and ISVs but is also seen in other verticals.
Regardless of origin and of whether the SSG currently lives in a corporate group or in engineering, however, both cultures
historically ended up with an SSI that is driven by a centralized, dedicated SSG whose function is to ensure appropriate
software security activities are happening across the portfolio. That is, nearly all SSIs today are governance-led regardless
of whether the SSI genesis was the executive team or the architecture team. They practice proactive risk management
through assurance-based activities, resulting in the creation of “rules that people must follow” (e.g., policy, standards,
gates). This means a defined process that includes prescriptive testing at various times in the lifecycle, gates where
engineering processes can be derailed, and other software security activities that make a lot of risk management sense to
the SSG but just appear as friction to the development, testing, and operations groups.
THE NEW WAVE OF ENGINEERING CULTURE

We’re once again seeing software security efforts emerging from engineering teams, and those efforts are being driven by
at least two large factors. First, there is the confluence of process friction, unpredictable impacts on delivery schedules,
adversarial relationships, and a growing number of human-intensive processes from existing SSIs. Then there are the
demands and pressures from modern software delivery practices, such as Agile and DevOps. The result is engineering
groups placing more emphasis on automation as opposed to human-driven tasks. Software-defined sensors and
checkpoints are replacing human discretion, conversations, and risk decisions that should involve multiple stakeholders.
Many application lifecycle processes are moving faster whether they’re ready to or not. And, perhaps most importantly,
all this software security effort is frequently happening independently from the experience and lessons learned that a
centralized SSG might provide.
The governance-driven approach we’ve seen for years and the emerging engineering-driven efforts are increasingly
coexisting within the same organization and often have competing objectives. The DevOps movement has put these
tensions center stage for SSI leaders to wrestle. Given different objectives, we find that the outcomes desired by these
two approaches are usually very different. Rather than the top-down, proactive risk management and “rules that people
must follow” of governance-minded teams, these newer engineering-minded teams are more likely to “prototype good
ideas” for securing software, which results in the creation of code and infrastructure on the critical path (e.g., security
features, home-spun vulnerability discovery, security guardrails). Here, security is just another aspect of quality, and
resiliency is just another aspect of availability.
To keep pace with both software development process changes (e.g., CI/CD adoption) and technology architecture
changes (e.g., cloud, container, and orchestration adoption), engineering-led efforts are independently evolving both how
they apply software security activities and, in some cases, what activities they apply. The changes engineering-led teams
are making include downloading and integrating their own security tools, spinning up cloud infrastructure and virtual
assets as they need them, following policy on use of open source software in applications but routinely downloading
dozens or hundreds of other open source packages to build and manage software and processes, and so on. Governance-
driven SSIs are finding themselves in a race to retroactively document, communicate, and share (as well as proactively
direct) these engineering-led evolutionary changes.

Given the frequent focus by centralized governance groups on policy adherence and test results as measures of success,
such groups often do not recognize the specific progress made by engineering-led teams. For their part, engineering
teams do not frequently broadcast changes to vulnerability discovery or security engineering until those changes are
shareable as reusable code. Engineering-led efforts are therefore making technology-specific changes to their security
activities as code at the same speed that their development and cloud technology changes, while centralized SSI owners
are making changes to their policies, standards, and processes at the same speed that executives can build consensus
around them. Combining these two approaches and cadences, while still maintaining a single coherent SSI direction, will
require a concerted effort by all the stakeholders.
MOVING FORWARD
We frequently observe governance-driven SSIs planning centrally, seeking to proactively define an ideal risk posture
during their emerging phase. After that, the initial uptake of provided controls (e.g., security testing) is usually led by
the teams that have experienced real security issues and are looking for help. These firms often struggle during the
maturation phase where growth will incur significant expense and effort as the SSG scales the controls and their benefits
enterprise-wide. We observe that emerging engineering-driven efforts prototype controls incrementally, building on the
existing tools and techniques that already drive software delivery. Gains happen quickly in these emerging efforts, perhaps
given the steady influx of new tools and techniques introduced by engineering, but also helped along by the fact that each
team is usually working in a homogenous culture on a single application and technology stack. Even so, these groups also
struggle to institutionalize durable gains during their maturation phase, usually because the engineers have not been able
to turn capability into either secure-by-default functionality or automation-friendly assurance—at least not beyond the
most frequently encountered security issues and beyond their own spheres of influence. Scaling an SSI across a software
portfolio is hard for everyone.
Emerging engineering-driven groups tend to view security as an enabler of software features and code quality. These
groups recognize the need for having security standards but tend to prefer “governance as code” as opposed to a “manual
steps with human review” approach to enforcement. This tends to result in engineers building security features and
frameworks into architectures, automating defect discovery techniques within a software delivery pipeline, and treating
security defects like any other defect. Traditional human-driven security decisions are modeled into a software-defined
workflow as opposed to written into a document and then implemented in a separate risk workflow handled outside of
engineering. In this type of culture, it’s not that the traditional SDLC gates and risk decisions go away, it’s that they get
implemented differently and they usually have different goals compared to those of the governance-driven groups.
WAYPOINTS ALONG YOUR JOURNEY

Although all organizations are different, we see patterns in how SSIs are implemented and trends in how they evolve.
Many of these activities are common to programs whether they’re working on foundations, scale, or efficacy. These
activities are observed across cultural boundaries, whether the security culture is one of central and proactive governance
or is engineering-driven, or whether both are learning to coexist.
We include specific references to BSIMM activities in the guidance below. The references are meant to help you
understand associations between the topic being discussed and one or more BSIMM activities. The references don’t mean
that the topic being discussed is fully equivalent to the activity. For example, when we say, “Inventory software [SM3.1],”
we don’t mean that having an inventory encompasses the totality of [SM3.1], just that having an inventory will likely be
something you’ll do on your way to implementing [SM3.1]. To continue using [SM3.1] as an example, most organizations
will not set about implementing this activity and get it all done all at once. Instead, an organization will likely create an
initial inventory, implement a process to keep the inventory up to date, find a way to track results from testing efforts, do
some repeatable analysis, and decide how to create a risk posture view that’s meaningful for them. Every activity has its
own nuances and components, and every organizational journey will be unique.

Although they might not use the same vocabulary or originate in the same organizational structure, all SSIs build a
foundation that includes the following:
• Structure. Name an owner [SM1.1], generate awareness [SM1.2], and identify engineering participation [SFD1.2]
• Prioritization. Define a list of Top 10 bugs [CR2.7] or attacks [AM2.5] to prevent (or let the security testing
tools they buy choose for them), prioritize portfolio scope [AA1.4], and select initial controls [SM1.4]
• Visibility. Inventory assets [SM3.1, CP2.1, CMVM2.3], then conduct defect discovery [AA1.2, CR1.4, ST2.1,
PT1.1, SR2.4] to determine which issues are already in production
Note that an SSI leader with a young initiative (less than one year) working on the foundations should not expect or
set out to quickly implement a large number of BSIMM activities. Firms can only absorb a limited amount of cultural
and process change at any given time. The BSIMM10 data show that SSIs having an age of less than one year at time of
assessment have an average score of 20.8 (26 of 122 firms).
GOVERNANCE-LED CULTURE
Governance-driven SSIs almost always begin their journey GETTING STARTED CHECKLIST
by appointing an SSI owner tasked with shepherding the
organization through understanding scope, approach, and 1. Leadership. Put someone in charge of
software security, and provide the resources he
priorities. Once an SSI owner is in place, his or her first order
or she will need to succeed.
of business is likely to establish centralized structure. This
structure might not involve hiring staff immediately, but it will 2. Inventory software. Know what you have,
likely entail implementing key foundational activities central where it is, and when it changes.
to supporting assurance objectives that are further defined
3. Select in-scope software. Decide what
and institutionalized in policy [CP1.3], standards [SR1.1],
you’re going to focus on first.
and processes [SM1.1].
4. Ensure host and network security basics.
Inventory Software Don’t put good software on bad systems or
We observe governance-led SSIs seeking an enterprise-wide in poorly constructed networks (cloud
perspective when building an initial view into their software or otherwise).
portfolio. Engaging directly with application business owners,
these cultures prefer to cast a wide net through questionnaire- 5. Do defect discovery. Determine the issues
style data gathering to build their initial application inventory in today’s production software and plan
[CMVM2.3]. These SSIs tend to focus on applications (with for tomorrow.
owners who are responsible for risk management) as the unit 6. Select security controls. Start with
of measure in their inventory rather than software, which controls that establish some risk management
might include many vital components that aren’t applications. to prevent recurrence of issues you’re
In addition to understanding application profile characteristics seeing today.
(e.g., programming language, architecture type such as web or
mobile, revenue generated) as a view into risk, these cultures 7. Repeat. Expand the team, improve
tend to focus on understanding where sensitive data resides the inventory, automate the basics, do more
and flows (e.g., PII inventory) [CP2.1] along with the status prevention, and then repeat again.
of active development projects.

Select In-scope Software
With an application inventory in hand, governance-led SSIs impose security requirements top-down using formalized
risk-based approaches to blanket as much of their software portfolio as possible. Using simple criteria (e.g., application
size, regulatory constraints, internal vs. external facing, data classification), these cultures assign a risk classification (e.g.,
high, medium, low) to each application in their inventory [AA1.4]. SSI leaders then define the initial set of software and
project teams with which to prototype security activities. Although application risk classifications are often the primary
driver, we have observed firms using other information, such as whether a major change in application architecture is
being undertaken (e.g., lift and shift to a cloud environment), when selecting foundational SSI efforts. We also observe
that firms find it beneficial to include in the selection process some engineering teams that are already doing some
security activity organically.
Ensure Host and Network Security Basics
One of the most commonly observed activities today, regardless of SSG age, is [SE1.2 Ensure host and network security
basics]. A common strength for governance-minded firms who have tight controls over the infrastructure assets they
manage, this is accomplished through a combination of IT provisioning controls, written policy, pre-built and tested golden
images, monitoring capabilities, server hardening and configuration standards, and entire groups dedicated to patching. As
firms migrate infrastructure off-premise to cloud environments, governance-led firms remain keen on re-implementing
their assurance-based controls to verify adherence to security policy, calling out cloud provider dependencies. They
sometimes must deploy custom solutions to overcome limitations in a cloud provider’s ability to meet desired policy in an
attempt to keep tabs on the growing number of virtual assets created by engineering groups and their automation.
Do Defect Discovery
Initial defect discovery efforts in governance-led cultures tend to be one-off using centralized commercial tools [CR1.2]
and tend to target the most critical software with a plan to scale efforts over time. Often, a previous breach or near-
miss focuses everyone’s attention on one particular type of software or security defect. While not always automated
or repeatable, conducting some vulnerability discovery in order to get a feel for the current risk posture allows firms to
prioritize remediation and motivate the necessary conversations with stakeholders to gain buy-in for an SSG. The type of
vulnerability discovery doesn’t necessarily matter at this stage and can be selected because it applies to the current phase
of the software lifecycle that the intended target is naturally progressing through (e.g., do threat modeling at design time
and penetration testing on deployed software).
Select Security Controls
Based on the kinds of software in inventory, the reasons for selecting certain applications to be within your program’s
scope, and the issues uncovered in initial defect discovery efforts, SSI leaders select those BSIMM activities directly
applicable to incrementally improving the security of their application portfolio (e.g., policy [CP1.3], testing [AA1.2,
CR1.4, ST2.1, PT1.3, SR2.4], training [T1.5]) and often implement them in a “quick win” approach. Governance-minded
cultures tend to prefer showing adherence to well-known guidance and often choose initial security controls in response
to general industry guidance (e.g., OWASP, CWE, NIST, analysts) that applies to as much of their software as possible.
Initial selection is likely focused on detective controls to obtain as much visibility into the organization’s risk posture
as possible.
MATURING GOVERNANCE-LED SSIs

With foundations for centralized governance established, SSI leaders shift their attention to scaling risk-based controls
across the entire software portfolio and enabling development to find and fix issues early in the software lifecycle. Driven
centrally and communicated top-down, these cultures prescribe when security activities must occur at each phase of the
software lifecycle [SM1.4] and begin on-boarding application teams into the SSDL to improve overall risk posture.

Document and Socialize the SSDL
Because requirements are driven top-down and communicated centrally through people, these firms prefer to create
process, policy, and security standards in document and presentation form. Specifically, these firms document a process
(e.g., prototype SSDL) to generalize the SSI efforts above and communicate it to everyone for the organization’s use
[SM1.1]. Creating even a single-page view of the defect discovery activities to be conducted allows the organization to
institutionalize its initial awareness-building efforts as the first revision of its governance and testing regimen.
We observe governance-minded firms publishing security policies and standards through already established governance,
risk, and compliance (GRC) channels, complementing existing IT security standards. The SSI leader may also create a
security portal (e.g., website, wiki) that houses SSDL information in a central place [SR1.2]. Similar to the approach for
prioritizing defect discovery efforts, we observe these firms driving initial standards creation from industry top N risks,
leveraging sources such as MITRE, ISO, and NIST to form baseline requirements [AM2.5, CR2.7].
Finally, in governance-led SSIs, getting the word out about the organization’s top N risks and what can be done about
them becomes a key part of the SSI leader’s job. We observe these leaders using every channel possible (e.g., town halls,
brown bags, communities of practice forums, messaging channels) to socialize the software security message and raise
awareness of the SSDL [SM1.2].
Balance Detective and Preventive Controls
As evidence is gathered through initial defect discovery efforts that highlight the organization’s serious security defects in
its most important software assets, SSI leaders in governance-led firms seek to balance detective controls with preventive
controls for avoiding security issues and changing developer behavior.
Because initial defect discovery often targets deployed software (over to the “right” in the software lifecycle), SSI
leaders begin educating the organization on the need to “shift left” through adoption of tools that can be integrated into
developer workflow. These firms typically rely on tool vendor rule sets and vulnerability coverage to expand their generic
top N-focused defect discovery, often starting with static [CR1.4] and dynamic analysis [ST2.1, ST2.6] to complement
existing penetration testing [PT1.1, PT1.3] efforts. To get started with tool adoption, we observe SSI leaders dedicating
some portion of their staff to serve as tool mentors and coaches to help development teams not only integrate the tools
but also triage and interpret results for the first time [CR2.5]. Seeking portfolio coverage, when evaluating and selecting
tools, governance-led SSIs often consider language support, environment interoperability, ease of deployment, and
results accuracy as key success criteria.
To scale the security mindset as tools are adopted, we observe governance-led firms focusing on establishing security
champions within application teams [SM2.3]. Although the primary objective is to embed security leadership inside
development, these individuals also serve as key points of contacts and interface points for the SSG to interact with
application teams to monitor progress. Because they are local to teams, champions also facilitate defect management
goals, such as tracking recurring issues to drive remediation [PT1.2].
Similar to policy, the need for tool adoption and building a satellite of champions is often communicated top-down by the
SSI leader. Starting at the executive level, SSI leaders often arm the CISO, CTO, or similar executive with data from initial
defect discovery efforts to tell stories about the consequences of having insecure software and how the SSDL will help
[SM2.1]. At the developer level, SSI leaders begin rolling out foundational software security training material tailored to the
most common security defects identified through defect discovery efforts, often cataloged by technology stack [T1.7].
Support Incident Response and Feedback to Development
In some governance-led cultures, establishing a link between the SSG and those doing the monitoring for security
incidents is often natural when CISOs or similar executives also own security operations. We observe SSI leaders
participating in software-related security incidents in a trusted advisor role to provide guidance to operations teams
on applying a temporary compensating control (e.g., a short-term WAF rule) and support to development teams on
fixing the root cause (e.g., refactor code, upgrade a library) [CMVM1.1]. For firms that have an emerging satellite, those
champions are often pulled into the conversation to address the issue at its source, creating a new interdepartmental
bridge between the SSG, security operations, and development teams.

OPTIMIZING GOVERNANCE-LED SSIs
Achieving software security scale—of expertise, portfolio coverage, tool integration, vulnerability discovery accuracy,
process consistency, and so on—remains a top priority. However, firms often scale one or two areas (e.g., defect
discovery, training) but fail to scale other areas (e.g., architecture analysis). Once scaled, there’s a treasure trove of data
to be harvested and included in KPI and KRI reporting dashboards. Then, executives start asking very difficult questions:
Are we getting better? Is our implementation working well? Where are we lagging? How can we go faster with less
overhead? What’s our message to the Board? The efficacy of an SSI will be supported by data collection and metrics
reporting that seeks to answer such questions [SM3.3].
As mentioned earlier, organizations don’t always progress from emerging to optimizing in one direction or in a straight
path, and some SSI capabilities might be optimizing while others are still emerging. Based on our experience, firms
with some portion of their SSI operating in an optimized state have likely been in existence for longer than three years.
Although we don’t have enough data to generalize this class of initiative, we do see common themes for those who strive
to reach to this state:
• Top N risk reduction. Relentlessly identify and close top N weaknesses, placing emphasis on obtaining visibility into
all sources of vulnerability, whether in-house developed code, open source code [SR3.1], vendor code [SR3.2],
tool chains, or any associated environments and processes. These top N risks are specific to the organization,
evaluated at least annually, and tied to metrics as a way to prioritize SSI efforts to improve risk posture.
• Tool customization. SSI leaders place a concerted effort into tuning tools (e.g., static analysis customization)
to improve accuracy, consistency, and depth of analysis [CR2.6]. Customization focuses on improving results
fidelity, applicability across the portfolio, and improving ease of use for everyone.
• Feedback loops. Loops are specifically created between SSDL activities to improve effectiveness, as
deliverables from SSI capabilities ebb and flow with each other. As an example, an expert within QA might
leverage architecture analysis results when creating security test cases [ST2.4]. Likewise, feedback from the
field might be used to drive SSDL improvement through enhancements to a hardening standard [CMVM3.2].
• Data-driven governance. Leaders instrument everything to collect data that in turn become metrics for
measuring SSI efficiency and effectiveness against KRIs and KPIs [SM3.1]. As an example, metrics such as
defect density might be leveraged to track performance of individual business units and application teams.

Push for Agile-Friendly SSIs
In recent years, we observe governance-led firms—often out of necessity to remain in sync with development changes—
evolving to become more agile-friendly:
• Putting “Sec” in DevOps is becoming a mission-critical objective. SSI leaders routinely partner with IT and
Development leadership to ensure the SSG mission aligns with DevOps values and principles.
• SSI leaders realize they need in-house talent with coding expertise to improve not only their credibility with
engineering but also their understanding of modern software delivery practices. Job descriptions for SSG roles
now mention experience and qualification requirements such as cloud, mobile, containers, and orchestration.
We expect this list to grow as other topics become more mainstream, such as serverless computing and
single-page application languages.
• To align better with DevOps values (e.g., agility, collaboration, responsiveness), SSI leaders are replacing
traditional people-driven activities with pipeline-driven automated tasks. Often this comes in the form of
automated security tool execution, bugs filed automatically to defect notification channels, builds flagged for
critical issues, and automated triggers to respond to real-time operational events.
• Scaling outreach and expertise through the implementation of an ever-growing satellite is viewed as a
short-term rather than long-term goal. Organizations report improved responsiveness and engagement as part
of DevOps initiatives when they’ve localized security expertise in the engineering teams. Champions are also
becoming increasingly sophisticated in building reusable artifacts in development and deployment streams
(e.g., security sensors) to directly support SSI activities.
• SSI leaders are partnering with operations to implement application-layer production monitoring and
automated mechanisms for responding to security events. There is a high degree of interest in consuming
real-time security events for data collection and analysis to produce useful metrics.
EMERGING ENGINEERING-LED CULTURE

From an activity perspective, we observe that emerging engineering-led software security efforts build on a foundation
very similar to governance-led organizations. How they go about accomplishing these activities differs, and usually
parallels their software-delivery focus.
Inventory Software
One of their first activities is creating an initial inventory of their local software portfolio [CMVM2.3]. Rather than
taking an organizational structure and owner-based view of this problem, we observe emerging engineering-led efforts
attempting to understand software inventory by extracting it from the same tools they use to manage their IT assets.
By scraping these software and infrastructure configuration management databases (CMDBs), they craft an inventory
brick-by-brick rather than top-down. They use the metadata and tagging that these content databases provide to reflect
their software’s architecture as well as their organization’s structure.
To this end, engineering-led efforts can combine two or more of the following approaches to inventory creation:
• Discovery, import, and visualization of assets managed by the organization’s cloud and data center virtualization
management consoles.
• Scraping and extracting assets and tags from infrastructure-as-code held in code repositories, as well as
processing metadata from container and other artifact registries.
• Outside-in web and network scanning for publicly discoverable assets, connectivity to known organizational
assets, and related ownership and administrative information.

That last bullet is particularly interesting. We’ve observed organizations that have discovered that this kind of external
discovery is essential despite substantial efforts to develop or purchase means of internal discovery such as described
by the first two bullets. In other words, despite increasing efforts, many organizations have substantially more software
in production environments than is captured by their existing processes. As one simple example, does a monolithic web
application replaced by a smaller application and 25 microservices become 26 entries in your CMDB? When the answer
is no, all organizations struggle to find all their software after the fact.
Select In-scope Software
We observe security leadership within engineering-led security efforts informally prioritizing in-scope software rather
than using a published and socialized risk formula. As software solutions pivot to meet changing customer demand,
software that is in scope of security governance is likely more fluid than in governance-driven groups. From their
perspective, informal prioritization that is revisited with greater frequency helps these groups better respond and
prioritize the appropriate software changes.
For much of an engineering-led effort, an activity is first prototyped by a security engineer participating within a
software delivery team. These engineers individually contribute to a team’s critical path activities. When they, for
example, complete production of test automation [ST2.5], vulnerability discovery tooling, or security features [SFD1.1],
a security engineer might move onto another delivery team bringing along their accomplishments or they might seek to
gain leverage from those accomplishments through the organization’s knowledge management systems and personally
evangelizing their use. This level of intimacy between a developer and the security improvements they will spread to other
projects and teams—often regardless of whether that improvement closely aligns with governance-driven rules—makes
scoping and prioritizing stakeholder involvement in the software inventory process vitally important.
Drivers differ by organization, but engineering-led groups have been observed to use the following as input when
prioritizing in-scope software:
• Velocity. Teams conducting active new development or major refactoring.
• Regulation. Those services or data repositories to which specific development or configuration requirements
for security or privacy apply [CP1.1, CP1.2].
• Opportunity. Those teams solving critical technical challenges or adopting key technologies that potentially
serve as proving grounds for emerging security controls.
Beyond immutable constraints like the applicability of regulation, we see evidence that assignment can be rather
opportunistic and perhaps driven “bottom-up” by security engineers and development managers themselves. In these
cases, the security initiative’s leader often seeks opportunities to cull their efforts and scale key successes rather than
direct the use of controls top-down.
Ensure Host and Network Security Basics
Compared to governance-led organizations, [SE1.2 Ensure host and network security basics] is observed no less
frequently for engineering-led groups. Security engineers might begin by conducting this work manually, then baking
these settings and changes into their software-defined infrastructure scripts to ensure both consistent application within
a development team and scalable sharing across the organization.
Forward-looking organizations that have adopted software and network orchestration technologies (e.g., Kubernetes,
Envoy, Istio) get maximum impact from this activity with the efforts of even an individual contributor, such as a security-
minded DevOps engineer. While organizations often have hardened container or host images on which software
deployments are based, software-defined networks and features from cloud service providers allow additional control
at the scale of infrastructure.

Though many of the technologies in which security engineers specify hardening and security settings are human readable,
engineering-led groups don’t typically take the time to extract and distill a document-based security policy from these
code bases. Without such policy, it can be hard for centralized elements of growing and maturing security initiatives—
governance-based groups, for example—to inspect and update this implicit policy on a firm-wide basis.
Choose Application Controls
Engineering-driven security cultures naturally favor security controls they can apply to software directly in the form of
features [SFD1.1]. This is unsurprising, as delivering security features has all the hallmarks of such a culture’s objectives:
delivering subject-matter experience as software, impacting the critical path of delivery, and accelerating that delivery.
Depending on the way an organization delivers to its customers, application controls can take the form of microservices
(e.g., authentication or other identity and access management), common product libraries (e.g., encryption) [SFD2.1], or
even infrastructure security controls (e.g., controlling scope of access to production secrets through vault technologies).
Defensively, engineering-led security groups have taken steps to tackle prevention of certain classes of vulnerability in
a wholesale manner [CMVM3.1], using development frameworks that obviate them, an effort we’ve seen decrease in
governance-led organizations. Security engineers in these groups are often asked their opinion about framework choices
and are often empowered to incorporate their understanding of security features and security posture tradeoffs as part of
the selection and implementation process. As part of the critical path to software delivery, these engineers can then tune
the framework’s implementation to the team’s and organization’s specific situation.
MATURING ENGINEERING-LED EFFORTS

As the foundations of an engineering-led security effort become more concrete, its leaders seek to deepen the technical
controls applied, apply all controls to a broader base of the organization’s software portfolio and infrastructure, and
generally scale its efforts.
Because engineering-led security culture relies heavily on the individual contributions of security engineers distributed
within development teams, these firms seek to follow through on what these dispersed engineers have started. Whereas
an emerging practice might have focused on automation to ensure host and network security basics, they will also
undertake and incrementally improve vulnerability discovery. They will continue to broaden the catalog of security
features delivered by security engineers to meet their view of security, usually as aligned with quality and resiliency rather
than centralized corporate governance. Rather than creating new policy, for example, engineering-led groups might
formalize the incident response experience accumulated to date into optimized internal process and use code snippets to
communicate incident feedback to development teams.
In addition to incremental progress on the activities that security engineers have begun to define, engineering-led security
efforts will also seek to apply what security engineers have delivered to one development team to the organization as a
whole. This means documenting and sharing software process, extracting explicit organizational policies and standards
from existing automation, and formalizing identification of data-driven obligations such as those due to PCI or to other
PII use.
Upgrade Incident Response
Governance-based and engineering-led groups alike conduct incident response. Engineering-led teams leverage DevOps
engineers to help make connections between those events and alerts raised in production and the artifacts, pipelines,
repositories, and teams responsible [CMVM1.1]. This crucial traceability mechanism allows these groups to effectively
prioritize security issues on which the security initiative will focus. Feedback from the field essentially replaces the top N
lists governance-led organizations use to establish priorities.
Security engineers that are in development teams and are more familiar with application logic might be able to facilitate
more instructive monitoring and logging. They can coordinate with DevOps engineers to generate in-application defenses
that are more effective than, for example, web application firewall rules, such as behavioral rules for access control and
specifically rules for business logic. Introducing such functionality will in turn provide richer feedback and allow more
tailored response [SE3.3].

Organizations building cloud-native applications using orchestration might respond to incidents, or to data indicating
imminent incidents, with an increase in logging, perhaps by adjusting traffic to the distribution of image types in
production. Much of this is possible only with embedded security engineers that are steeped in the business context
of a development team and have good relationships with that team’s DevOps engineers; satellite members (security
champions) can be a good source for these individuals. Under these circumstances, incident response moves at the speed
of a well-practiced single team rather than that of an inter-departmental playbook.
Do Defect Discovery
As firms mature, we see evidence of them building out scalable defect discovery practices. Specifically, these cultures
seek to provide highly actionable information about potential security issues to developers proactively. However, visibility
into potential vulnerability must come without disrupting CI/CD pipelines with tools that have long execution times,
without generating large volumes of perceived false positives, and without impeding delivery velocity (e.g., through
broken builds or inadmissible promotion).
Our observation is that engineering-led groups build discovery capability incrementally, with security engineers
prototyping new detective capability shoulder-to-shoulder with development teams. Prototyping likely includes in-band
triage and developer buy-in to the test findings, their accuracy, and their importance, as well as suggested remediation.
Our observations are that engineering-led groups are starting with open source and home-grown security
tools, with much less reliance on “big box” vulnerability discovery products. Generally, these groups hold to
two heuristics:
• Lengthening time to (or outright preventing) delivery is unacceptable. Instead, organize to provide telemetry
and then respond asynchronously through virtual patching, rollback, or other compensating controls.
• Build vulnerability detective capability incrementally, in line with a growing understanding of software misuse
and abuse and associated business risk, rather than purchasing boxed security standards as part of a vendor’s
core rule set.
These groups might build on top of in-place test scaffolding, might purposefully extend open source scanners that
integrate cleanly with their development tool chain, or both. Extension often focuses on a different set of issues than
characterized in general lists such as the OWASP Top 10, or even the broader set of vulnerabilities found by commercial
tools. Instead, these groups sometimes focus on denial of service, misuse/abuse of business functionality, or enforcement
of the organization’s technology-specific coding standards (even when these are implicit rather than written down).
Document the SSDL
Engineering-led cultures typically eschew document- or presentation-based deliverables in favor of code-based
deliverables. As the group seeks to apply its efforts to a larger percentage of the firm’s software, it might work to
institute some form of knowledge sharing process to get the security activities applied across teams. To this end, security
leaders might create a “one-pager” describing the security tools and techniques to be applied throughout software’s
lifecycle, make that resource available through organizational knowledge management, and evangelize it through internal
knowledge-sharing forums.
Unlike governance-driven groups, we found that engineering-led groups explicitly and purposefully incentivize security
engineers to talk externally about those security tools they’ve created (or customized), such as at regional meet-ups
and conferences. Security leads might use these incentives and invite external critique to ensure frequent maintenance
and improvement on tools and frameworks their engineers create, without continuing to tie up 100% of that engineer’s
bandwidth indefinitely.
SSDL documentation might be made available through an internal or even external source code repository, along with
other related material that aids uptake and implementation by development teams. A seemingly simple step, this makes it
very easy for development teams to conform to the SSDL within their existing tool chains and cultural norms.

OPTIMIZING ENGINEERING-LED EFFORTS
To some extent, engineering-led groups take an optimizing approach from the beginning. Security efforts are built on
contributions of engineers, delivering software early and often, and constantly improving rather than relying on explicit
strategy, backed by policies, built top-down, and pushed everywhere through organizational mandate over time.
It’s clear that some of these groups have achieved an “optimizing” state of maturity for some of their software security
capabilities. However, the BSIMM does not yet contain enough data to generalize about this type of effort, in terms of
which activities such groups are likely to conduct, or how implementation of those activities may differ from their form
in governance-driven groups. We will continue to track engineering-led groups and look for patterns and generalizations
in the data that might give us insight into how they achieve some maturity that aligns with expectations across the
organization and the software portfolio. It may be the case that over the next few years, we will once again see a merging
of engineering-led efforts and governance-led efforts into a single firm-wide SSI.

PART TWO: BSIMM10
THE BSIMM10 FRAMEWORK
The BSIMM is organized as a set of 119 activities in a software security framework, represented here. The framework
includes twelve practices that are organized into four domains.
DOMAINS
Practices that help Practices that result in Practices associated with Practices that interface
organize, manage, and collections of corporate analysis and assurance with traditional network
measure a software knowledge used in carrying of particular software security and software
security initiative. out software security development artifacts and maintenance organizations.
Staff development is activities throughout processes. All software Software configuration,
also a central the organization. security methodologies maintenance, and other
governance practice. Collections include both include these practices. environment issues
proactive security guidance have direct impact on
and organizational software security.
threat modeling.
PRACTICES
1. Strategy & Metrics 4. Attack Models 7. Architecture Analysis 10. Penetration

(SM) (AM) (AA) Testing
(PT)
2. Compliance & Policy 5. Security Features 8. Code Review
(CP) & Design (CR) 11. Software
(SFD) Environment
3. Training 9. Security Testing
(SE)
(T) 6. Standards & (ST)
Requirements 12. Configuration
(SR) Management &
Vulnerability
Management
(CMVM)

THE BSIMM10 SKELETON
The BSIMM skeleton provides a way to view the model at a glance and is useful when assessing an SSI. The skeleton is
shown below, organized by practices and levels. More complete descriptions of the activities and examples are available in
Part Three of this document.
GOVERNANCE
STRATEGY & METRICS (SM) COMPLIANCE & POLICY (CP) TRAINING (T)
LEVEL 1 LEVEL 1 LEVEL 1

• SM1.1 Publish process and evolve • CP1.1 Unify regulatory pressures. • T1.1 Conduct awareness training.
as necessary.
• CP1.2 Identify PII obligations. • T1.5 Deliver role-specific
• SM1.2 Create evangelism role and advanced curriculum.
perform internal marketing. • CP1.3 Create policy.
• T1.7 Deliver on-demand
• SM1.3 Educate executives. individual training.
• SM1.4 Identify gate locations, gather
necessary artifacts.

• SM2.1 Publish data about software • CP2.1 Identify PII inventory. • T2.5 Enhance satellite through
security internally. training and events.
• CP2.2 Require security sign-off for
• SM2.2 Enforce gates with measurements compliance-related risk. • T2.6 Include security resources
and track exceptions. in onboarding.
• CP2.3 Implement and track controls
• SM2.3 Create or grow a satellite. for compliance. • T2.8 Create and use material specific
to company history.
• SM2.6 Require security sign-off. • CP2.4 Include software security SLAs
in all vendor contracts.
• CP2.5 Ensure executive awareness of
compliance and privacy obligations.

• SM3.1 Use an internal tracking • CP3.1 Create a regulator • T3.1 Reward progression
application with portfolio view. compliance story. through curriculum.
• SM3.2 Run an external • CP3.2 Impose policy on vendors. • T3.2 Provide training for vendors
marketing program. or outsourced workers.
• CP3.3 Drive feedback from software
• SM3.3 Identify metrics and use lifecycle data back to policy. • T3.3 Host software security events.
them to drive budgets. • T3.4 Require an annual refresher.
• SM3.4 Integrate software-defined • T3.5 Establish SSG office hours.
lifecycle governance.
• T3.6 Identify new satellite members
through training.

INTELLIGENCE
SECURITY FEATURES STANDARDS

ATTACK MODELS (AM)
& DESIGN (SFD) & REQUIREMENTS (SR)

• AM1.2 Create a data classification • SFD1.1 Build and publish • SR1.1 Create security standards.
scheme and inventory. security features. • SR1.2 Create a security portal.
• AM1.3 Identify potential attackers. • SFD1.2 Engage the SSG with • SR1.3 Translate compliance
• AM1.5 Gather and use architecture teams. constraints to requirements.
attack intelligence.

• AM2.1 Build attack patterns and abuse • SFD2.1 Leverage secure-by-design • SR2.2 Create a standards
cases tied to potential attackers. middleware frameworks and review board.
common libraries.
• AM2.2 Create technology-specific • SR2.4 Identify open source.
attack patterns. • SFD2.2 Create an SSG capability • SR2.5 Create SLA boilerplate.
to solve difficult design problems.
• AM2.5 Build and maintain a top N
possible attacks list.
• AM2.6 Collect and publish
attack stories.
• AM2.7 Build an internal forum
to discuss attacks.

• AM3.1 Have a science team that • SFD3.1 Form a review board or central • SR3.1 Control open source risk.
develops new attack methods. committee to approve and maintain • SR3.2 Communicate standards
secure design patterns.
• AM3.2 Create and use automation to vendors.
to mimic attackers. • SFD3.2 Require use of approved • SR3.3 Use secure coding standards.
security features and frameworks.
• AM3.3 Monitor automated • SR3.4 Create standards for
asset creation. • SFD3.3 Find and publish mature technology stacks.
design patterns from the organization.

SSDL TOUCHPOINTS
ARCHITECTURE ANALYSIS (AA) CODE REVIEW (CR) SECURITY TESTING (ST)

• AA1.1 Perform security feature review. • CR1.2 Have the SSG perform • ST1.1 Ensure QA supports edge/
• AA1.2 Perform design review for ad hoc review. boundary value condition testing.
high-risk applications. • CR1.4 Use automated tools along • ST1.3 Drive tests with security
• AA1.3 Have SSG lead design with manual review. requirements and security features.
review efforts. • CR1.5 Make code review mandatory
• AA1.4 Use a risk questionnaire for all projects.
to rank applications. • CR1.6 Use centralized reporting to
close the knowledge loop and
drive training.

• AA2.1 Define and use AA process. • CR2.5 Assign tool mentors. • ST2.1 Integrate black-box security
tools into the QA process.
• AA2.2 Standardize • CR2.6 Use automated tools
architectural descriptions. with tailored rules. • ST2.4 Share security results with QA.
• CR2.7 Use a top N bugs list • ST2.5 Include security tests in
(real data preferred). QA automation.
• ST2.6 Perform fuzz testing customized
to application APIs.

• AA3.1 Have engineering teams lead • CR3.2 Build a capability to combine • ST3.3 Drive tests with risk
AA process. assessment results. analysis results.
• AA3.2 Drive analysis results into • CR3.3 Eradicate specific bugs from the • ST3.4 Leverage coverage analysis.
standard architecture patterns. entire codebase. • ST3.5 Begin to build and apply
• AA3.3 Make the SSG available as • CR3.4 Automate malicious adversarial security tests (abuse cases).
AA resource or mentor. code detection.
• CR3.5 Enforce coding standards.

DEPLOYMENT
CONFIGURATION
PENETRATION SOFTWARE MANAGEMENT &
TESTING (PT) ENVIRONMENT (SE) VULNERABILITY
MANAGEMENT (CMVM)

• PT1.1 Use external penetration testers • SE1.1 Use application input monitoring. • CMVM1.1 Create or interface with
to find problems. incident response.
• SE1.2 Ensure host and network
• PT1.2 Feed results to the defect security basics are in place. • CMVM1.2 Identify software defects
management and mitigation system. found in operations monitoring and
• PT1.3 Use penetration testing feed them back to development.
tools internally.

• PT2.2 Penetration testers use all • SE2.2 Publish installation guides. • CMVM2.1 Have emergency
available information. codebase response.
• SE2.4 Use code signing.
• PT2.3 Schedule periodic penetration • CMVM2.2 Track software bugs found
tests for application coverage. in operations through the fix process.
• CMVM2.3 Develop an operations
inventory of applications.

• PT3.1 Use external penetration testers • SE3.2 Use code protection. • CMVM3.1 Fix all occurrences of
to perform deep-dive analysis. software bugs found in operations.
• SE3.3 Use application behavior
• PT3.2 Have the SSG customize monitoring and diagnostics. • CMVM3.2 Enhance the SSDL
penetration testing tools and scripts. to prevent software bugs found
• SE3.4 Use application containers.
in operations.
• SE3.5 Use orchestration for containers
• CMVM3.3 Simulate software crises.
and virtualized environments.
• CMVM3.4 Operate a bug
• SE3.6 Enhance application inventory
bounty program.
with operations bill of materials.
• CMVM3.5 Automate verification of
• SE3.7 Ensure cloud security basics.
operational infrastructure security.

WHAT BSIMM10 TELLS US
This section provides information about BSIMM10 participants. We show the current data pool composition, the
BSIMM10 scorecard for the 122 firms across 119 activities, and some analysis of the industry verticals represented. We
also discuss emerging trends in the BSIMM10 data.
The BSIMM data pool includes participants from a variety of vertical markets. Figure 2 below provides counts for those
vertical markets with sufficient members to allow reporting on that group. To help protect member privacy, we don’t
publish details on verticals with very few members.
ASIA
IoT PACIFIC
(13) (5)
UNITED KINGDOM/
CLOUD EUROPE
(20) (15)
FINANCIAL
(57)
HEALTHCARE
(16)
INSURANCE
(11)
RETAIL
(9)
ISV
TECH NORTH
(43)
(20) AMERICA
(102)
Figure 2. BSIMM10 Participating Firms. These are the participant counts per tracked vertical in the BSIMM10 data pool. Note that some
firms are in multiple vertical markets and some firms are in verticals not listed here, such as energy and telecoms.
The BSIMM data yield very interesting analytical results as shown throughout this document. Shown on the next page are
the highest-resolution BSIMM data that are published. Organizations can use these data to note how often we observe
each activity across all 122 participants and use that information to help plan their next areas of focus. Activities that are
broadly popular across all vertical markets will likely benefit your organization as well.

BSIMM10 BSIMM10 BSIMM10 BSIMM10
BSIMM10 BSIMM10 BSIMM10
FIRMS BSIMM10 FIRMS FIRMS FIRMS
ACTIVITY ACTIVITY FIRMS ACTIVITY FIRMS ACTIVITY FIRMS
(out of FIRMS (%) (out of (out of (out of
(%) (%) (%)
122) 122) 122) 122)
STRATEGY & METRICS ATTACK MODELS ARCHITECTURE ANALYSIS PENETRATION TESTING

[SM1.1] 81 66.4% [AM1.2] 80 65.6% [AA1.1] 103 84.4% [PT1.1] 109 89.3%
[SM1.2] 66 54.1% [AM1.3] 36 29.5% [AA1.2] 29 23.8% [PT1.2] 94 77.0%
[SM1.3] 73 59.8% [AM1.5] 51 41.8% [AA1.3] 23 18.9% [PT1.3] 82 67.2%
[SM1.4] 107 87.7% [AM2.1] 8 6.6% [AA1.4] 62 50.8% [PT2.2] 25 20.5%
[SM2.1] 49 40.2% [AM2.2] 7 5.7% [AA2.1] 18 14.8% [PT2.3] 22 18.0%
[SM2.2] 53 43.4% [AM2.5] 16 13.1% [AA2.2] 14 11.5% [PT3.1] 11 9.0%
[SM2.3] 52 42.6% [AM2.6] 11 9.0% [AA3.1] 7 5.7% [PT3.2] 5 4.1%
[SM2.6] 51 41.8% [AM2.7] 10 8.2% [AA3.2] 1 0.8%
[SM3.1] 21 17.2% [AM3.1] 3 2.5% [AA3.3] 4 3.3%
[SM3.2] 6 4.9% [AM3.2] 2 1.6%
[SM3.3] 14 11.5% [AM3.3] 0 0.0%
[SM3.4] 0 0.0%
COMPLIANCE & POLICY SECURITY FEATURES & DESIGN CODE REVIEW SOFTWARE ENVIRONMENT
[CP1.1] 81 66.4% [SFD1.1] 98 80.3% [CR1.2] 80 65.6% [SE1.1] 66 54.1%
[CP1.2] 105 86.1% [SFD1.2] 69 56.6% [CR1.4] 85 69.7% [SE1.2] 111 91.0%
[CP1.3] 76 62.3% [SFD2.1] 31 25.4% [CR1.5] 44 36.1% [SE2.2] 36 29.5%
[CP2.1] 48 39.3% [SFD2.2] 40 32.8% [CR1.6] 44 36.1% [SE2.4] 27 22.1%
[CP2.2] 47 38.5% [SFD3.1] 11 9.0% [CR2.5] 39 32.0% [SE3.2] 13 10.7%
[CP2.3] 51 41.8% [SFD3.2] 12 9.8% [CR2.6] 21 17.2% [SE3.3] 4 3.3%
[CP2.4] 44 36.1% [SFD3.3] 4 3.3% [CR2.7] 23 18.9% [SE3.4] 14 11.5%
[CP2.5] 56 45.9% [CR3.2] 7 5.7% [SE3.5] 5 4.1%
[CP3.1] 25 20.5% [CR3.3] 1 0.8% [SE3.6] 3 2.5%
[CP3.2] 15 12.3% [CR3.4] 4 3.3% [SE3.7] 9 7.4%
[CP3.3] 7 5.7% [CR3.5] 2 1.6%
TRAINING STANDARDS & REQUIREMENTS SECURITY TESTING CONFIG. MGMT. & VULN. MGMT.
[T1.1] 77 63.1% [SR1.1] 83 68.0% [ST1.1] 100 82.0% [CMVM1.1] 103 84.4%
[T1.5] 37 30.3% [SR1.2] 81 66.4% [ST1.3] 87 71.3% [CMVM1.2] 101 82.8%
[T1.7] 46 37.7% [SR1.3] 85 69.7% [ST2.1] 32 26.2% [CMVM2.1] 91 74.6%
[T2.5] 27 22.1% [SR2.2] 52 42.6% [ST2.4] 15 12.3% [CMVM2.2] 88 72.1%
[T2.6] 28 23.0% [SR2.4] 46 37.7% [ST2.5] 9 7.4% [CMVM2.3] 64 52.5%
[T2.8] 28 23.0% [SR2.5] 35 28.7% [ST2.6] 9 7.4% [CMVM3.1] 2 1.6%
[T3.1] 3 2.5% [SR3.1] 22 18.0% [ST3.3] 2 1.6% [CMVM3.2] 9 7.4%
[T3.2] 16 13.1% [SR3.2] 11 9.0% [ST3.4] 1 0.8% [CMVM3.3] 12 9.8%
[T3.3] 15 12.3% [SR3.3] 9 7.4% [ST3.5] 2 1.6% [CMVM3.4] 13 10.7%
[T3.4] 14 11.5% [SR3.4] 24 19.7% [CMVM3.5] 0 0.0%
[T3.5] 5 4.1%
[T3.6] 1 0.8%
Table 2. BSIMM10 Scorecard. The scorecard shows how often each of the activities in the BSIMM were observed in the BSIMM10 data pool
from 122 firms.

In the BSIMM10 Scorecard, we also identified the most common activity in each practice (highlighted in the scorecard).
These 12 activities were observed in at least 77 (63%) of the 122 firms we studied (see the appendix for
“Table 7. Most Common Activities Per Practice”).
We created spider charts by noting the highest-level activity observed for each practice per BSIMM participant (a
“high-water mark”) and then averaging these values over the group of 122 firms to produce 12 numbers (one for each
practice). The resulting spider chart (Figure 3) plots these values on 12 spokes corresponding to the 12 practices. Note
that performing level 3 (the outside edge) activities is often a sign of SSI maturity but only because organizations tend to
start with common activities (level 1) and build from there. Other, more sophisticated analyses are possible, of course.
VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
ALLFIRMS (122)
Figure 3. AllFirms Spider Chart. This diagram shows the average of the high-water mark collectively reached in each practice by the
122 BSIMM10 firms.
By computing these high-water mark values and an observed score for each firm in the study, we can also compare relative
and average maturity for one firm against the others. The range of observed scores in the current data pool is [5, 83].
We’re pleased that the BSIMM study continues to grow year after year. The dataset we report on here is nearly 38 times
the size it was for the original publication. Note that once we exceeded a sample size of 30 firms, we began to apply
statistical analysis, yielding statistically significant results.

BSIMM10 AND INDUSTRY VERTICALS ANALYSIS
Spider charts are also useful for comparing groups of firms from particular industry verticals. The following figures show
data from verticals in BSIMM10.
VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
CLOUD (20 of 122) INTERNET OF THINGS (13 OF 122) TECH (20 OF 122)
Figure 4. Cloud vs. Internet of Things vs. Tech Spider Chart. Mature verticals still show distinct differences.
Cloud, Internet of Things, and high-technology firms are three of the most mature verticals in the BSIMM10 data pool.
On average, cloud firms (which are not necessarily equivalent to cloud service providers) are noticeably more mature
in the Governance and Intelligence domains compared to the technology and Internet of Things firms but noticeably
less mature in the Attack Models practice. By the same measure, technology and Internet of Things firms show greater
maturity in the Security Testing, Penetration Testing, and Software Environment practices. Despite these obvious
differences, there is a great deal of overlap. We believe that technology stacks and architectures, and therefore many of
the associated software security activities, between these three verticals are continuing to converge.

VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
FINANCIAL (57 of 122) HEALTHCARE (16 OF 122) INSURANCE (11 OF 122)
Figure 5. Financial vs. Healthcare vs. Insurance Spider Chart. Although they share similar compliance drivers, these groups of organizations
have different average maturity levels.
Three verticals in the BSIMM operate in highly regulated industries: financial services, healthcare, and insurance. In our
experience with the BSIMM, large financial services firms reacted to regulatory changes and started their SSIs much
earlier than insurance and healthcare firms. Even as the number of financial services firms has more than doubled over
the past five years with a large influx into the BSIMM data pool of newly started initiatives, the financial services SSG
average age at last assessment time remains 5.4 years, versus 3.2 years for insurance and 3.1 years for healthcare. Time
spent by financial services firms maturing their collective SSIs shows up clearly in the side-by-side comparison. Although
organizations in the insurance vertical include some mature outliers, the data for these three regulated verticals show
insurance lags behind in the Strategy & Metrics, Compliance & Policy, and Attack Models practices, while moving above
average in the Security Testing practice. Compared to financial services firms, we see a similar contrast in healthcare,
which achieves par in Compliance & Policy, Architecture Analysis, and Penetration Testing, but lags in other practices.
The overall maturity of the healthcare vertical remains low.

VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
TECH (20 OF 122) HEALTHCARE (16 OF 122)
Figure 6. Tech vs. Healthcare Spider Chart. Although healthcare firms are increasingly building devices and associated services, their overall
maturity lags behind technology firms that do similar things.
In the BSIMM population, we can find large gaps between the maturity of verticals, even when the technology stacks
might be similar. Consider the spider diagram that directly compares the current technology and healthcare verticals. In
this case, there is an obvious delta between technology firms that build devices tied to back-end services and healthcare
firms that increasingly build devices tied to back-end services. The disparity in maturity extends to most practices.
Fortunately for organizations that find themselves behind the curve, the experiences of many BSIMM participants
provide a good roadmap to faster maturity.

VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
ALLFIRMS (122) RETAIL (9 of 122)
Figure 7. AllFirms vs. Retail Spider Chart. While it may have taken some years for retail firms to begin using the BSIMM in earnest,
they have been working on their SSIs.
For the second year, the BSIMM presents data on the retail vertical. This group, with an average SSG age at time of last
assessment of 4.0 years and average SSG size of 8.4 full-time people, seems to track closely to the overall data pool.
The most obvious differences are in the Security Features & Design, Penetration Testing, Software Environment, and
Configuration Management & Vulnerability Management practices, where retail participants are somewhat ahead of the
average for all firms.

EMERGING TRENDS IN THE BSIMM10 DATA
As the BSIMM community grew, we added a greater number of firms with newer SSIs and began to track new verticals
that have less software security experience. Thus, we expected to see a direct impact on the data. Specifically, adding
firms with less experience decreased the average score to 33.1 in BSIMM8, from 33.9 in BSIMM7 and 36.7 in BSIMM6,
even as re-measurements have shown that individual firm maturity increases over time.
For BSIMM9, however, the average score increased to 34.0 and increased again to 35.6 for BSIMM10. One
reason for this change—a potential reversal of the decline in overall maturity—appears to be the mix of firms
using the BSIMM:
• The average SSG age for new firms entering BSIMM6 was 2.9 years; it was 3.37 years for BSIMM7, 2.83
years for BSIMM8, and increased to 4.57 years for BSIMM9. On the other hand, the average SSG age for
new firms in BSIMM10 is 3.42 years.
• A second reason appears to be an increase in firms continuing to use the BSIMM to guide their initiatives.
BSIMM7 included 11 firms that received their second or higher assessment. That figure increased to 12 firms
for BSIMM8, 16 firms for BSIMM9, and remained at 16 firms for BSIMM10.
• A third reason appears to be the effect of firms aging out of the data pool. We removed 55 firms for
BSIMM-V through BSIMM9 and an additional 17 firms for BSIMM10; interestingly, nine of the 72 firms that
had once aged out of the BSIMM data pool have subsequently had a new assessment.
We also see this potential reversal (i.e., a return to an upward trend) in mature verticals such as financial services where
average overall maturity decreased to 35.6 in BSIMM8 from 36.2 in BSIMM7 and 38.3 in BSIMM6. For BSIMM9,
however, the average financial services score increased to 36.8 and increased again for BSIMM10 to 37.6. Of potential
impact here, five of the 11 firms dropped from BSIMM9 due to data age were in the financial services group, while that
figure was only two of 17 firms dropped for BSIMM10. On the other hand, a different trend might be starting in personnel
where, with the exception of some outliers, we observed an overall decrease in SSG size on first measurement to 9.6, but the
first measurement average had increased from 6.1 for BSIMM7 and 8.8 for BSIMM8 to 11.6 for BSIMM9.
Note that a large number of firms with no satellite continue to exist in the community, which causes the median satellite
size to be zero (65 of 122 firms had no satellite at the time of their current assessment, and nearly 50% of the firms
added for BSIMM10 had no satellite at assessment time). BSIMM participants, however, continue to report that the
existence of a satellite is directly tied to SSI maturity. For the 57 BSIMM10 firms with a satellite at assessment time, the
average size was 110 with a median of 25. Notably, the average score for the 57 firms with a satellite is 43.9, while the
average score for the 65 firms without a satellite is 28.4.
For BSIMM8, we zoomed in on two particular activities as part of our analysis. Observations of [AA3.3 Make the
SSG available as an AA resource or mentor] dropped to 2% in the BSIMM8 community, from 5% in BSIMM7, 17% in
BSIMM6, and 30% in BSIMM-V. However, observations rose to 3% for BSIMM9 and remained at 3% for BSIMM10.
Observations of [SR3.3 Use secure coding standards] dropped to 14% in BSIMM8, from 18% in BSIMM7, 29% in
BSIMM6, and 40% in BSIMM-V. In this case, the slide continued to 8% for BSIMM9 and 7% in BSIMM10. This kind of
change can be seen in activities spanning all 12 practices. In some cases, it appears that instead of focusing on a robust,
multi-activity approach to a given practice, many firms have a tendency to pick one figurehead activity (e.g., static
analysis with a tool or penetration testing) on which to focus their investment in money, people, and effort. In other
cases, it appears that some SSGs have moved away from being the source of expertise on software security architecture
and secure coding standards, without the organization having those skills and knowledge appropriately spread across the
product teams.
Firms that have been in the BSIMM community for multiple years have, with one or two exceptions, always increased the
number of activities they are able to deploy and maintain over time. We expect the majority of newer firms entering the
BSIMM population to do the same.

PART THREE: BSIMM10 ACTIVITIES
GOVERNANCE: STRATEGY & METRICS (SM)
The Strategy & Metrics practice encompasses planning, assigning roles and responsibilities, identifying software security
goals, determining budgets, and identifying metrics and gates.
SM LEVEL 1
[SM1.1: 81] Publish process and evolve as necessary.
The process for addressing software security is published and broadcast to all stakeholders so that everyone knows the
plan. Goals, roles, responsibilities, and activities are explicitly defined. Most organizations pick an existing methodology,
such as the Microsoft SDL or the Synopsys Touchpoints, and then tailor it to meet their needs. The secure SDLC process
must be adapted to the specifics of the development process it governs (e.g., waterfall, agile, CI/CD, DevOps, etc.)
because it will evolve with both the organization and the security landscape. In many cases, the process is controlled
by the SSG and published only internally; it doesn’t need to be publicly promoted outside the firm to have the desired
impact. In addition to publishing the process, some firms also encode it into an application lifecycle management (ALM)
tool as workflow.
[SM1.2: 66] Create evangelism role and perform internal marketing.
To build support for software security throughout the organization, someone in the SSG must play an evangelism role.
This internal marketing function helps keep executives and other stakeholders up to date on the magnitude of the
software security problem and the elements of its solution. An agile coach familiar with security, for example, could
help teams adopt better software security practices as they transform to an agile methodology. Evangelists can increase
understanding and build credibility by giving talks to internal groups (including executives), extending invitations to
well-known experts, authoring white papers for internal consumption, or creating a collection of papers, books, and other
resources on an internal website and promoting its use. An early example of such an evangelist was Michael Howard’s role
at Microsoft just after Bill Gates’ 2002 security memo kicked off the company’s new security strategy.
[SM1.3: 73] Educate executives.
Executives are periodically shown the consequences of inadequate software security and the negative business impact
it can have on the organization. They’re also shown what other organizations are doing to mature software security,
including how they deal with the risks of adopting “flavor of the day” engineering methodologies with no oversight. By
understanding both the problems and their proper resolutions, executives can support the SSI as a risk management
necessity. In its most dangerous form, security education arrives courtesy of malicious hackers or public data exposure
incidents. Preferably, the SSG will demonstrate a worst-case scenario in a controlled environment with the permission
of all involved (e.g., by actually showing working exploits and their business impact). In some cases, presentation to the
Board can help garner resources for an ongoing SSI. Bringing in an outside guru is often helpful when seeking to bolster
executive attention. Tying education to specific development areas, such as mobile or cloud services, or particular
methodologies, such as CI/CD and DevOps, can likewise help convince leadership to accept SSG recommendations
when they might otherwise be ignored in favor of faster release dates or other priorities.
[SM1.4: 107] Identify gate locations, gather necessary artifacts.
The software security process includes release gates (or checkpoints, guardrails, milestones, etc.) at one or more points in the
SDLC or, more likely, multiple SDLCs. The first two steps toward establishing security-specific release gates are to identify
gate locations that are compatible with existing development practices and to then begin gathering the input necessary
to make a go/no-go decision. Importantly, the gates might not be enforced. For example, the SSG can collect security
testing results for each project prior to release then provide their informed opinion on what constitutes sufficient testing or
acceptable test results without trying to stop a project from moving forward. Shorter release cycles, as seen in organizations
practicing CI/CD, often require creative approaches to collecting the right evidence and rely heavily on lightweight, super-
fast automation. The idea of identifying gates first and enforcing them later is extremely helpful in moving development
toward software security without major pain. Socializing the gates and then turning them on once most projects already
know how to succeed is a gradual approach that can motivate good behavior without requiring it.

SM LEVEL 2
[SM2.1: 49] Publish data about software security internally.
To facilitate improvement, the SSG publishes data internally about the state of software security within the organization.
This information might come in the form of a dashboard with metrics for executives and software development
management. Sometimes, these published data won’t be shared with everyone in the firm but only with relevant
executives who then drive change in the organization. In other cases, open book management and data published to
all stakeholders helps everyone know what’s going on, the philosophy being that sunlight is the best disinfectant. If the
organization’s culture promotes internal competition between groups, this information can add a security dimension. The
time compression associated with CI/CD calls for measurements that can be taken quickly and accurately, and might
initially focus less on historical trends (e.g., bugs per release) and more on speed (e.g., time to fix).
[SM2.2: 53] Enforce gates with measurements and track exceptions.
Software lifecycle security gates are enforced for every project, so to pass a gate, a project must either meet an
established measure or obtain a waiver. Even recalcitrant project teams must now play along and the SSG tracks
exceptions. In some cases, gates are directly associated with regulations, contractual agreements, and other obligations,
with exceptions tracked as required by statutory or regulatory drivers. In other cases, gate measures yield key
performance indicators that are used to govern the process. Allowing any projects to automatically pass or automatically
granting waivers without due consideration defeats the purpose of enforcing a gate. Even seemingly innocuous software
projects, such as a new mobile client for an existing back end or an application ported to a cloud environment from an
internal data center, must successfully pass the prescribed security gates in order to progress or remain in production.
Similarly, APIs, frameworks, libraries, bespoke code, microservices, container configurations, and so on are all software
that must traverse the security gates. Remember, it’s possible, and often very useful, to have enforced gates both before
and after the development process itself.
[SM2.3: 52] Create or grow a satellite.
Create a collection of people scattered across the organization who show an above-average level of security interest or
skill—a satellite. Forming this group of advocates, sometimes referred to as champions, is a step toward creating a social
network that speeds the adoption of security into software engineering. One way to build the initial group is to track the
people who stand out during introductory training courses; see [T3.6 Identify new satellite members through training].
Another way is to ask for volunteers. In a more top-down approach, initial satellite membership is assigned to ensure
complete coverage of all development/product groups, but ongoing membership is based on actual performance. A strong
satellite is a good sign of a mature SSI. In new or fast-moving technology areas, satellite members can help combine
software security skills with domain knowledge that might be underrepresented in the SSG. Agile coaches and DevOps
engineers make particularly useful satellite members, especially for detecting and removing process friction.
[SM2.6: 51] Require security sign-off.
The organization has an initiative-wide process for accepting security risk and documenting accountability, with a risk
acceptor signing off on the state of all software prior to release. The sign-off policy might require the head of a business
unit to sign off on critical vulnerabilities that have not been mitigated or on SSDL steps that have been skipped, for
example. The sign-off policy must apply both to outsourced projects, such as a boutique mobile application, and to
projects that will be deployed in external environments, such as the cloud. Informal or uninformed risk acceptance alone
isn’t a security sign-off because the act of accepting risk is more effective when it’s formalized (e.g., with a signature, a
form submission, or something similar) and captured for future reference. Similarly, simply stating that certain projects
don’t need sign-off at all won’t achieve the desired risk management results. In some cases, however, the risk acceptor
can provide the sign-off on a particular set of software project acceptance criteria, which are then implemented in
automation to ensure that the criteria are applied in the fastest processes; however, there must be an ongoing verification
that the criteria remain accurate and the automation is actually working.

SM LEVEL 3
[SM3.1: 21] Use an internal tracking application with portfolio view.
The SSG uses centralized tracking automation to chart the progress of every piece of software in its purview, regardless
of development methodology. The automation records the security activities scheduled, in progress, and completed,
incorporating results from activities such as architecture analysis, code review, and security testing even when they
happen in a tight loop. A combined inventory and risk posture view is fundamental. The SSG uses the automation to
generate portfolio reports for multiple metrics and, in many cases, publishes these data, at least among executives.
Depending on the culture, this can cause interesting effects via internal competition. As an initiative matures and
activities become more distributed, the SSG uses the centralized reporting system to keep track of all the moving parts.
[SM3.2: 6] Run an external marketing program.
To build external awareness, the SSG helps the firm market the SSI outside the internal teams. In this way, software
security can grow beyond being a risk reduction exercise and instead become a competitive advantage or market
differentiator. The SSG might publish papers or books about its software security capabilities, or have a public blog. It
might provide details in external conferences or trade shows. In some cases, a complete SSDL methodology can be
published and promoted outside the firm, with mobile, cloud, and new technology security projects making important
software security case studies. Regardless of venue, the process of sharing details externally and inviting critique is used
to bring new perspectives into the firm.
[SM3.3: 14] Identify metrics and use them to drive budgets.
The SSG and its management choose the metrics that define and measure SSI progress in quantitative terms. These metrics
in turn drive the initiative’s budget and resource allocations, so simple counts and out-of-context measurements won’t
suffice here. One such metric could be security defect density, a reduction in which could be used to show a decreasing
cost of remediation over time. Recall that, in agile methodologies, metrics are best collected early and often in a lightweight
manner. The key is to tie technical results to business objectives in a clear and obvious fashion in order to justify funding.
Because the concept of security is already tenuous to many business people, making an explicit tie-in can be helpful.
[SM3.4: 0] Integrate software-defined lifecycle governance.
Organizations begin replacing traditional document, presentation, and spreadsheet-based lifecycle management with
software-based delivery platforms. Humans, sometimes aided by tools, no longer drive progression from each lifecycle
phase to the next. Instead, organizations rely on automation to drive the management and delivery process with ALM/
ADLM software, such as Spinnaker, and humans participate asynchronously (and often optionally), like services.
Automation often extends beyond the scope of CI/CD to include functional and nonfunctional aspects of delivery,
including health checks, cut-over on failure, rollback to known good software, defect discovery and management,
compliance verification, and a way to ensure adherence to policies and standards. Some organizations are also evolving
their lifecycle management approach by integrating their compliance and defect discovery data to begin moving from a
series of point-in-time go/no-go decisions (e.g., a security test at each gate) to a future state of continuous accumulation
of assurance data (e.g., output from sensors embedded in development and production).
GOVERNANCE: COMPLIANCE & POLICY (CP)

The Compliance & Policy practice is focused on identifying controls for compliance regimens such as PCI DSS and
HIPAA, developing contractual controls such as service-level agreements (SLAs) to help control COTS software risk,
setting organizational software security policy, and auditing against that policy.
CP LEVEL 1
[CP1.1: 81] Unify regulatory pressures.
If the business or its customers are subject to regulatory or compliance drivers such as the Payment Card Industry
security standards; GLBA, SOX, and HIPAA in the United States; or GDPR in the EU, the SSG acts as a focal point
for understanding the constraints such drivers impose on software. In some cases, the SSG creates or collaborates on a

unified approach that removes redundancy and conflicts from overlapping compliance requirements. A formal approach
will map applicable portions of regulations to control statements explaining how the organization complies. As an
alternative, existing business processes run by legal or other risk and compliance groups outside the SSG could also serve
as the regulatory focal point. A unified set of software security guidance for meeting regulatory pressures ensures that
compliance work is completed as efficiently as possible. Some firms move on to influencing the regulatory environment
directly by becoming involved in standards groups exploring new technologies and mandates.
[CP1.2: 105] Identify PII obligations.
The SSG plays a key role in identifying and describing PII obligations stemming from regulation and customer expectations
by using this information to promote best practices related to privacy. The way software handles PII might be explicitly
regulated, but even if it isn’t, privacy is a hot topic. For example, if the organization processes credit card transactions, the
SSG will help in identifying the constraints that the PCI DSS places on the handling of cardholder data and then inform
all stakeholders. Note that outsourcing to hosted environments (e.g., the cloud) doesn’t relax PII obligations and can even
increase the difficulty of recognizing all associated obligations. Also note that firms creating software products that process
PII (where the firms don’t necessarily handle it directly) can meet this need by providing privacy controls and guidance for
their customers. Given evolving consumer privacy expectations, proliferation of “software is in everything” and data scraping
and correlation (e.g., social media) adds yet another dimension to PII protection.
[CP1.3: 76] Create policy.
The SSG guides the rest of the organization by creating or contributing to software security policy that satisfies
internal, regulatory, and customer-driven security requirements. This policy includes a unified approach for satisfying
the (potentially lengthy) list of security drivers at the governance level. As a result, project teams can avoid keeping up
with the details involved in complying with all applicable regulations or other mandates. Likewise, project teams won’t
need to relearn customer security requirements on their own. SSG policy statements can sometimes focus on major
compliance topics, such as handling PII or using cryptography. In some cases, policy will relate directly to the SSDL and
its use in the firm. Because they might be new topics, codifying decisions about IoT, cloud, and mobile architectures can
rekindle interest in setting policy. Similarly, it can be necessary, for example, to explain what can and can’t be automated
into CI/CD and continuous deployment pipelines (see [SM3.4 Integrate software-defined lifecycle governance]).
Architecture standards and coding guidelines aren’t examples of policy, but policy that prescribes and mandates the use
of coding guidelines and architecture standards for certain software categories falls under the umbrella. Policy is what is
permitted and denied at the initiative level; if it’s not mandatory, it’s not policy. In many cases, policy statements must
be translatable into automation for use in a software-defined lifecycle, not just a process enforced by humans, but even
automated policy must be mandatory.
CP LEVEL 2
[CP2.1: 48] Identify PII inventory.
The organization identifies the kinds of PII processed or stored by each of its systems, along with their associated data
repositories. A PII inventory can be approached in two ways: starting with each individual application by noting its PII use
or starting with particular types of PII and noting the applications that touch them. System architectures have evolved
such that PII will flow into cloud-based service and end-point device ecosystems, and come to rest there (e.g., content
delivery networks, social networks, mobile devices, IoT devices), making it tricky to keep an accurate PII inventory. The
inventory must be easily referenced in critical situations, such as making a list of databases that would require customer
notification if breached or a list to use in crisis simulations (see [CMVM3.3 Simulate software crises]).

[CP2.2: 47] Require security sign-off for compliance-related risk.
The organization has a formal compliance risk acceptance and accountability process that addresses all software development
projects. In that process, the SSG acts as an advisor when the risk acceptor signs off on the software’s state prior to release.
For example, the sign-off policy might require the head of the business unit to sign off on compliance issues that haven’t
been mitigated or on compliance-related SSDL steps that have been skipped. Sign-off should be explicit and captured
for future reference, with any exceptions tracked, even under the fastest of agile methodologies. Note that an application
without security defects might still be noncompliant so a clean penetration test is not a substitute for a compliance sign-
off. Even in DevOps organizations where engineers have the technical ability to release software, there is still a need for a
deliberate risk acceptance step even if the criteria are embedded in automation. In cases where the risk acceptor signs off
on a particular set of compliance acceptance criteria that are then implemented in automation, there must be an ongoing
verification that the criteria remain accurate and the automation is actually working.
[CP2.3: 51] Implement and track controls for compliance.
The organization can demonstrate compliance with applicable requirements because its SSDL is aligned with the control
statements developed by the SSG (see [CP1.1 Unify regulatory pressures]). The SSG tracks SDLC controls, navigates
problem areas, and ensures auditors and regulators are satisfied. If the organization’s SDLC is predictable and reliable, the
SSG might be able to remain in the background because following the SSDL generates the desired compliance evidence.
Increasingly, the DevOps approach of embedding compliance controls in process shows up within software-defined
infrastructure and networks rather than in process and manual intervention. A firm doing this properly can explicitly
associate satisfying its compliance concerns with following its SSDL.
[CP2.4: 44] Include software security SLAs in all vendor contracts.
Vendor contracts include an SLA to ensure that a vendor won’t jeopardize the organization’s compliance story or SSI.
Each new or renewed contract contains provisions requiring the vendor to address software security and deliver a product
or service compatible with the organization’s security policy (see [SR2.5 Create SLA boilerplate]). In some cases, open
source licensing concerns initiate the vendor management process, which can open the door for additional software
security language in the SLA. Traditional IT security requirements and a simple agreement to allow penetration testing
aren’t sufficient here.
[CP2.5: 56] Ensure executive awareness of compliance and privacy obligations.
To gain executive buy-in around compliance and privacy activities, the SSG provides executives with plain-language
explanations of the organization’s compliance and privacy obligations, along with the potential consequences of failing to
meet those obligations. For some organizations, explaining the direct cost and likely fallout from a compliance failure or
data breach is be an effective way to broach the subject. For others, having an outside expert address the Board works
because some executives value an outside perspective more than an internal one. A sure sign of proper executive buy-in
is adequate allocation of resources to meet those obligations. While useful for bootstrapping efforts, be aware that the
sense of urgency typically following a breach will not last.
CP LEVEL 3
[CP3.1: 25] Create a regulator compliance story.
The SSG has the information regulators want, so a combination of written policy, controls documentation, and artifacts
gathered through the SSDL gives the SSG the ability to demonstrate the organization’s compliance story without a
fire drill for every audit or a piece of paper for every sprint. Often, regulators, auditors, and senior management will be
satisfied with the same kinds of reports that can be generated directly from various tools. In some cases, the organization
will require additional information from vendors about how the vendor’s controls support organizational compliance needs
(e.g., cloud providers, especially in a multi-cloud deployment). It will often be necessary to normalize information that
comes from disparate sources. While they are often the biggest, governments aren’t the only regulators of behavior.

[CP3.2: 15] Impose policy on vendors.
Vendors are required to adhere to the same policies used internally and must submit evidence that their software
security practices pass muster. For a given organization, vendors might comprise cloud providers, middleware providers,
virtualization providers, container and orchestration providers, bespoke software creators, contractors, and many more,
and each might be held to different policy requirements. Evidence of their compliance could include results from code
reviews or penetration tests, or from tests built directly into automation or infrastructure. Vendors might attest to the
fact that they perform certain SSDL processes. In some cases, a BSIMM score or a BSIMMsc score can help ensure that
vendors are complying with the firm’s software security policies.
[CP3.3: 7] Drive feedback from software lifecycle data back to policy.
Information from the software lifecycle is routinely fed back into the policy creation process to help find defects earlier
or to prevent them from occurring in the first place. In doing so, blind spots can be eliminated by mapping them to trends
in SSDL failures. The regular appearance of inadequate architecture analysis, recurring vulnerabilities, ignored security
gates, or the wrong firm choice for carrying out a penetration test can expose policy weakness. In some cases, lifecycle
data might indicate that policies impose too much bureaucracy, for example, by introducing friction that prevents
engineering from meeting the expected delivery cadence. Rapid technology evolution might also create policy gaps that
must be addressed. Over time, policies become more practical and easier to carry out (see [SM1.1 Publish process and
evolve as necessary]). Ultimately, policies are refined with SSDL data to enhance and improve a firm’s effectiveness.
GOVERNANCE: TRAINING (T)

Training has always played a critical role in software security because software developers and architects often start with
little security knowledge.
T LEVEL 1
[T1.1: 77] Conduct awareness training.
To promote a culture of software security throughout the organization, the SSG conducts awareness training. As
examples, the training might be delivered via SSG members, an outside firm, the internal training organization, or
e-learning. Course content doesn’t necessarily have to be tailored for a specific audience. For example, all developers,
QA engineers, and project managers could attend the same “Introduction to Software Security” course, but this activity
should be enhanced with a tailored approach that addresses the firm’s culture explicitly. Generic introductory courses
that cover basic IT or high-level software security concepts don’t generate satisfactory results. Likewise, awareness
training aimed only at developers and not at other roles in the organization is insufficient.
[T1.5: 37] Deliver role-specific advanced curriculum.
Software security training goes beyond building awareness by enabling trainees to incorporate security practices into their
work. This training is tailored to cover the tools, technology stacks, development methodologies, and bugs that are most
relevant to the trainees. For example, an organization could offer four tracks for its engineers: one for architects, one for
Java developers, one for mobile developers, and a fourth for testers. Tool-specific training is also commonly observed in
such a curriculum. Note that training is important for many different roles within an organization, including QA, product
management, executives, and others.
[T1.7: 46] Deliver on-demand individual training.
The organization lowers the burden on trainees and reduces the cost of delivering training by offering on-demand training
for individuals across roles. The most obvious choice, e-learning, can be kept up to date through a subscription model,
but an online curriculum must be engaging and relevant to the trainees in various roles to achieve its intended purpose.
Training that isn’t used won’t create any change, and hot topics like new IoT and cloud architectures and new delivery
styles such as gamification will attract more interest than boring policy discussions. For developers, it’s possible to provide
training directly through the IDE right when it’s needed, but in some cases, building a new skill (such as code review or
threat modeling) might be better suited for instructor-led training, which can also be provided on demand.

T LEVEL 2
[T2.5: 27] Enhance satellite through training and events.
The SSG strengthens the satellite network by inviting guest speakers or holding special events about advanced topics
(e.g., the latest software security techniques for DevOps or AWS cloud development). Offering attendees coffee
and snacks doesn’t hurt. This effort is about providing the satellite customized training so that it can fulfill its specific
responsibilities, not about inviting the satellite members to brown bags or signing them up for the standard computer-
based training. In addition, a standing conference call with voluntary attendance won’t get the desired results, which are
as much about building camaraderie as they are about sharing knowledge and organizational efficiency. Face-to-face
meetings are by far the most effective, even if they happen only once or twice a year and some participants must attend
over videoconferencing.
[T2.6: 28] Include security resources in onboarding.
The process for bringing new hires into an engineering organization requires that they complete a training module about
software security. The generic new hire process usually covers topics like picking a good password and making sure that
people don’t follow you into the building, but this orientation period can be enhanced to cover topics such as secure
coding, the SSDL, and internal security resources. The objective is to ensure that new hires contribute to the security
culture. Turnover in engineering organizations is generally high, and although a generic onboarding module is useful, it
doesn’t take the place of a timely and more complete introductory software security course.
[T2.8: 28] Create and use material specific to company history.
To make a strong and lasting change in behavior, training includes material specific to the company’s history. When
participants can see themselves in a problem, they’re more likely to understand how the material is relevant to their work
as well as when and how to apply what they’ve learned. One way to do this is to use noteworthy attacks on the company’s
software as examples in the training curriculum. This training shouldn’t cover platforms not used by developers (Windows
developers probably won’t care about old Unix problems) or examples of problems relevant only to languages no longer in
common use (Java developers probably don’t need to understand buffer overflows in C). Stories from company history
can help steer training in the right direction, but only if those stories are still relevant and not overly censored. Both
successful and unsuccessful attacks can make good teachable moments.
T LEVEL 3
[T3.1: 3] Reward progression through curriculum.
Knowledge is its own reward, but progression through the security curriculum brings other benefits, too, such as career
advancement. The reward system can be formal and lead to a certification or an official mark in the human resources
system, or it can be less formal and include motivators such as documented praise at annual review time. Involving a
corporate training department and/or HR team can make security’s impact on career progression more obvious, but the
SSG should continue to monitor security knowledge in the firm and not cede complete control or oversight. Coffee mugs
and t-shirts can build morale, but it might take the possibility of real career progression to change behavior.
[T3.2: 16] Provide training for vendors or outsourced workers.
Vendors and outsourced workers receive the same level of software security training given to employees. Spending time
and effort helping suppliers get security right at the outset is much easier than trying to determine what went wrong
later on, especially if the development team has moved on to other projects. Training individual contractors is much more
natural than training entire outsource firms and is a reasonable place to start. It’s important that everyone who works on
the firm’s software has an appropriate level of training, regardless of their employment status.
[T3.3: 15] Host software security events.
The organization highlights its security culture as a differentiator by hosting security events featuring external speakers
and content. Good examples of this are Microsoft’s BlueHat and QUALCOMM’s Mobile Security Summit, given their
featuring of external presenters and their focus on helping development create better code. Employees benefit from
hearing outside perspectives, especially those related to fast-moving technology areas, and the organization as a whole
benefits from putting its security credentials on display (see [SM3.2 Run an external marketing program]). Events open
only to small, select groups won’t result in the desired culture change across the organization.

[T3.4: 14] Require an annual refresher.
Everyone involved in the SSDL is required to take an annual software security refresher course. This course keeps the
staff up to date on security and ensures that the organization doesn’t lose focus due to turnover, evolving methodologies,
or changing deployment models. The SSG might take half a day to give an update on the security landscape and explain
changes to policies and standards. A refresher can also be rolled out as part of a firm-wide security day or in concert with
an internal security conference, but it’s useful only if it’s fresh.
[T3.5: 5] Establish SSG office hours.
The SSG offers help to anyone during an advertised lab period or regularly scheduled office hours. By acting as an
informal resource for people who want to solve security problems, the SSG leverages teachable moments and emphasizes
the carrot over the stick approach to security best practices. Office hours might be held one afternoon per week in the
office of a senior SSG member, but roving office hours are also a possibility, with visits to particular product or application
groups by request, perhaps prioritizing visits by key functionality being developed and its security implications.
[T3.6: 1] Identify new satellite members through training.
Recruit future satellite members (e.g., champions) by noting people who stand out during training courses, office hours,
capture-the-flag exercises, hack-a-thons, and other opportunities to show skill and enthusiasm, and encouraging them
to join the satellite. The satellite often begins as an assigned collection of people scattered across the organization who
show an above-average level of security interest or advanced knowledge of new technology stacks and development
methodologies (see [SM2.3 Create or grow a satellite]). Identifying future members proactively is a step toward creating
a social network that speeds the adoption of security into software development and operations. A group of enthusiastic
and skilled volunteers will be easier to lead than a group that is drafted.
INTELLIGENCE: ATTACK MODELS (AM)

Attack Models capture information used to think like an attacker: threat modeling, abuse case development and
refinement, data classification, and technology-specific attack patterns.
AM LEVEL 1
[AM1.2: 80] Create a data classification scheme and inventory.
Security stakeholders in an organization agree on a data classification scheme and use it to inventory software according
to the kinds of data the software handles, regardless of whether the software is on or off premise. This allows applications
to be prioritized by their data classification. Many classification schemes are possible—one approach is to focus on PII,
for example. Depending on the scheme and the software involved, it could be easiest to first classify data repositories
(see [CP2.1 Identify PII inventory]) and then derive classifications for applications according to the repositories they use.
Other approaches to the problem include data classification according to protection of intellectual property, impact of
disclosure, exposure to attack, relevance to GDPR, or geographic boundaries.
[AM1.3: 36] Identify potential attackers.
The SSG identifies potential attackers in order to understand their motivations and abilities. The outcome of this
exercise could be a set of attacker profiles that includes generic sketches for categories of attackers and more detailed
descriptions for noteworthy individuals. In some cases, a third-party vendor might be contracted to provide this
information. Specific and contextual attacker information is almost always more useful than generic information copied
from someone else’s list. Moreover, a list that simply divides the world into insiders and outsiders won’t drive useful
results. Identification of attackers should account for the organization’s evolving software supply chain and attack surface.
[AM1.5: 51] Gather and use attack intelligence.
The SSG stays ahead of the curve by learning about new types of attacks and vulnerabilities. In particular, by attending
technical conferences and monitoring attacker forums, then correlating that information with what’s happening in
the organization (perhaps by reviewing operational logs and telemetry), the SSG can identify potential problems and
collaborate with experts to learn more about emerging vulnerability exploitation. In many cases, a subscription to a
commercial service can provide a reasonable way of gathering basic attack intelligence. Regardless of its origin, attack
information must be made actionable and useful for developers, testers, and DevOps engineers.

AM LEVEL 2
[AM2.1: 8] Build attack patterns and abuse cases tied to potential attackers.
The SSG prepares for security testing and architecture analysis by building attack patterns and abuse cases tied to
potential attackers (see [AM1.3 Identify potential attackers]). However, these resources don’t have to be built from
scratch for every application in order to be useful; rather, standard sets might exist for applications with similar profiles,
and the SSG can add to the pile based on its own attack stories. For example, a story about an attack against a poorly
designed cloud application could lead to a cloud security attack pattern that drives a new type of testing. If a firm tracks
the fraud and monetary costs associated with particular attacks, this information can in turn be used to prioritize the
process of building attack patterns and abuse cases. Evolving software architectures (e.g., microservices, serverless) might
require organizations to evolve their attack pattern and abuse case creation approach and content.
[AM2.2: 7] Create technology-specific attack patterns.
The SSG creates technology-specific attack patterns to capture its knowledge about attacks that target specific
technologies. For example, if the organization’s cloud software relies on a cloud vendor’s security apparatus (e.g.,
cryptography), the SSG can catalogue the quirks of the crypto package and how it might be exploited. Attack patterns
directly related to the security frontier (e.g., IoT) can be useful here as well. It’s often easiest to start with existing
generalized attack patterns to create the needed technology-specific attack patterns, but simply adding, for example,
“for mobile applications” at the end won’t suffice.
[AM2.5: 16] Build and maintain a top N possible attacks list.
The SSG periodically digests the ever-growing list of attack types and focuses the organization on prevention efforts for
a prioritized short list—the top N—and uses it to drive change. This initial list can combine input from multiple sources,
both inside and outside the organization. Some organizations prioritize their list according to perception of potential
business loss while others might prioritize according to successful attacks against their software. The top N list doesn’t
need to be updated with great frequency, and attacks can be coarsely sorted. For example, the SSG might brainstorm
twice a year to create lists of attacks the organization should be prepared to counter “now,” “soon,” and “someday.”
[AM2.6: 11] Collect and publish attack stories.
To maximize the benefit from lessons that don’t always come cheap, the SSG collects and publishes stories about attacks
against the organization. Both successful and unsuccessful attacks can be noteworthy, and discussing historical information
about software attacks has the added effect of grounding software security in a firm’s reality. This is particularly useful in
training classes, to help counter a generic approach that might be overly focused on other people’s top 10 lists or outdated
platform attacks (see [T1.6 Create and use material specific to company history]). Hiding information about attacks from
people building new systems fails to garner any positive benefits from a negative happenstance.
[AM2.7: 10] Build an internal forum to discuss attacks.
The organization has an internal forum where the SSG, the satellite, and others discuss attacks and attack methods. The
discussion serves to communicate the attacker perspective to everyone. The SSG can also maintain an internal mailing
list that encourages subscribers to discuss the latest information on publicly known incidents. Dissection of attacks and
exploits that are relevant to a firm are particularly helpful when they spur discussion of development, infrastructure,
and other mitigations. Simply republishing items from public mailing lists doesn’t achieve the same benefits as active
discussion, nor does a closed discussion hidden from those actually creating code. Everyone should feel free to ask
questions and learn about vulnerabilities and exploits (see [SR1.2 Create a security portal]).
AM LEVEL 3
[AM3.1: 3] Have a science team that develops new attack methods.
The SSG has a science team that works to identify and defang new classes of attacks before real attackers even know
that they exist. Because the security implications of new technologies haven’t been fully explored in the wild, doing it in
house is sometimes the best way forward. This isn’t a penetration testing team finding new instances of known types of
weaknesses—it’s a research group that innovates new types of attacks. A science team could even include well-known
security researchers who publish their findings at conferences like DEF CON.

[AM3.2: 2] Create and use automation to mimic attackers.
The SSG arms testers with automation to mimic what attackers are going to do. For example, a new attack method
identified by the science team could require a new tool, so the SSG could package the tool and distribute it to testers.
The idea here is to push attack capability past what typical commercial tools and offerings encompass, and then make that
knowledge and technology easy for others to use. Tailoring these new tools to a firm’s particular technology stacks and
potential attackers increases the overall benefit. When technology stacks and coding languages evolve faster than vendors
can innovate, creating tools and automation in house might be the best way forward. In the DevOps world, these tools
might be created by engineering and embedded directly into toolchains and automation (e.g., Chaos Monkey).
[AM3.3: 0] Monitor automated asset creation.
The SSG implements technology controls that provide a continuously updated view of the various network, machine,
software, and related infrastructure assets being instantiated by engineering teams as part of their ALM processes. The
SSG works with the engineering teams to understand the custom automation and cloud provider dashboards engineering
uses to quickly stand-up servers, databases, networks, and entire clouds for software deployments. Monitoring the
changes in application design (e.g., moving a monolithic application to microservices) is also part of this effort. This
monitoring requires a specialized effort; normal system, network, and application logging and analysis won’t suffice.
Success might require a multi-pronged approach, including consuming orchestration and virtualization metadata,
querying cloud service provider APIs, and outside-in web crawling and scraping. As processes improve, the data will be
helpful for threat modeling efforts (see [AA1.1 Perform security feature review]).
INTELLIGENCE: SECURITY FEATURES & DESIGN (SFD)

The Security Features & Design practice is charged with creating usable security patterns for major security controls
(meeting the standards defined in the Standards & Requirements practice), building middleware frameworks for those
controls, and creating and publishing proactive security guidance.
SFD LEVEL 1
[SFD1.1: 98] Build and publish security features.
Rather than having each project team implement its own security features (e.g., authentication, role management, key
management, audit/log, cryptography, protocols), the SSG provides proactive guidance by acting as a clearinghouse of
security features for development groups to use. These features might be discovered during code review, created by the
SSG or a specialized development team, or be part of a library provided by a vendor, such as a cloud service provider.
Generic security features often have to be tailored for specific platforms. A mobile crypto feature will likely need at least
two versions to cover Android and iOS, while managing identity in the cloud might require versions specific to AWS,
Google, and Azure. Project teams benefit from implementations that come preapproved by the SSG, and the SSG
benefits by not having to repeatedly track down the kinds of subtle errors that often creep into security features.
[SFD1.2: 69] Engage the SSG with architecture teams.
Security is a regular topic in the organization’s software architecture discussions, with the architecture team taking
responsibility for security in the same way that it takes responsibility for performance, availability, and scalability.
One way to keep security from falling out of these discussions is to have an SSG member participate in architecture
discussions. In other cases, enterprise architecture teams can help the SSG create secure designs that integrate properly
into corporate design standards. Proactive engagement by the SSG is key to success here. Moving a well-known system
to the cloud means reengaging the SSG, for example. It’s never safe for one team to assume another team has addressed
security requirements.

SFD LEVEL 2
[SFD2.1: 31] Leverage secure-by-design middleware frameworks and common libraries.
The SSG takes a proactive role in software design by building or providing pointers to secure-by-design middleware
frameworks or common libraries. In addition to teaching by example, this middleware aids architecture analysis and
code review because the building blocks make it easier to spot errors. For example, the SSG can modify a popular web
framework, such as Spring, to make it easy to meet input validation requirements. Eventually, the SSG can tailor code
review rules specifically for the components it offers (see [CR3.1 Use automated tools with tailored rules]). When
adopting a middleware framework (or any other widely used software), the SSG must carefully vet the software for
security before publication. Encouraging adoption and use of insecure middleware doesn’t help the overall software
security goal. Generic open source software security frameworks and libraries (e.g., Spring Security, NaCL), should not
be considered secure by design. Attempting to bolt security on at the end by calling a library is always an unsuccessful
approach to secure design.
[SFD2.2: 40] Create an SSG capability to solve difficult design problems.
The SSG contributes to new architecture and solves difficult design problems, minimizing the negative impact that
security has on other constraints (time to market, price, etc.). If a skilled security architect from the SSG is involved in
the design of a new protocol, he or she can analyze the security implications of existing protocols and identify elements
that should be duplicated or avoided. Likewise, having a security architect understand the security implications of moving
a seemingly well-understood application to the cloud saves a lot of headaches later. Designing for security up front is
more efficient than analyzing an existing design for security and refactoring when flaws are uncovered, so the SSG should
be involved early in the new project process. Note that some design problems will require specific expertise outside of the
SSG: even the best expert can’t scale to cover the needs of an entire software portfolio.
SFD LEVEL 3
[SFD3.1: 11] Form a review board or central committee to approve and maintain secure design patterns.
A review board or central committee formalizes the process of reaching consensus on design needs and security tradeoffs.
Unlike the architecture committee, this group focuses on providing security guidance and also periodically reviews already
published design standards (especially around authentication, authorization, and cryptography) to ensure that design
decisions don’t become stale or out of date. Moreover, a review board can help control the chaos often associated with
the adoption of new technologies when development groups might otherwise make decisions on their own without ever
engaging the SSG.
[SFD3.2: 12] Require use of approved security features and frameworks.
Implementers take their security features and frameworks from an approved list or repository. There are two benefits
to this activity: developers don’t spend time reinventing existing capabilities, and review teams don’t have to contend
with finding the same old defects in new projects or when new platforms are adopted. Essentially, the more a project
uses proven components, the easier testing, code review, and architecture analysis become (see [AA1.1 Perform security
feature review]). Reuse is a major advantage of consistent software architecture and is particularly helpful for agile
development and velocity maintenance in CI/CD pipelines. Container-based approaches make it especially easy to
package and reuse approved features and frameworks (see [SE3.4 Use application containers]).
[SFD3.3: 4] Find and publish mature design patterns from the organization.
The SSG fosters centralized design reuse by collecting design patterns (sometimes referred to as security blueprints)
from across the organization and publishing them for everyone to use. A section of the SSG website could promote
positive elements identified during architecture analysis so that good ideas are spread. This process is formalized: an
ad hoc, accidental noticing isn’t sufficient. In some cases, a central architecture or technology team can facilitate and
enhance this activity. Common design patterns accelerate development, so it’s important to use secure design patterns
not just for applications but for all software (microservices, APIs, frameworks, infrastructure, and automation).

INTELLIGENCE: STANDARDS & REQUIREMENTS (SR)
The Standards & Requirements practice involves eliciting explicit security requirements from the organization,
determining which COTS to recommend, building standards for major security controls (such as authentication, input
validation, and so on), creating security standards for technologies in use, and creating a standards review board.
SR LEVEL 1
[SR1.1: 83] Create security standards.
The SSG meets the organization’s demand for security guidance by creating standards that explain the accepted way
to adhere to policy and carry out specific security-centric operations. A standard might describe how to perform
authentication on an Android device or how to determine the authenticity of a software update, with the SSG providing
a reference implementation. Often, software that isn’t an application requires its own standard (e.g., an API or a
microservices architecture). Standards can be deployed in a variety of ways to keep them actionable and relevant. They
can be automated into development environments (e.g., worked into an IDE or toolchain), or they can be explicitly linked
to code examples or even to containers. In any case, to be considered standards, they must be adopted and enforced.
[SR1.2: 81] Create a security portal.
The organization has a well-known central location for information about software security. Typically, this is an internal
website maintained by the SSG that people refer to for the latest and greatest on security standards and requirements,
as well as for other resources provided by the SSG (e.g., training). An interactive wiki is better than a static portal with
guideline documents that rarely change. Organizations can supplement these materials with mailing lists and face-to-
face meetings. Development teams are increasingly putting software security knowledge directly into toolchains and
automation that is be outside the organization (e.g., GitHub), but that does not remove the need for SSG-led
knowledge management.
[SR1.3: 85] Translate compliance constraints to requirements.
Compliance constraints are translated into software requirements for individual projects. This is a linchpin in the
organization’s compliance strategy: by representing compliance constraints explicitly with requirements, the organization
demonstrates that compliance is a manageable task. For example, if the organization routinely builds software that
processes credit card transactions, PCI DSS compliance plays a role in the SSDL during the requirements phase. In other
cases, technology standards built for international interoperability can include security guidance on compliance needs.
Representing these standards as requirements also helps with traceability and visibility in the event of an audit.
It’s particularly useful to codify the requirements into reusable code or container specifications.
SR LEVEL 2
[SR2.2: 52] Create a standards review board.
The organization creates a review board to formalize the process used to develop standards and to ensure that all
stakeholders have a chance to weigh in. This standards review board could operate by appointing a champion for any
proposed standard, putting the onus on the champion to demonstrate that the standard meets its goals and to get
approval and buy-in from the review board. Enterprise architecture or enterprise risk groups sometimes take on the
responsibility of creating and managing standards review boards. When the standards are implemented directly as
software, the responsible champion might be a DevOps manager, release engineer, or whomever owns the associated
container or service registry.
[SR2.4: 46] Identify open source.
Open source components included in the software portfolio are identified and reviewed to really understand their
dependencies. It’s not uncommon to discover old versions of components with known vulnerabilities or multiple
versions of the same component. Automated tools for finding open source, whether whole components or large chunks
of borrowed code, are one way to approach this activity. An informal annual review or a process that relies solely on
developers asking for permission does not generate satisfactory results.

[SR2.5: 35] Create SLA boilerplate.
The SSG works with the legal department to create standard SLA boilerplate for use in contracts with vendors and
outsource providers (including cloud providers) to require software security efforts. The legal department understands
that the boilerplate also helps prevent compliance and privacy problems. Under the agreement, vendors and outsource
providers must meet company-mandated software security standards (see [CP2.4 Include software security SLAs in all
vendor contracts]). Boilerplate language might call for objective third-party insight into software security efforts, such as
BSIMMsc measurements or BSIMM scores.
SR LEVEL 3
[SR3.1: 22] Control open source risk.
The organization has control over its exposure to the vulnerabilities that come along with using open source components
and all the involved dependencies. The use of open source could be restricted to predefined projects or to a short-list of
open source versions that have been through an SSG security screening process, have had unacceptable vulnerabilities
remediated, and are made available only through specific internal repositories and containers. In some cases, policy might
preclude any use of open source. The legal department often spearheads additional open source controls due to the “viral”
license problem associated with GPL code. In general, getting the legal department to understand security risks can help
move an organization to improve its open source risk management practices, which must be applied across the software
portfolio to be effective.
[SR3.2: 11] Communicate standards to vendors.
The SSG works with vendors to educate them and promote the organization’s security standards. However, a healthy
relationship with a vendor isn’t guaranteed through contract language alone, so the SSG should engage with vendors,
discuss vendor security practices, and explain in concrete terms (rather than legalese) what the organization expects of
its vendors. Any time a vendor adopts the organization’s security standards, it’s a clear sign of progress. When the firm’s
SSDL is publicly available, communication regarding software security expectations is easier. Likewise, sharing internal
practices and measures can make expectations clear.
[SR3.3: 9] Use secure coding standards.
Secure coding standards help the organization’s developers avoid the most obvious bugs and provide ground rules for
code review. These standards are necessarily specific to a programming language or platform, and they can address the
use of popular frameworks and libraries. Platforms might include mobile or IoT runtimes, cloud service provider APIs, and
SaaS platforms (e.g., Salesforce, SAP). If the organization already has coding standards for other purposes, its secure
coding standards should build upon them. A clear set of secure coding standards is a good way to guide both manual
and automated code review, as well as to provide relevant examples for security training. Some groups might choose to
integrate their secure coding standards directly into automation, but violation of the standards must still be considered a
defect to be fixed. Remember, if the secure coding standards are not specific and enforced, they won’t be effective.
[SR3.4: 24] Create standards for technology stacks.
The organization standardizes on specific technology stacks. For the SSG, this means a reduced workload because the
group doesn’t have to explore new technology risks for every new project. Ideally, the organization will create a secure
base configuration for each technology stack, further reducing the amount of work required to use the stack safely. A
stack might include an operating system, a database, an application server, and a runtime environment (e.g., a LAMP
stack). In other cases, the stack might be an application server and development framework bundle (e.g., MEAN) or
even layers 1 through 6 in a cloud environment (e.g., functions-as-a-service). The security frontier is a good place to find
traction; mobile technology stacks and platforms, IoT devices, and cloud-based technology stacks are areas where specific
attention to security particularly pays off. Container-based approaches can make standardization more scalable (see
[SE3.4 Use application containers]).

SSDL TOUCHPOINTS: ARCHITECTURE ANALYSIS (AA)
Architecture Analysis encompasses capturing software architecture in concise diagrams, applying lists of risks and
threats, adopting a process for review (such as STRIDE or Architecture Risk Analysis), and building an assessment and
remediation plan for the organization.
AA LEVEL 1
[AA1.1: 103] Perform security feature review.
To get started in architecture analysis, center the process on a review of security features. Security-aware reviewers
identify the security features in an application (authentication, access control, use of cryptography, etc.) and then inspect
the design for problems that would cause these features to fail at their purpose or otherwise prove insufficient. For
example, this kind of review would identify both a system that was subject to escalation of privilege attacks because of
broken access control as well as a mobile application that stashed away PII in local storage. In some cases, use of the firm’s
secure-by-design components can streamline this process. Be aware that cloud service provider APIs and the services
behind them are often integral to the way certain security features work.
[AA1.2: 29] Perform design review for high-risk applications.
The organization learns the benefits of AA by seeing real results for a few high-risk, high-profile applications. Reviewers
must have some experience performing detailed design reviews and breaking the architecture under consideration,
especially for new platforms or environments. In all cases, a design review should produce a set of architecture flaws and
a plan to mitigate them. If the SSG isn’t yet equipped to perform an in-depth AA, it can use consultants to do this work,
but it should participate actively. Ad hoc review paradigms that rely heavily on expertise can be used here, but they don’t
tend to scale in the long run. A review focused only on whether a software project has performed the right process steps
won’t generate useful results about architecture flaws. Note that a sufficiently robust design review process can’t be
executed at CI/CD speed.
[AA1.3: 23] Have SSG lead design review efforts.
The SSG takes a lead role in AA by performing a design review to uncover flaws. Breaking down an architecture is
enough of an art that the SSG must be proficient at it before it can turn the job over to architects, and proficiency
requires practice. The SSG can’t be successful on its own, either; it will likely need help from architects or implementers
to understand the design. With a clear design in hand, the SSG might be able to carry out the detailed review with a
minimum of interaction with the project team. Over time, the responsibility for leading review efforts should shift toward
software security architects. Approaches to AA, including threat modeling, evolve over time, so it’s wise to not expect to
set a process and use it forever.
[AA1.4: 62] Use a risk questionnaire to rank applications.
To facilitate security feature and design review processes, the SSG uses a risk questionnaire or similar method—whether
manual or automated—to collect information about each application in order to assign a risk classification and associated
prioritization. Information needed for an assignment might include, “Which programming languages is the application
written in?” or “Who uses the application?” or “Is the application deployed in a container?” Typically, a qualified member
of the application team provides the information, where the process should be short enough to take only a few minutes.
Some teams might use automation to gather the necessary data. The SSG can use the answers to categorize the application
as high, medium, or low risk. Because a risk questionnaire can be easy to game, it’s important to put into place some spot-
checking for validity and accuracy. An overreliance on self-reporting or automation can render this activity useless.
AA LEVEL 2
[AA2.1: 18] Define and use AA process.
The SSG defines and documents a process for AA and applies it in the design reviews it conducts to find flaws. This
process includes a standardized approach for thinking about attacks, security properties, and the associated risk, and it
is defined well enough that people outside the SSG can learn to carry it out. Pay particular attention to documenting
both the architecture under review and any security flaws uncovered, as well as risk information people can understand.
Individual ad hoc approaches to AA don’t count as a defined process. Microsoft’s STRIDE and Synopsys’s ARA are
examples of such a process, although even these two methodologies for AA have evolved greatly over time.

[AA2.2: 14] Standardize architectural descriptions.
Defined AA processes use an agreed-upon format to describe architecture, including a means for representing data
flow. Combining a documented process along with standardized architecture descriptions will make AA tractable for
people who aren’t security experts. In the case of cloud applications, data are likely to flow across the Internet, so a
network diagram is useful in this case, but the description should go into detail about how the software itself is structured.
A standard architecture description can be enhanced to provide an explicit picture of information assets that require
protection. Standardized icons that are consistently used in diagrams, templates, and whiteboard squiggles are especially
useful, too.
AA LEVEL 3
[AA3.1: 7] Have engineering teams lead AA process.
Engineering teams lead the AA process most of the time. This effort requires a well-understood and well-documented
process (see [AA2.1 Define and use AA process]), although the SSG still might contribute to AA in an advisory capacity
or under special circumstances. Even with a good process, consistency is difficult to attain because breaking architecture
requires experience, so provide architects with SSG or outside expertise on novel issues.
[AA3.2: 1] Drive analysis results into standard architecture patterns.
Failures identified during AA are fed back to a security design committee so that similar mistakes can be prevented in
the future through improved design patterns (see [SFD3.1 Form a review board or central committee to approve and
maintain secure design patterns]). Security design patterns can interact in surprising ways that break security, so the AA
process should be applied even when vetted design patterns are in standard use.
[AA3.3: 4] Make the SSG available as an AA resource or mentor.
To build an AA capability outside of the SSG, the SSG advertises itself as a resource or mentor for teams that ask for
help in using the AA process (see [AA2.1 Define and use AA process]) to conduct their own design review. The SSG
can answer AA questions during office hours and, in some cases, might assign someone to sit with the architect for the
duration of the analysis. In the case of high-risk software, the SSG should play a more active mentorship role in applying
the AA process.
SSDL TOUCHPOINTS: CODE REVIEW (CR)

The Code Review practice includes use of code review tools, development of tailored rules, customized profiles for tool
use by different roles (for example, developers versus auditors), manual analysis, and tracking/measuring results.
CR LEVEL 1
[CR1.2: 80] Have the SSG perform ad hoc review.
The SSG performs an ad hoc code review for high-risk applications in an opportunistic fashion, such as by following up
a design review with a code review looking for security issues. This informal targeting often evolves into a systematic
approach. SSG review could involve the use of specific tools and services, or it might be manual, but it has to be part of a
proactive process. When new technologies pop up, new approaches to code review might become necessary.
[CR1.4: 85] Use automated tools along with manual review.
Incorporate static analysis into the code review process to make the review more efficient and consistent. Automation
won’t replace human judgment, but it does bring definition to the review process and security expertise to reviewers
who typically aren’t security experts. Note that a specific tool might not cover an entire portfolio, especially when new
languages are involved, but that’s no excuse not to review the code. A firm might use an external service vendor as part
of a formal code review process for software security, but this service should be explicitly connected to a larger SSDL
defect management process applied during software development, not just used to “check the security box” on the path
to deployment.

[CR1.5: 44] Make code review mandatory for all projects.
Code review is mandatory for all projects under the SSG’s purview, with a lack of code review or unacceptable results
stopping a release, slowing it down, or causing it to be recalled. While all projects must undergo code review, the process
might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation,
for example, whereas high-risk projects might have no upper bound on the amount of time spent by reviewers. Having a
minimum acceptable standard forces projects that don’t pass to be fixed and reevaluated. A code review tool with nearly
all the rules turned off (so it can run at CI/CD automation speeds, for example) won’t provide sufficient defect coverage.
Similarly, peer code review focused on quality and style won’t provide useful security results.
[CR1.6: 44] Use centralized reporting to close the knowledge loop and drive training.
The bugs found during code review are tracked in a centralized repository that makes it possible to do both summary
and trend reporting for the organization. The code review information can be incorporated into a CISO-level dashboard
that might include feeds from other parts of the security organization (e.g., penetration tests, security testing, black-box
testing, and white-box testing). Given the historical code review data, the SSG can also use the reports to demonstrate
progress and drive the training curriculum (see [SM2.5 Identify metrics and use them to drive budgets]). Individual bugs
make excellent training examples.
CR LEVEL 2
[CR2.5: 39] Assign tool mentors.
Mentors are available to show developers how to get the most out of code review tools. If the SSG has the most skill with
the tools, it could use office hours or other outreach to help developers establish the right configuration or get started on
interpreting results. Alternatively, someone from the SSG might work with a development team for the duration of the
first review they perform. Centralized use of a tool can be distributed into the development organization or toolchains
over time through the use of tool mentors, but providing installation instructions and URLs to centralized tools isn’t the
same as mentoring. In many organizations, satellite members take on the tool mentorship role.
[CR2.6: 21] Use automated tools with tailored rules.
Customize static analysis to improve efficiency and reduce false positives. Adding custom rules can help uncover security
defects specific to the organization’s coding standards or the framework-based or cloud-provided middleware it uses. The
same group that provides tool mentoring will likely spearhead the customization. Tailored rules can be explicitly tied to
proper usage of technology stacks in a positive sense and avoidance of errors commonly encountered in a firm’s code base
in a negative sense. To reduce the workload for everyone, many organizations also create rules to remove repeated false
positives and turn off checks that aren’t relevant.
[CR2.7: 23] Use a top N bugs list (real data preferred).
The SSG maintains a living list of the most important kinds of bugs that it wants to eliminate from the organization’s
code and uses it to drive change. Many organizations start with a generic list pulled from public sources but lists such
as the OWASP Top 10 rarely reflect an organization’s bug priorities. The list’s value comes from being specific to
the organization, built from real data gathered from code review, testing, software composition analysis, and actual
incidents, and prioritized for prevention efforts. Simply sorting the day’s bug data by number of occurrences won’t
produce a satisfactory list because these data change so often. To increase interest, the SSG can periodically publish a
“most wanted” report after updating the list. One potential pitfall with a top N list is that it tends to only include known
problems. Of course, just building the list won’t accomplish anything; everyone has to actually use it to kill bugs.
CR LEVEL 3
[CR3.2: 7] Build a capability to combine assessment results.
Combine assessment results so that multiple analysis techniques feed into one reporting and remediation process. Analysis
techniques might include static analysis, dynamic analysis, software composition analysis, container scanning, and so on.
The SSG might write scripts to gather data automatically and combine the results into a format that can be consumed by
a single downstream review and reporting solution. The tricky part of this activity is normalizing vulnerability information
from disparate sources that use conflicting terminology. In some cases, using a standardized taxonomy (e.g., a CWE-like
approach) can help with normalization. Combining multiple sources helps drive better-informed risk mitigation decisions.

[CR3.3: 1] Eradicate specific bugs from the entire codebase.
When a new kind of bug is found, the SSG writes rules to find it and uses these rules to identify all occurrences of the
new bug throughout the entire codebase. It’s possible to eradicate the bug type entirely without waiting for every project
to reach the code review portion of its lifecycle. A firm with only a handful of software applications will have an easier
time with this activity than firms with a large number of large applications.
[CR3.4: 4] Automate malicious code detection.
Automated code review is used to identify dangerous code written by malicious in-house developers or outsource providers.
Examples of malicious code that could be targeted include backdoors, logic bombs, time bombs, nefarious communication
channels, obfuscated program logic, and dynamic code injection. Although out-of-the-box automation might identify some
generic malicious-looking constructs, custom rules for the static analysis tools used to codify acceptable and unacceptable
code patterns in the organization’s codebase will quickly become a necessity. Manual code review for malicious code is a good
start but insufficient to complete this activity at scale. While not all backdoors or similar code were meant to be malicious
when they were written (e.g., a developer’s feature to bypass authentication during testing), such things have a tendency to
stay in deployed code and should be treated as malicious code until proven otherwise.
[CR3.5: 2] Enforce coding standards.
The enforced portions of an organization’s secure coding standards often start out as a simple list of banned functions,
with a violation of these standards being sufficient grounds for rejecting a piece of code. Other useful coding standard
topics might include proper use of cloud APIs, use of approved cryptography, memory sanitization, and many others.
Code review against standards must be objective: it shouldn’t devolve into a debate about whether the noncompliant
code is exploitable. In some cases, coding standards for developers are published specific to technology stacks and then
enforced during the code review process or directly in the IDE. Standards can be positive (“do it this way”) or negative
(“do not use this API”), but they must be enforced to be useful.
SSDL TOUCHPOINTS: SECURITY TESTING (ST)

The Security Testing practice is concerned with prerelease testing, including integrating security into standard QA
processes. The practice includes the use of black-box security tools (including fuzz testing) as a smoke test in QA,
risk-driven white-box testing, application of the attack model, and code coverage analysis. Security testing focuses on
vulnerabilities in construction.
ST LEVEL 1
[ST1.1: 100] Ensure QA supports edge/boundary value condition testing.
QA efforts go beyond functional testing to perform basic adversarial tests and probe simple edge cases and boundary
conditions, with no particular attacker skills required. When QA understands the value of pushing past standard
functional testing that uses expected input, it begins to move slowly toward thinking like an adversary. A discussion
of boundary value testing can lead naturally to the notion of an attacker probing the edges on purpose (for example,
determining what happens when someone enters the wrong password over and over).
[ST1.3: 87] Drive tests with security requirements and security features.
QA targets declarative security mechanisms with tests derived from requirements and security features. A test could try
to access administrative functionality as an unprivileged user, for example, or verify that a user account becomes locked
after some number of failed authentication attempts. For the most part, security features can be tested in a fashion
similar to other software features; security mechanisms based on requirements such as account lockout, transaction
limitations, entitlements, and so on are tested with both expected and unexpected input. Software security isn’t security
software, but testing security features is an easy way to get started. New software architectures and deployment models,
such as with cloud, might require novel test approaches.

ST LEVEL 2
[ST2.1: 32] Integrate black-box security tools into the QA process.
The organization uses one or more black-box security testing tools as part of the QA process. Such tools are valuable
because they encapsulate an attacker’s perspective, albeit generically; tools such as IBM Security AppScan or Fortify
WebInspect are relevant for web applications, while Prowler is relevant for AWS deployments. In some situations, other
groups might collaborate with the SSG to apply the tools. For example, a testing team could run the tool but come to the
SSG for help interpreting the results. Because of the way testing is integrated into agile development approaches, black-
box tools might be hooked into toolchains or be used directly by engineering. Regardless of who runs the black-box tool,
the testing should be properly integrated into the QA cycle of the SSDL.
[ST2.4: 15] Share security results with QA.
The SSG or others with security testing data routinely share results from security reviews with those responsible for
testing. Using testing results as the basis for a conversation about common attack patterns or the underlying causes of
code vulnerabilities allows QA to generalize that information into new test approaches. CI/CD makes this easier because
of the way testing is integrated into the cross-functional team. Over time, QA learns the security mindset, and the
organization benefits from an improved ability to create security tests tailored to the organization’s code.
[ST2.5: 9] Include security tests in QA automation.
Security tests are included in an automation framework and run alongside other QA tests. While many groups trigger
these tests manually, in a modern toolchain, these tests are likely part of the pipeline and triggered through automation.
Security tests might be derived from abuse cases identified earlier in the lifecycle, from creative tweaks of functional
tests, developer tests, and security feature tests, or even from guidance provided by penetration testers on how to
reproduce an issue.
[ST2.6: 9] Perform fuzz testing customized to application APIs.
QA efforts include running a customized fuzzing framework against APIs critical to the organization. They could begin from
scratch or use an existing fuzzing toolkit, but the necessary customization often goes beyond creating custom protocol
descriptions or file format templates to giving the fuzzing framework a built-in understanding of the application interfaces it
calls into. Test harnesses developed explicitly for particular applications make good places to integrate fuzz testing.
ST LEVEL 3
[ST3.3: 2] Drive tests with risk analysis results.
Testers use architecture analysis results (see [AA 2.1 Define and use AA process]) to direct their work. If the AA
determines that “the security of the system hinges on the transactions being atomic and not being interrupted partway
through,” for example, then torn transactions will become a primary target in adversarial testing. Adversarial tests like
these can be developed according to risk profile, with high-risk flaws at the top of the list.
[ST3.4: 1] Leverage coverage analysis.
Testers measure the code coverage of their security tests (see [ST2.5 Include security tests in QA automation]) to
identify code that isn’t being exercised. In turn, code coverage analysis drives increased security testing depth. Standard-
issue black-box testing tools achieve exceptionally low coverage, leaving a majority of the software under test unexplored,
which isn’t a testing best practice. Coverage analysis is easier when using standard measurements such as function
coverage, line coverage, or multiple condition coverage.
[ST3.5: 2] Begin to build and apply adversarial security tests (abuse cases).
Testing begins to incorporate test cases based on abuse cases (see [AM2.1 Build attack patterns and abuse cases tied to
potential attackers]) as testers move beyond verifying functionality and take on the attacker’s perspective. One way to do
this is to systematically attempt to replicate incidents from the organization’s history. Abuse and misuse cases based on
the attacker’s perspective can also be derived from security policies, attack intelligence, standards, and the organization’s
top N attacks list (see [AM2.5 Build and maintain a top N possible attacks list]). This effort turns the corner from testing
features to attempting to break the software under test.

DEPLOYMENT: PENETRATION TESTING (PT)
The Penetration Testing practice involves standard outside g in testing of the sort carried out by security specialists.
Penetration testing focuses on vulnerabilities in the final configuration and provides direct feeds to defect management
and mitigation.
PT LEVEL 1
[PT1.1: 109] Use external penetration testers to find problems.
Use external penetration testers to demonstrate that the organization’s code needs help. Breaking a high-profile
application to provide unmistakable evidence that the organization isn’t somehow immune to the problem often gets the
right attention. Over time, the focus of penetration testing moves from trying to determine if the code is broken in some
areas to a sanity check done before shipping. External penetration testers that bring a new set of experiences and skills to
the problem are the most useful.
[PT1.2: 94] Feed results to the defect management and mitigation system.
Penetration testing results are fed back to development through established defect management or mitigation channels,
with development responding via a defect management and release process. Emailing the results to various people
doesn’t generate useful results. Properly done, this exercise demonstrates the organization’s ability to improve the state
of security, and many firms are emphasizing the critical importance of not just identifying but actually fixing security
problems. One way to ensure attention is to add a security flag to the bug-tracking and defect management system. The
organization might leverage developer workflow or social tooling (e.g., Slack, JIRA) to communicate change requests, but
those requests are still tracked explicitly as part of a vulnerability management process.
[PT1.3: 82] Use penetration testing tools internally.
The organization creates an internal penetration testing capability that uses tools. This capability can be part of the SSG
or part of a specialized team elsewhere in the organization, with the tools improving the efficiency and repeatability of
the testing process. Tools used can include off-the-shelf products built specifically for application penetration testing,
network penetration tools that specifically understand the application layer, and custom scripts. Free-time or crisis-
driven efforts aren’t the same as an internal capability.
PT LEVEL 2
[PT2.2: 25] Penetration testers use all available information.
Penetration testers, whether internal or external, use source code, design documents, architecture analysis results,
misuse and abuse cases, and code review results to do deeper analysis and find more interesting problems. To effectively
do their job, penetration testers often need everything created throughout the SSDL, so an SSDL that creates no useful
artifacts about the code will make this effort harder. Having access to the artifacts is not the same as using them.
[PT2.3: 22] Schedule periodic penetration tests for application coverage.
The SSG periodically tests all applications in its purview according to an established schedule, which could be tied to a
calendar or a release cycle. High-profile applications should get a penetration test at least once a year. This testing serves
as a sanity check and helps ensure that yesterday’s software isn’t vulnerable to today’s attacks; it can also help maintain
the security of software configurations and environments, especially containers and components in the cloud. One
important aspect of periodic testing is to make sure that the problems identified are actually fixed and don’t creep back
into the build. New automation created for CI/CD deserves penetration testing as well.
PT LEVEL 3
[PT3.1: 11] Use external penetration testers to perform deep-dive analysis.
The organization uses external penetration testers to do deep-dive analysis for critical projects and to introduce fresh
thinking into the SSG. These testers should be experts and specialists who keep the organization up to speed with the
latest version of the attacker’s perspective and have a track record for breaking the type of software being tested. Skilled
penetration testers will always break a system, but the question is whether they demonstrate new kinds of thinking about
attacks that can be useful when designing, implementing, and hardening new systems. Creating new types of attacks
from threat intelligence and abuse cases prevents checklist-driven approaches that only look for known types of
problems, which is essential when it comes to new technologies.
[PT3.2: 5] Have the SSG customize penetration testing tools and scripts.
The SSG either creates penetration testing tools or adapts publicly available ones to more efficiently and
comprehensively attack the organization’s software. Tools will improve the efficiency of the penetration testing process
without sacrificing the depth of problems that the SSG can identify. Automation can be particularly valuable in
organizations using agile methodologies because it helps teams go faster. Tools that can be tailored are always preferable
to generic tools. Success here is often dependent upon both the depth of tests and their scope.
DEPLOYMENT: SOFTWARE ENVIRONMENT (SE)

The Software Environment practice deals with OS and platform patching (including in the cloud), web application
firewalls, installation and configuration documentation, containerization, orchestration, application monitoring, change
management, and code signing.
SE LEVEL 1
[SE1.1: 66] Use application input monitoring.
The organization monitors the input to the software that it runs in order to spot attacks. For web code, a web application
firewall (WAF) can do this job, while other kinds of software likely require other approaches. The SSG might be
responsible for the care and feeding of the monitoring system, but incident response isn’t part of this activity. For web
applications, WAFs that write log files can be useful if someone periodically reviews the logs and takes action. Other
software and technology stacks, such as mobile and IoT, likely require their own input monitoring solutions. Serverless
and containerized software can require interaction with vendor software to get the appropriate logs and monitoring data.
Cloud deployments and platform-as-a-service usage can add another level of difficulty to the monitoring, collection, and
aggregation approach.
[SE1.2: 111] Ensure host and network security basics are in place.
The organization provides a solid foundation for its software by ensuring that host and network security basics are in place
across its data centers and networks. Evolving network perimeters, increased connectivity and data sharing, and increasing
interdependence on vendors (e.g., content delivery, load balancing, and content inspection services) add a degree of
difficulty even to getting the basics right. Doing software security before getting host and network security in place is like
putting on shoes before putting on socks.
SE LEVEL 2
[SE2.2: 36] Publish installation guides.
The SSDL requires the creation of an installation guide or a clearly described configuration (such as for a container)
to help deployment teams and operators install and configure software securely. If special steps are required to ensure
a deployment is secure, these steps can either be outlined in the guide or explicitly noted in deployment automation;
the guide should include a discussion of COTS and vendor components as well. In some cases, installation guides are
distributed to customers who buy the software. All deployment automation should be understandable by humans, not
just machines. Increasingly, this means infrastructure scripting (e.g., Terraform, Helm, Ansible, and Chef) becomes the
installation guide.
[SE2.4: 27] Use code signing.
The organization uses code signing for software published across trust boundaries, which is particularly useful for
protecting the integrity of software that leaves the organization’s control, such as shrink-wrapped applications or thick
clients. In cloud environments, leveraging code signing might be important when packaging and distributing mobile
applications, containers, and machine images through vendor registries or in-house hosted registries. The fact that some
mobile platforms require the application code itself to be signed doesn’t indicate institutional use of code signing.

SE LEVEL 3
[SE3.2: 13] Use code protection.
To protect intellectual property and make exploit development harder, the organization erects barriers to reverse
engineering its software (e.g., anti-tamper, debug protection, anti-piracy features, runtime integrity). This is particularly
important for widely distributed mobile applications. For some software, obfuscation techniques could be applied as part
of the production build and release process. In other cases, these protections could be applied at the software-defined
network or software orchestration layer when applications are being dynamically regenerated post-deployment. On
some platforms, employing Data Execution Prevention (DEP), Safe Structured Handling (SafeSEH), and Address Space
Layout Randomization (ASLR) can be a good start at making exploit development more difficult.
[SE3.3: 4] Use application behavior monitoring and diagnostics.
The organization monitors production software to look for misbehavior or signs of attack. This activity goes beyond host
and network monitoring to look for software-specific problems, such as indications of malicious behavior. Intrusion
detection and anomaly detection systems at the application level might focus on an application’s interaction with
the operating system (through system calls) or with the kinds of data that an application consumes, originates, and
manipulates. In any case, the signs that an application isn’t behaving as expected will be specific to the software and its
environment, so one-size-fits-all solutions probably won’t generate satisfactory results. In some types of environments
(e.g., PaaS), some of this data and the associated predictive analytics might come from a vendor.
[SE3.4: 14] Use application containers.
The organization uses application containers to support its software security goals, which likely include ease of
deployment, a tighter coupling of applications with their dependencies, immutability, integrity (see [SE2.4 Use code
signing]), and some isolation benefits without the overhead of deploying a full OS on a virtual machine. Containers
provide a convenient place for security controls to be applied and updated consistently. While containers can be useful in
development and test environments, production use provides the real benefit.
[SE3.5: 5] Use orchestration for containers and virtualized environments.
The organization uses automation to scale service, container, and virtual machine deployments in a disciplined way.
Orchestration processes take advantage of built-in and add-on security controls to ensure each deployed workload meets
predetermined security requirements. Setting security behaviors in aggregate allows for rapid change when the need
arises. Orchestration platforms are themselves software that become part of your production environment, which in turn
requires security patching and configuration; in other words, if you use Kubernetes, make sure you patch Kubernetes.
[SE3.6: 3] Enhance application inventory with operations bill of materials.
A list of applications and their locations in production environments is essential information for any well-run enterprise
(see [CMVM2.3 Develop an operations inventory of applications]). In addition, a manifest detailing the components,
dependencies, configurations, external services, and so on for all production software helps the organization to tighten its
security posture, that is, to react with agility as attackers and attacks evolve, compliance requirements change, and the
number of items to patch grows quite large. Knowing where all the components live in running software—whether they’re
in private data centers, in clouds, or sold as box products—allows for timely response when unfortunate events occur.
Done properly, institutional use of container security solutions can make inventory efforts much simpler.
[SE3.7: 9] Ensure cloud security basics.
Organizations should already be ensuring that their host and network security basics are in place, but they must also ensure
that basic requirements are met in cloud environments. Of course, cloud-based virtual assets often have public-facing
services that create an attack surface (e.g., cloud-based storage) that is different from the one in a private data center, so
these assets require customized security configuration and administration. In the increasingly software-defined world, the
SSG has to help everyone explicitly implement cloud-based security features and controls (some of which can be built in, for
example, to cloud provider administration consoles) that are comparable to those built with cables and physical hardware in
private data centers. Detailed knowledge about cloud provider shared responsibility security models is always necessary.

DEPLOYMENT: CONFIGURATION MANAGEMENT &
VULNERABILITY MANAGEMENT (CMVM)
The Configuration Management & Vulnerability Management practice concerns itself with patching and updating
applications, version control, defect tracking and remediation, and incident handling.
CMVM LEVEL 1
[CMVM1.1: 103] Create or interface with incident response.
The SSG is prepared to respond to an event or alert, and is regularly included in the incident response process, either by
creating its own incident response capability or by regularly interfacing with the organization’s existing team. A regular
meeting between the SSG and the incident response team can keep information flowing in both directions. Having pre-
built communication channels with critical vendors (e.g., infrastructure, SaaS) is also very important.
[CMVM1.2: 101] Identify software defects found in operations monitoring and feed them back to development.
Defects identified through operations monitoring are fed back to development and used to change developer behavior.
In some cases, the contents of production logs can be revealing (or can reveal the need for improved logging). Offering a
way to enter incident triage data into an existing bug-tracking system (perhaps by making use of a special security flag)
seems to solve some problems, but the idea is to close the information loop and make sure that security issues get fixed.
In the best of cases, processes in the SSDL can be improved based on operational data.
CMVM LEVEL 2
[CMVM2.1: 91] Have emergency codebase response.
The organization can make quick code changes when an application is under attack, with a rapid-response team working
in conjunction with application owners and the SSG to study the code and the attack, find a resolution, and fix the
production code (e.g., push a patch into production, rollback to a known-good version, deploy a new container). Often,
the emergency response team is the engineering team itself. A well-defined process is a must here, but a process that has
never been used might not actually work.
[CMVM2.2: 88] Track software bugs found in operations through the fix process.
Defects found in operations are fed back to development, entered into established defect management systems, and tracked
through the fix process. This capability could come in the form of a two-way bridge between bug finders and bug fixers, but
make sure the loop is closed completely. Setting a security flag in the bug-tracking system can help facilitate tracking.
[CMVM2.3: 64] Develop an operations inventory of applications.
The organization has a map of its software deployments. If a piece of code needs to be changed, operations or DevOps
teams can reliably identify all the places where the change needs to be installed. Common components shared between
multiple projects can be noted so that, when an error occurs in one application, other applications that share the same
components can be fixed as well.
CMVM LEVEL 3
[CMVM3.1: 2] Fix all occurrences of software bugs found in operations.
The organization fixes all instances of each bug found during operations, not just the small number of instances that
trigger bug reports. This requires the ability to reexamine the entire codebase when new kinds of bugs come to light
(see [CR3.3 Eradicate specific bugs from the entire codebase]. One way to approach this is to create a rule set that
generalizes a deployed bug into something that can be scanned for via automated code review. Use of containers can
greatly simplify deploying the fix for all occurrences of a software bug.
[CMVM3.2: 9] Enhance the SSDL to prevent software bugs found in operations.
Experience from operations leads to changes in the SSDL, which can in turn be strengthened to prevent the
reintroduction of bugs found during operations. To make this process systematic, each incident response postmortem
could include a “feedback to SSDL” step. This works best when root-cause analysis pinpoints where in the SDLC an error
could have been introduced or slipped by uncaught. DevOps engineers might have an easier time with this because all the
players are likely involved in the discussion and the solution. An ad hoc approach to SSDL improvement isn’t sufficient.

[CMVM3.3: 12] Simulate software crises.
The SSG simulates high-impact software security crises to ensure software incident response capabilities minimize
damage. Simulations could test for the ability to identify and mitigate specific threats or, in other cases, begin with
the assumption that a critical system or service is already compromised and evaluate the organization’s ability to
respond. When simulations model successful attacks, an important question to consider is the time required to clean
up. Regardless, simulations must focus on security-relevant software failure and not on natural disasters or other types
of emergency response drills. Organizations that are highly dependent on vendor infrastructure (e.g., cloud service
providers, SaaS) and security features will naturally include those things in crisis simulations.
[CMVM3.4: 13] Operate a bug bounty program.
The organization solicits vulnerability reports from external researchers and pays a bounty for each verified and accepted
vulnerability received. Payouts typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g.,
remote code execution is worth $10,000 versus CSRF is worth $750), exploitability (demonstrable exploits command
much higher payouts), or specific service and software versions (widely deployed or critical services warrant higher
payouts). Ad hoc or short-duration activities, such as capture-the-flag contests or informal crowd-sourced efforts, don’t
constitute a bug bounty program.
[CMVM3.5: 0] Automate verification of operational infrastructure security.
The SSG works with engineering teams to facilitate a controlled self-service process that replaces some traditional
IT efforts, such as application and infrastructure deployment, and includes verification of security properties (e.g.,
adherence to agreed-upon security hardening). Engineers now create networks, containers, and machine instances,
orchestrate deployments, and perform other tasks that were once IT’s sole responsibility. In facilitating this change,
the organization uses machine-readable policies and configuration standards to automatically detect and report on
infrastructure that does not meet expectations. In some cases, the automation makes changes to running environments
to bring them into compliance. In many cases, organizations use a single policy to manage automation in different
environments, such as in multi-cloud and hybrid-cloud environments.

APPENDIX
In this appendix, we provide some history on the BSIMM project and how it serves as a longitudinal study of software
security efforts. We also describe the most recent changes to the BSIMM. To help understand how various vertical
markets approach their SSIs, we also provide a scorecard showing activity observation counts per vertical market. Finally,
we provide a list of the 119 BSIMM10 activities.
BUILDING A MODEL FOR SOFTWARE SECURITY

In the late 1990s, software security began to flourish as a discipline separate from computer and network security.
Researchers began to put more emphasis on studying the ways in which a programmer can contribute to or
unintentionally undermine the security of a computer system and started asking some specific questions: What kinds of
bugs and flaws lead to security problems? How can we identify problems systematically?
By the middle of the following decade, there was an emerging consensus that building secure software required more
than just smart individuals toiling away. Getting security right, especially across a software portfolio, means being involved
in the software development process, even as the process evolves.
Since then, practitioners have come to learn that process and developer tools alone are insufficient. Software security
encompasses business, social, and organizational aspects as well.
Table 3 shows how the BSIMM has grown over the years. (Recall that our data freshness constraints, introduced with
BSIMM-V and later tightened, cause data from firms with aging measurements to be removed from the dataset.)
BSIMM10 describes the work of 7,894 SSG and satellite people working directly in software security, impacting the
security efforts of 468,500 developers.

BSIMM NUMBERS OVER TIME
BSIMM10 BSIMM9 BSIMM8 BSIMM7 BSIMM6 BSIMM-V BSIMM4 BSIMM3 BSIMM2 BSIMM1
FIRMS 122 120 109 95 78 67 51 42 30 9
MEASUREMENTS 339 320 256 237 202 161 95 81 49 9
2ND MEASURES 50 42 36 30 26 21 13 11 0 0
3RD MEASURES 32 20 16 15 10 4 1 0 0 0
4TH MEASURES 8 7 5 2 2
SSG MEMBERS 1,596 1,600 1,268 1,111 1,084 976 978 786 635 370
SATELLITE
6,298 6,291 3,501 3,595 2,111 1,954 2,039 1,750 1,150 710
MEMBERS
DEVELOPERS 468,500 415,598 290,582 272,782 287,006 272,358 218,286 185,316 141,175 67,950
APPLICATIONS 173,233 135,881 94,802 87,244 69,750 69,039 58,739 41,157 28,243 3,970
AVG. SSG AGE
4.53 4.13 3.88 3.94 3.98 4.28 4.13 4.32 4.49 5.32
(YEARS)
SSG AVG.
1.37 / 100 1.33 / 100 1.60 / 100 1.61 / 100 1.51 / 100 1.4 / 100 1.95 / 100 1.99 / 100 1.02 / 100 1.13 / 100
OF AVGs
FINANCIAL
57 50 47 42 33 26 19 17 12 4
SERVICES
ISVs 43 42 38 30 27 25 19 15 7 4
TECH 20 22 16 14 17 14 13 10 7 2
HEALTHCARE 16 19 17 15 10
INTERNET
13 16 12 12 13
OF THINGS
CLOUD 20 17 16 15
INSURANCE 11 10 11 10
RETAIL 9 10
Table 3. BSIMM Numbers Over Time. The chart shows how the BSIMM has grown over the years.

THE BSIMM AS A LONGITUDINAL STUDY
Fifty of the 122 firms in BSIMM10 have been measured at least twice. On average, the time between first and second
measurements for those 50 firms was 29.4 months. Although individual activities among the 12 practices come and go
(as shown in the longitudinal scorecard below), in general, re-measurement over time shows a clear trend of increased
maturity. The raw score went up in 43 of the 50 firms and remained the same in three firms. Across all 50 firms, the
score increased by an average of 11.1 (42%). Simply put, SSIs mature over time.

BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM
ACTIVITY ROUND 1 ROUND 2 ACTIVITY ROUND 1 ROUND 2 ACTIVITY ROUND 1 ROUND 2 ACTIVITY ROUND 1 ROUND 2
(OF 50) (OF 50) (OF 50) (OF 50) (OF 50) (OF 50) (OF 50) (OF 50)
[SM1.1] 22 40 [AM1.2] 36 43 [AA1.1] 45 47 [PT1.1] 44 49

[SM1.2] 22 31 [AM1.3] 13 20 [AA1.2] 14 18 [PT1.2] 28 41
[SM1.3] 26 34 [AM1.5] 21 26 [AA1.3] 11 14 [PT1.3] 28 34
[SM1.4] 42 47 [AM2.1] 4 7 [AA1.4] 24 33 [PT2.2] 11 9
[SM2.1] 19 31 [AM2.2] 4 6 [AA2.1] 5 11 [PT2.3] 15 14
[SM2.2] 15 25 [AM2.5] 5 8 [AA2.2] 3 6 [PT3.1] 4 5
[SM2.3] 18 30 [AM2.6] 7 5 [AA3.1] 5 7 [PT3.2] 1 3
[SM2.6] 19 27 [AM2.7] 6 7 [AA3.2] 1 1
[SM3.1] 8 18 [AM3.1] 2 2 [AA3.3] 6 6
[SM3.2] 2 3 [AM3.2] 0 1
[SM3.3] 10 13 [AM3.3] 0 0
[SM3.4] 0 0
[CP1.1] 31 37 [SFD1.1] 38 42 [CR1.2] 27 35 [SE1.1] 23 28
[CP1.2] 42 45 [SFD1.2] 33 36 [CR1.4] 31 44 [SE1.2] 44 47
[CP1.3] 28 40 [SFD2.1] 11 19 [CR1.5] 16 23 [SE2.2] 19 20
[CP2.1] 15 25 [SFD2.2] 15 22 [CR1.6] 17 29 [SE2.4] 9 14
[CP2.2] 17 20 [SFD3.1] 4 8 [CR2.5] 10 24 [SE3.2] 4 4
[CP2.3] 18 22 [SFD3.2] 7 10 [CR2.6] 8 16 [SE3.3] 7 3
[CP2.4] 14 24 [SFD3.3] 3 3 [CR2.7] 11 14 [SE3.4] 1 3
[CP2.5] 22 28 [CR3.2] 2 4 [SE3.5] 0 1
[CP3.1] 8 18 [CR3.3] 1 3 [SE3.6] 0 2
[CP3.2] 11 12 [CR3.4] 0 0 [SE3.7] 0 2
[CP3.3] 1 4 [CR3.5] 3 3
[T1.1] 33 41 [SR1.1] 33 43 [ST1.1] 37 42 [CMVM1.1] 42 45
[T1.5] 9 22 [SR1.2] 30 41 [ST1.3] 39 40 [CMVM1.2] 48 45
[T1.7] 20 29 [SR1.3] 30 41 [ST2.1] 17 20 [CMVM2.1] 42 45
[T2.5] 6 15 [SR2.2] 15 29 [ST2.4] 4 8 [CMVM2.2] 35 43
[T2.6] 7 12 [SR2.4] 11 21 [ST2.5] 3 6 [CMVM2.3] 20 34
[T2.8] 10 9 [SR2.5] 11 21 [ST2.6] 6 4 [CMVM3.1] 2 0
[T3.1] 1 5 [SR3.1] 5 11 [ST3.3] 2 2 [CMVM3.2] 2 6
[T3.2] 2 9 [SR3.2] 8 9 [ST3.4] 0 0 [CMVM3.3] 3 3
[T3.3] 0 5 [SR3.3] 14 11 [ST3.5] 2 3 [CMVM3.4] 1 6
[T3.4] 1 11 [SR3.4] 14 17 [CMVM3.5] 0 0
[T3.5] 0 7
[T3.6] 3 3
Table 4. BSIMM10 Reassessments Scorecard Round 1 vs. Round 2. The chart shows how 50 SSIs changed between assessments.

As with earlier spider diagrams, Figure 8 shows the average high-water marks per practice for the 50 firms in their first
and second assessments. We see growth in nearly every practice, with Software Environment being the
possible exception.
VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
R1 FIRMS (50) R2 FIRMS (50)
Figure 8. Round 1 Firms vs. Round 2 Firms Spider Chart. This diagram illustrates the high-water mark change in 50 firms between their first
and second BSIMM assessments.
There are two obvious factors causing the numerical change seen on the longitudinal scorecard (showing 50
BSIMM10 firms moving from their first to second assessment). The first factor is newly observed activities. The
activities where we see the biggest increase in new observations include the following:
• [SM1.1 Publish process and evolve as necessary], with 19 new observations
• [CMVM2.3 Develop an operations inventory of applications], with 18 new observations
• [PT1.2 Feed results to the defect management and mitigation system], with 17 new observations
• [SM2.1 Publish data about software security internally], with 16 new observations
• [SM2.3 Create or grow a satellite], with 16 new observations
• [CP2.1 Identify PII inventory], with 16 new observations
• [SR2.2 Create a standards review board], with 16 new observations
• [CR2.5 Assign tool mentors], with 16 new observations

The changes observed from the first assessment to the second cannot always be seen directly on this scorecard.
For example, [SFD1.2 Engage the SSG with architecture teams] was a new activity for 11 firms, but the scorecard
shows that the observations increased by only three. That’s where the second factor comes in: although that
activity was newly observed in 11 firms, it was either no longer observed in eight firms or went away due to data
aging out, giving a total change of three (as shown in the scorecard). In a different example, the activity [SE2.2
Publish installation guides] was newly observed in nine firms and dropped out of the data pool or no longer
observed in eight firms. Therefore, the total observation count changed by only one on the scorecard.
Twenty-one of the 122 BSIMM10 firms have had a third measurement. Table 5 captures the ongoing growth that
occurs in these SSIs.

BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM BSIMM
ACTIVITY ROUND 1 ROUND 3 ACTIVITY ROUND 1 ROUND 3 ACTIVITY ROUND 1 ROUND 3 ACTIVITY ROUND 1 ROUND 3
[SM1.1] 10 19 [AM1.2] 15 20 [AA1.1] 17 19 [PT1.1] 19 19

[SM1.2] 10 16 [AM1.3] 5 14 [AA1.2] 8 10 [PT1.2] 12 20
[SM1.3] 10 15 [AM1.5] 12 13 [AA1.3] 7 9 [PT1.3] 12 15
[SM1.4] 17 20 [AM2.1] 4 6 [AA1.4] 12 15 [PT2.2] 5 5
[SM2.1] 6 13 [AM2.2] 2 7 [AA2.1] 2 5 [PT2.3] 10 6
[SM2.2] 5 14 [AM2.5] 2 5 [AA2.2] 0 4 [PT3.1] 1 3
[SM2.3] 10 11 [AM2.6] 3 3 [AA3.1] 3 2 [PT3.2] 1 3
[SM2.6] 11 11 [AM2.7] 3 5 [AA3.2] 0 0
[SM3.1] 4 8 [AM3.1] 0 2 [AA3.3] 4 3
[SM3.2] 0 4 [AM3.2] 0 3
[SM3.3] 5 5 [AM3.3] 0 0
[SM3.4] 0 0
[CP1.1] 14 21 [SFD1.1] 19 20 [CR1.2] 9 17 [SE1.1] 11 16
[CP1.2] 20 20 [SFD1.2] 13 18 [CR1.4] 11 20 [SE1.2] 18 21
[CP1.3] 14 19 [SFD2.1] 6 9 [CR1.5] 5 7 [SE2.2] 7 5
[CP2.1] 10 14 [SFD2.2] 4 15 [CR1.6] 7 13 [SE2.4] 4 9
[CP2.2] 9 11 [SFD3.1] 2 7 [CR2.5] 3 10 [SE3.2] 0 3
[CP2.3] 11 14 [SFD3.2] 3 6 [CR2.6] 3 7 [SE3.3] 5 1
[CP2.4] 5 10 [SFD3.3] 3 1 [CR2.7] 5 6 [SE3.4] 0 1
[CP2.5] 9 12 [CR3.2] 1 2 [SE3.5] 0 1
[CP3.1] 4 8 [CR3.3] 0 1 [SE3.6] 0 1
[CP3.2] 4 3 [CR3.4] 0 1 [SE3.7] 0 1
[CP3.3] 1 2 [CR3.5] 2 2
[T1.1] 15 20 [SR1.1] 16 19 [ST1.1] 13 20 [CMVM1.1] 17 21
[T1.5] 3 11 [SR1.2] 13 21 [ST1.3] 15 19 [CMVM1.2] 21 21
[T1.7] 10 14 [SR1.3] 14 20 [ST2.1] 7 10 [CMVM2.1] 20 20
[T2.5] 2 7 [SR2.2] 10 15 [ST2.4] 3 3 [CMVM2.2] 13 20
[T2.6] 3 9 [SR2.4] 4 10 [ST2.5] 1 1 [CMVM2.3] 12 19
[T2.8] 6 9 [SR2.5] 5 9 [ST2.6] 3 4 [CMVM3.1] 0 1
[T3.1] 0 2 [SR3.1] 1 6 [ST3.3] 1 1 [CMVM3.2] 1 3
[T3.2] 0 5 [SR3.2] 3 5 [ST3.4] 0 1 [CMVM3.3] 0 3
[T3.3] 0 4 [SR3.3] 7 5 [ST3.5] 2 1 [CMVM3.4] 0 4
[T3.4] 0 4 [SR3.4] 7 9 [CMVM3.5] 0 0
[T3.5] 0 2
[T3.6] 2 2
Table 5. BSIMM10 Reassessments Scorecard Round 1 vs. Round 3. The chart shows how 21 SSIs changed from their first to their
third assessment.

The figure below shows the average high-water marks per practice for the 21 firms in their first and third assessments.
Interestingly, while this chart shows growth in nearly every practice, it also shows a slight regression in the Architecture
Analysis practice.
VULNERABILITY 3.0
COMPLIANCE
MANAGEMENT & POLICY
2.5
2.0
SOFTWARE TRAINING
ENVIRONMENT 1.5
1.0
0.5
PENETRATION ATTACK
0.0
TESTING MODELS

TESTING & DESIGN
CODE STANDARDS &

REVIEW REQUIREMENTS
ARCHITECTURE
ANALYSIS
R1 FIRMS (21) R3 FIRMS (21)
Figure 9. Round 1 Firms vs. Round 3 Firms Spider Chart. This diagram illustrates the high-water mark change in 21 firms between their first
and third BSIMM assessments.

CHARTS, GRAPHS, AND SCORECARDS
In this section, we present the BSIMM skeleton showing the activities and their observation rates, along with other useful
or interesting charts.
The BSIMM skeleton provides a way to view the model at a glance and is useful when assessing an SSI. We showed you a
streamlined version of the skeleton in Part Two. Table 6 shows a more detailed version, with the number and percentages
of firms (out of 122) performing that activity in their own SSI.
GOVERNANCE
STRATEGY & METRICS (SM)

ACTIVITY DESCRIPTION ACTIVITY OBSERVATIONS PARTICIPANT %
LEVEL 1
Publish process and evolve as necessary. [SM1.1] 81 66.4%
Create evangelism role and perform internal marketing. [SM1.2] 66 54.1%
Educate executives. [SM1.3] 73 59.8%
Identify gate locations, gather necessary artifacts. [SM1.4] 107 87.7%
LEVEL 2
Publish data about software security internally. [SM2.1] 49 40.2%
Enforce gates with measurements and track exceptions. [SM2.2] 53 43.4%
Create or grow a satellite. [SM2.3] 52 42.6%
Require security sign-off. [SM2.6] 51 41.8%
LEVEL 3
Use an internal tracking application with portfolio view. [SM3.1] 21 17.2%
Run an external marketing program. [SM3.2] 6 4.9%
Identify metrics and use them to drive budgets. [SM3.3] 14 11.5%
Integrate software-defined lifecycle governance. [SM3.4] 0 0.0%
COMPLIANCE & POLICY (CP)

LEVEL 1
Unify regulatory pressures. [CP1.1] 81 66.4%
Identify PII obligations. [CP1.2] 105 86.1%
Create policy. [CP1.3] 76 62.3%
LEVEL 2
Identify PII inventory. [CP2.1] 48 39.3%
Require security sign-off for compliance-related risk. [CP2.2] 47 38.5%
Implement and track controls for compliance. [CP2.3] 51 41.8%
Include software security SLAs in all vendor contracts. [CP2.4] 44 36.1%
Ensure executive awareness of compliance and privacy obligations. [CP2.5] 56 45.9%
LEVEL 3
Create a regulator compliance story. [CP3.1] 25 20.5%
Impose policy on vendors. [CP3.2] 15 12.3%
Drive feedback from software lifecycle data back to policy. [CP3.3] 7 5.7%

TRAINING (T)
LEVEL 1
Conduct awareness training. [T1.1] 77 63.1%
Deliver role-specific advanced curriculum. [T1.5] 37 30.3%
Deliver on-demand individual training. [T1.7] 46 37.7%
LEVEL 2
Enhance satellite through training and events. [T2.5] 27 22.1%
Include security resources in onboarding. [T2.6] 28 23.0%
Create and use material specific to company history. [T2.8] 28 23.0%
LEVEL 3
Reward progression through curriculum. [T3.1] 3 2.5%
Provide training for vendors or outsourced workers. [T3.2] 16 13.1%
Host software security events. [T3.3] 15 12.3%
Require an annual refresher. [T3.4] 14 11.5%
Establish SSG office hours. [T3.5] 5 4.1%
Identify new satellite members through training. [T3.6] 1 0.8%

INTELLIGENCE
ATTACK MODELS (AM)

LEVEL 1
Create a data classification scheme and inventory. [AM1.2] 80 65.6%
Identify potential attackers. [AM1.3] 36 29.5%
Gather and use attack intelligence. [AM1.5] 51 41.8%
LEVEL 2
Build attack patterns and abuse cases tied to potential attackers. [AM2.1] 8 6.6%
Create technology-specific attack patterns. [AM2.2] 7 5.7%
Build and maintain a top N possible attacks list. [AM2.5] 16 13.1%
Collect and publish attack stories. [AM2.6] 11 9.0%
Build an internal forum to discuss attacks. [AM2.7] 10 8.2%
LEVEL 3
Have a science team that develops new attack methods. [AM3.1] 3 2.5%
Create and use automation to mimic attackers. [AM3.2] 2 1.6%
Monitor automated asset creation. [AM3.3] 0 0.0%
SECURITY FEATURES & DESIGN (SFD)

LEVEL 1
Build and publish security features. [SFD1.1] 98 80.3%
Engage the SSG with architecture teams. [SFD1.2] 69 56.6%
LEVEL 2
Leverage secure-by-design middleware frameworks and common libraries. [SFD2.1] 31 25.4%
Create an SSG capability to solve difficult design problems. [SFD2.2] 40 32.8%
LEVEL 3
Form a review board or central committee to approve and maintain secure design patterns. [SFD3.1] 11 9.0%
Require use of approved security features and frameworks. [SFD3.2] 12 9.8%
Find and publish mature design patterns from the organization. [SFD3.3] 4 3.3%

STANDARDS & REQUIREMENTS (SR)
LEVEL 1
Create security standards. [SR1.1] 83 68.0%
Create a security portal. [SR1.2] 81 66.4%
Translate compliance constraints to requirements. [SR1.3] 85 69.7%
LEVEL 2
Create a standards review board. [SR2.2] 52 42.6%
Identify open source. [SR2.4] 46 37.7%
Create SLA boilerplate. [SR2.5] 35 28.7%
LEVEL 3
Control open source risk. [SR3.1] 22 18.0%
Communicate standards to vendors. [SR3.2] 11 9.0%
Use secure coding standards. [SR3.3] 9 7.4%
Create standards for technology stacks. [SR3.4] 24 19.7%

SSDL TOUCHPOINTS
ARCHITECTURE ANALYSIS (AA)

LEVEL 1
Perform security feature review. [AA1.1] 103 84.4%
Perform design review for high-risk applications. [AA1.2] 29 23.8%
Have SSG lead design review efforts. [AA1.3] 23 18.9%
Use a risk questionnaire to rank applications. [AA1.4] 62 50.8%
LEVEL 2
Define and use AA process. [AA2.1] 18 14.8%
Standardize architectural descriptions. [AA2.2] 14 11.5%
LEVEL 3
Have engineering teams lead AA process. [AA3.1] 7 5.7%
Drive analysis results into standard architecture patterns. [AA3.2] 1 0.8%
Make the SSG available as an AA resource or mentor. [AA3.3] 4 3.3%
CODE REVIEW (CR)

LEVEL 1
Have the SSG perform ad hoc review. [CR1.2] 80 65.6%
Use automated tools along with manual review. [CR1.4] 85 69.7%
Make code review mandatory for all projects. [CR1.5] 44 36.1%
Use centralized reporting to close the knowledge loop and drive training. [CR1.6] 44 36.1%
LEVEL 2
Assign tool mentors. [CR2.5] 39 32.0%
Use automated tools with tailored rules. [CR2.6] 21 17.2%
Use a top N bugs list (real data preferred). [CR2.7] 23 18.9%
LEVEL 3
Build a capability to combine assessment results. [CR3.2] 7 5.7%
Eradicate specific bugs from the entire codebase. [CR3.3] 1 0.8%
Automate malicious code detection. [CR3.4] 4 3.3%
Enforce coding standards. [CR3.5] 2 1.6%

SECURITY TESTING (ST)
LEVEL 1
Ensure QA supports edge/boundary value condition testing. [ST1.1] 100 82.0%
Drive tests with security requirements and security features. [ST1.3] 87 71.3%
LEVEL 2
Integrate black-box security tools into the QA process. [ST2.1] 32 26.2%
Share security results with QA. [ST2.4] 15 12.3%
Include security tests in QA automation. [ST2.5] 9 7.4%
Perform fuzz testing customized to application APIs. [ST2.6] 9 7.4%
LEVEL 3
Drive tests with risk analysis results. [ST3.3] 2 1.6%
Leverage coverage analysis. [ST3.4] 1 0.8%
Begin to build and apply adversarial security tests (abuse cases). [ST3.5] 2 1.6%

DEPLOYMENT
PENETRATION TESTING (PT)

LEVEL 1
Use external penetration testers to find problems. [PT1.1] 109 89.3%
Feed results to the defect management and mitigation system. [PT1.2] 94 77.0%
Use penetration testing tools internally. [PT1.3] 82 67.2%
LEVEL 2
Penetration testers use all available information. [PT2.2] 25 20.5%
Schedule periodic penetration tests for application coverage. [PT2.3] 22 18.0%
LEVEL 3
Use external penetration testers to perform deep-dive analysis. [PT3.1] 11 9.0%
Have the SSG customize penetration testing tools and scripts. [PT3.2] 5 4.1%
SOFTWARE ENVIRONMENT (SE)

LEVEL 1
Use application input monitoring. [SE1.1] 66 54.1%
Ensure host and network security basics are in place. [SE1.2] 111 91.0%
LEVEL 2
Publish installation guides. [SE2.2] 36 29.5%
Use code signing. [SE2.4] 27 22.1%
LEVEL 3
Use code protection. [SE3.2] 13 10.7%
Use application behavior monitoring and diagnostics. [SE3.3] 4 3.3%
Use application containers. [SE3.4] 14 11.5%
Use orchestration for containers and virtualized environments. [SE3.5] 5 4.1%
Enhance application inventory with operations bill of materials. [SE3.6] 3 2.5%
Ensure cloud security basics. [SE3.7] 9 7.4%

CONFIGURATION MANAGEMENT & VULNERABILITY MANAGEMENT (CMVM)
LEVEL 1
Create or interface with incident response. [CMVM1.1] 103 84.4%
Identify software defects found in operations monitoring and feed them back to development. [CMVM1.2] 101 82.8%
LEVEL 2
Have emergency codebase response. [CMVM2.1] 91 74.6%
Track software bugs found in operations through the fix process. [CMVM2.2] 88 72.1%
Develop an operations inventory of applications. [CMVM2.3] 64 52.5%
LEVEL 3
Fix all occurrences of software bugs found in operations. [CMVM3.1] 2 1.6%
Enhance the SSDL to prevent software bugs found in operations. [CMVM3.2] 9 7.4%
Simulate software crises. [CMVM3.3] 12 9.8%
Operate a bug bounty program. [CMVM3.4] 13 10.7%
Automate verification of operational infrastructure security. [CMVM3.5] 0 0.0%
Table 6. BSIMM10 Skeleton. This expanded version of the BSIMM skeleton shows the 12 BSIMM practices and the 119 activities they
contain, along with the observation rates as both counts and percentages. Highlighted activities are the most common per practice.

In Table 7, we show the most common activities per practice. Although we can’t directly conclude that these 12 activities are
necessary for all SSIs, we can say with confidence that they’re commonly found in highly successful initiatives. This suggests
that if an organization is working on an initiative of its own, it should consider these 12 activities particularly carefully.
MOST COMMON ACTIVITIES PER PRACTICE

ACTIVITY DESCRIPTION
[SM1.4] Identify gate locations, gather necessary artifacts.

[CP1.2] Identify PII obligations.
[T1.1] Conduct awareness training.
[AM1.2] Create a data classification scheme and inventory.
[SFD1.1] Build and publish security features.
[SR1.3] Translate compliance constraints to requirements.
[AA1.1] Perform security feature review.
[CR1.4] Use automated tools along with manual review.
[ST1.1] Ensure QA supports edge/boundary value condition testing.
[PT1.1] Use external penetration testers to find problems.
[SE1.2] Ensure host and network security basics are in place.
[CMVM1.1] Create or interface with incident response.
Table 7. Most Common Activities Per Practice. This figure shows the most common activity in each of the 12 BSIMM practices.
Of course, the list above of the most common activity in each practice isn’t the same as the list of the most
common activities. If you’re working on improving your company’s SSI, you should consider these 12 activities
particularly carefully.

BSIMM10 TOP 20 ACTIVITIES BY OBSERVATION COUNT
RANK OBSERVATIONS ACTIVITY DESCRIPTION
1 111 [SE1.2] Ensure host and network security basics are in place.
2 109 [PT1.1] Use external penetration testers to find problems.
3 107 [SM1.4] Identify gate locations, gather necessary artifacts.
4 105 [CP1.2] Identify PII obligations.
5 103 [AA1.1] Perform security feature review.
6 103 [CMVM1.1] Create or interface with incident response.
7 101 [CMVM1.2] Identify software defects found in operations monitoring and feed them back to development.
8 100 [ST1.1] Ensure QA supports edge/boundary value condition testing.
9 98 [SFD1.1] Build and publish security features.
10 94 [PT1.2] Feed results to the defect management and mitigation system.
11 91 [CMVM2.1] Have emergency codebase response.
12 88 [CMVM2.2] Track software bugs found in operations through the fix process.
13 87 [ST1.3] Drive tests with security requirements and security features.
14 85 [SR1.3] Translate compliance constraints to requirements.
15 85 [CR1.4] Use automated tools along with manual review.
16 83 [SR1.1] Create security standards.
17 82 [PT1.3] Use penetration testing tools internally.
18 81 [SM1.1] Publish process and evolve as necessary.
19 81 [CP1.1] Unify regulatory pressures.
20 81 [SR1.2] Create a security portal.
Table 8. Top 20 Activities by Observation Count. Shown here are the most commonly observed activities in the BSIMM10 data.

Figure 10 shows the distribution of scores among the population of 122 participating firms. To create this graph, we
divided the scores into six bins. As you can see, the scores represent a slightly skewed bell curve. We also plotted the
average age of the firms’ SSIs in each bin as the horizontal line on the graph. In general, firms where more BSIMM
activities have been observed have older SSIs.
50
45
40
35
30
FIRMS
25
20
15
9.2
10
7.5 7.2
4.8
5 2.6
0.8
0-15 16-30 31-45 46-60 61-75 76-119
Figure 10. BSIMM Score Distribution. The majority of BSIMM10 participants have a score in the 16 to 45 range, with an average SSG age
of 2.6 to 4.8 years.

COMPARING VERTICALS
Table 9 shows the BSIMM scorecards for the eight verticals compared side by side. In the Activity columns, we have
highlighted the most common activity in each practice as observed in the entire BSIMM data pool (122 firms). See Part
Two for discussion.
GOVERNANCE
FINANCIAL ISV TECH HEALTHCARE IOT INSURANCE CLOUD RETAIL
ACTIVITY
[SM1.1] 42 30 14 10 9 6 15 5
[SM1.2] 30 25 16 7 11 4 10 5
[SM1.3] 35 26 14 9 8 4 15 4
[SM1.4] 53 35 18 14 10 10 15 9
[SM2.1] 29 17 7 5 5 3 11 5
[SM2.2] 31 15 12 5 7 3 8 3
[SM2.3] 23 21 10 7 8 6 9 4
[SM2.6] 26 14 13 7 8 2 8 4
[SM3.1] 10 6 6 2 4 1 4 1
[SM3.2] 1 5 2 1 1 1 3 1
[SM3.3] 10 3 2 2 2 1 1 0
[SM3.4] 0 0 0 0 0 0 0 0
[CP1.1] 42 27 13 14 11 7 14 4
[CP1.2] 53 31 16 16 11 9 20 9
[CP1.3] 43 21 11 10 7 6 11 5
[CP2.1] 25 14 6 9 6 2 11 4
[CP2.2] 25 12 11 9 6 3 7 2
[CP2.3] 26 15 11 8 6 3 8 3
[CP2.4] 20 15 9 8 5 3 8 4
[CP2.5] 26 20 10 10 7 4 13 2
[CP3.1] 18 8 2 2 2 2 6 0
[CP3.2] 8 3 3 3 1 2 3 1
[CP3.3] 4 2 2 0 1 0 2 0
[T1.1] 39 29 13 8 9 6 15 7
[T1.5] 20 13 7 3 4 4 8 3
[T1.7] 28 14 7 4 5 6 8 4
[T2.5] 13 10 4 2 3 2 4 3
[T2.6] 16 10 5 2 4 3 6 2
[T2.8] 9 18 7 3 6 0 10 2
[T3.1] 0 2 2 0 1 0 2 0
[T3.2] 8 7 5 2 4 3 5 1
[T3.3] 5 8 5 1 3 1 3 0
[T3.4] 10 4 2 2 2 2 3 0
[T3.5] 2 2 0 0 0 0 1 2
[T3.6] 0 1 0 0 0 0 1 0
Table 9. Vertical Comparison Scorecard. This table allows for easy comparisons of observation rates for the eight verticals tracked in BSIMM10.

INTELLIGENCE
ACTIVITY
[AM1.2] 48 19 10 10 9 6 12 7
[AM1.3] 20 8 7 5 5 3 2 2
[AM1.5] 28 12 10 8 6 4 7 5
[AM2.1] 2 1 4 2 3 1 0 1
[AM2.2] 3 3 4 0 2 0 1 0
[AM2.5] 6 6 7 2 4 1 3 1
[AM2.6] 3 5 3 3 3 1 3 0
[AM2.7] 2 5 6 1 4 0 2 0
[AM3.1] 1 1 2 0 1 0 1 1
[AM3.2] 0 1 2 0 1 0 0 0
[AM3.3] 0 0 0 0 0 0 0 0
[SFD1.1] 48 31 13 12 9 9 18 9
[SFD1.2] 30 27 16 12 10 7 13 6
[SFD2.1] 14 14 6 4 4 2 7 2
[SFD2.2] 18 16 8 4 6 4 7 4
[SFD3.1] 9 1 0 0 0 0 0 1
[SFD3.2] 4 6 2 1 1 2 6 1
[SFD3.3] 0 2 2 1 2 0 0 1
[SR1.1] 47 21 12 11 9 6 13 6
[SR1.2] 40 33 15 10 11 6 16 5
[SR1.3] 45 26 16 10 9 8 13 8
[SR2.2] 33 11 7 4 3 5 8 5
[SR2.4] 22 21 10 5 7 4 11 1
[SR2.5] 15 11 8 7 5 3 5 4
[SR3.1] 10 10 6 1 2 2 6 1
[SR3.2] 4 3 3 2 1 3 3 0
[SR3.3] 4 2 3 2 2 2 1 0
[SR3.4] 15 6 3 3 3 2 7 2

SSDL TOUCHPOINTS
ACTIVITY
[AA1.1] 50 35 17 14 11 9 17 9
[AA1.2] 10 12 9 3 5 2 5 2
[AA1.3] 7 9 7 4 3 2 4 1
[AA1.4] 38 13 7 10 6 6 7 7
[AA2.1] 5 8 9 2 4 2 2 0
[AA2.2] 5 5 6 2 4 1 1 0
[AA3.1] 3 2 4 0 3 1 1 0
[AA3.2] 0 0 0 0 0 0 0 1
[AA3.3] 1 1 3 0 2 0 1 0
[CR1.2] 37 29 14 11 7 7 13 5
[CR1.4] 44 29 14 7 10 6 15 7
[CR1.5] 19 18 10 4 4 2 7 3
[CR1.6] 24 16 6 3 4 2 9 4
[CR2.5] 21 16 6 3 4 3 7 5
[CR2.6] 16 4 2 0 1 1 4 1
[CR2.7] 12 9 2 2 1 3 5 1
[CR3.2] 2 1 1 2 0 2 1 1
[CR3.3] 0 1 0 0 0 0 1 0
[CR3.4] 4 0 0 0 0 0 0 0
[CR3.5] 2 0 0 0 0 0 0 0
[ST1.1] 51 33 20 9 12 10 15 7
[ST1.3] 44 30 17 9 10 7 13 6
[ST2.1] 14 14 8 4 6 5 3 4
[ST2.4] 7 6 5 1 2 1 3 1
[ST2.5] 3 4 4 1 2 0 3 1
[ST2.6] 0 7 7 1 4 0 2 0
[ST3.3] 0 2 1 0 1 0 2 0
[ST3.4] 0 0 1 1 1 0 0 0
[ST3.5] 0 2 1 0 1 0 2 0

DEPLOYMENT
ACTIVITY
[PT1.1] 49 40 20 13 13 11 17 9
[PT1.2] 47 33 15 9 10 5 17 8
[PT1.3] 40 26 13 11 6 7 13 8
[PT2.2] 7 11 8 4 4 3 6 2
[PT2.3] 13 9 3 0 1 0 4 2
[PT3.1] 1 6 7 2 4 1 3 2
[PT3.2] 3 1 2 0 1 0 1 0
[SE1.1] 38 14 6 12 6 6 12 5
[SE1.2] 54 40 18 14 11 9 19 9
[SE2.2] 15 15 12 2 8 2 7 2
[SE2.4] 8 16 12 1 9 2 5 1
[SE3.2] 4 4 5 2 3 1 1 3
[SE3.3] 1 3 1 0 1 0 1 0
[SE3.4] 4 9 2 0 1 0 6 3
[SE3.5] 1 4 0 0 0 0 3 0
[SE3.6] 1 2 2 0 2 0 1 0
[SE3.7] 4 5 0 1 0 0 4 0
[CMVM1.1] 50 39 18 11 12 7 19 8
[CMVM1.2] 48 34 16 12 12 7 16 9
[CMVM2.1] 47 32 14 10 10 6 16 8
[CMVM2.2] 43 31 15 9 11 5 15 9
[CMVM2.3] 35 24 9 7 7 5 11 3
[CMVM3.1] 0 1 1 0 1 0 0 0
[CMVM3.2] 2 4 4 2 3 1 3 0
[CMVM3.3] 5 3 4 2 2 1 1 2
[CMVM3.4] 4 7 2 1 1 2 6 2
[CMVM3.5] 0 0 0 0 0 0 0 0

119 BSIMM ACTIVITIES AT A GLANCE
The following is a list of BSIMM10 activities, sorted into their respective levels. Keep in mind that the levels in the
BSIMM are simply an organizing feature that allows everyone to quickly determine the relative frequency with which
each activity is observed. Those observed frequently will be at level 1, while those observed very infrequently will be at
level 3. Some activities will be inherently harder to implement for some organizations (e.g., a large organization with
thousands of applications versus a small organization with a handful), but that isn’t what’s reflected by the model’s levels.
Unlike other maturity models, each BSIMM activity is unique. A model with multiple prescriptive yet vague variations of
activities (e.g., do X, do more of X, formalize X, make X repeatable) is not a viable substitute for an observational model of
things organizations actually do. In our anecdotal experience, organizations that measure their efforts via the procedural
formality of each activity instead of the depth, breadth, and cost-effectiveness of their overall SSI are only seeing the
must-report-progress trees, not the software security forest.
The BSIMM focuses on the real-world “what” of software security, leaving the “how” and the “how much” to each
organization and its unique culture, budget, resources, constraints, software portfolio, and business objectives. Generally,
the how is trending toward automation, so it’s time to integrate an “automate first” strategy into your SSI, and the
how much derives from consistently applying a clearly defined risk management approach that is connected to other
organizational cybersecurity risk management initiatives (e.g., cloud, privacy, digital transformation).
LEVEL 1 ACTIVITIES
(Red indicates most observed BSIMM activity in that practice.)
Governance
Strategy & Metrics (SM)
• Publish process and evolve as necessary. [SM1.1]
• Create evangelism role and perform internal marketing. [SM1.2]
• Educate executives. [SM1.3]
• Identify gate locations, gather necessary artifacts. [SM1.4]
Compliance & Policy (CP)

• Unify regulatory pressures. [CP1.1]
• Identify PII obligations. [CP1.2]
• Create policy. [CP1.3]
Training (T)
• Conduct awareness training. [T1.1]
• Deliver role-specific advanced curriculum. [T1.5]
• Deliver on-demand individual training. [T1.7]

Intelligence
Attack Models (AM)
• Create a data classification scheme and inventory. [AM1.2]
• Identify potential attackers. [AM1.3]
• Gather and use attack intelligence. [AM1.5]
Security Features & Design (SFD)

• Build and publish security features. [SFD1.1]
• Engage the SSG with architecture teams. [SFD1.2]
Standards & Requirements (SR)

• Create security standards. [SR1.1]
• Create a security portal. [SR1.2]
• Translate compliance constraints to requirements. [SR1.3]
SSDL Touchpoints
Architecture Analysis (AA)
• Perform security feature review. [AA1.1]
• Perform design review for high-risk applications. [AA1.2]
• Have SSG lead design review efforts. [AA1.3]
• Use a risk questionnaire to rank applications. [AA1.4]
Code Review (CR)

• Have the SSG perform ad hoc review. [CR1.2]
• Use automated tools along with manual review. [CR1.4]
• Make code review mandatory for all projects. [CR1.5]
• Use centralized reporting to close the knowledge loop and drive training. [CR1.6]
Security Testing (ST)

• Ensure QA supports edge/boundary value condition testing. [ST1.1]
• Drive tests with security requirements and security features. [ST1.3]

Deployment
Penetration Testing (PT)
• Use external penetration testers to find problems. [PT1.1]
• Feed results to the defect management and mitigation system. [PT1.2]
• Use penetration testing tools internally. [PT1.3]
Software Environment (SE)

• Use application input monitoring. [SE1.1]
• Ensure host and network security basics are in place. [SE1.2]
Configuration Management & Vulnerability Management (CMVM)

• Create or interface with incident response. [CMVM1.1]
• Identify software defects found in operations monitoring and feed them back to development.
[CMVM1.2]

LEVEL 2 ACTIVITIES
Governance
• Publish data about software security internally. [SM2.1]
• Enforce gates with measurements and track exceptions. [SM2.2]
• Create or grow a satellite. [SM2.3]
• Require security sign-off. [SM2.6]

• Identify PII inventory. [CP2.1]
• Require security sign-off for compliance-related risk. [CP2.2]
• Implement and track controls for compliance. [CP2.3]
• Include software security SLAs in all vendor contracts. [CP2.4]
• Ensure executive awareness of compliance and privacy obligations. [CP2.5]
Training (T)
• Enhance satellite through training and events. [T2.5]
• Include security resources in onboarding. [T2.6]
• Create and use material specific to company history. [T2.8]
Intelligence
Attack Models (AM)
• Build attack patterns and abuse cases tied to potential attackers. [AM2.1]
• Create technology-specific attack patterns. [AM2.2]
• Build and maintain a top N possible attacks list. [AM2.5]
• Collect and publish attack stories. [AM2.6]
• Build an internal forum to discuss attacks. [AM2.7]

• Leverage secure-by-design middleware frameworks and common libraries. [SFD2.1]
• Create an SSG capability to solve difficult design problems. [SFD2.2]

• Create a standards review board. [SR2.2]
• Identify open source. [SR2.4]
• Create SLA boilerplate. [SR2.5]

SSDL Touchpoints
• Define and use AA process. [AA2.1]
• Standardize architectural descriptions. [AA2.2]
Code Review (CR)

• Assign tool mentors. [CR2.5]
• Use automated tools with tailored rules. [CR2.6]
• Use a top N bugs list (real data preferred). [CR2.7]

• Integrate black-box security tools into the QA process. [ST2.1]
• Share security results with QA. [ST2.4]
• Include security tests in QA automation. [ST2.5]
• Perform fuzz testing customized to application APIs. [ST2.6]
Deployment
• Penetration testers use all available information. [PT2.2]
• Schedule periodic penetration tests for application coverage. [PT2.3]

• Publish installation guides. [SE2.2]
• Use code signing. [SE2.4]

• Have emergency codebase response. [CMVM2.1]
• Track software bugs found in operations through the fix process. [CMVM2.2]
• Develop an operations inventory of applications. [CMVM2.3]

LEVEL 3 ACTIVITIES
Governance
• Use an internal tracking application with portfolio view. [SM3.1]
• Run an external marketing program. [SM3.2]
• Identify metrics and use them to drive budgets. [SM3.3]
• Integrate software-defined lifecycle governance. [SM3.4]

• Create a regulator compliance story. [CP3.1]
• Impose policy on vendors. [CP3.2]
• Drive feedback from software lifecycle data back to policy. [CP3.3]
Training (T)
• Reward progression through curriculum. [T3.1]
• Provide training for vendors or outsourced workers. [T3.2]
• Host software security events. [T3.3]
• Require an annual refresher. [T3.4]
• Establish SSG office hours. [T3.5]
• Identify new satellite members through training. [T3.6]
Intelligence
Attack Models (AM)
• Have a science team that develops new attack methods. [AM3.1]
• Create and use automation to mimic attackers. [AM3.2]
• Monitor automated asset creation. [AM3.3]

• Form a review board or central committee to approve and maintain secure design patterns. [SFD 3.1]
• Require use of approved security features and frameworks. [SFD3.2]
• Find and publish mature design patterns from the organization. [SFD3.3]

• Control open source risk. [SR3.1]
• Communicate standards to vendors. [SR3.2]
• Use secure coding standards. [SR3.3]
• Create standards for technology stacks. [SR3.4]

SSDL Touchpoints
• Have engineering teams lead AA process. [AA3.1]
• Drive analysis results into standard architecture patterns. [AA3.2]
• Make the SSG available as an AA resource or mentor. [AA3.3]
Code Review (CR)

• Build a capability to combine assessment results. [CR3.2]
• Eradicate specific bugs from the entire codebase. [CR3.3]
• Automate malicious code detection. [CR3.4]
• Enforce coding standards. [CR3.5]

• Drive tests with risk analysis results. [ST3.3]
• Leverage coverage analysis. [ST3.4]
• Begin to build and apply adversarial security tests (abuse cases). [ST3.5]
Deployment
• Use external penetration testers to perform deep-dive analysis. [PT3.1]
• Have the SSG customize penetration testing tools and scripts. [PT3.2]

• Use code protection. [SE3.2]
• Use application behavior monitoring and diagnostics. [SE3.3]
• Use application containers. [SE3.4]
• Use orchestration for containers and virtualized environments. [SE3.5]
• Enhance application inventory with operations bill of materials. [SE3.6]
• Ensure cloud security basics. [SE3.7]

• Fix all occurrences of software bugs found in operations. [CMVM3.1]
• Enhance the SSDL to prevent software bugs found in operations. [CMVM3.2]
• Simulate software crises. [CMVM3.3]
• Operate a bug bounty program. [CMVM3.4]
• Automate verification of operational infrastructure security. [CMVM3.5]

Find out how to unlock access to an engaged BSIMM member community,
including conferences, newsletters, and original content.
Go to www.bsimm.com

Bsimm10 PDF

Uploaded by

Copyright:

Available Formats

Bsimm10 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bsimm10 PDF

Uploaded by

Copyright:

Available Formats

Sammy Migues, John Steven,

& Mike Ware

PAGE 2 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 3

Adobe Depository Trust & Medtronic

PAGE 4 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BSIMM History.........................................................6 Deployment............................................................ 58

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 5

PAGE 6 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

The following are the five changes we made for BSIMM10:

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 7

PAGE 8 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

SOFTWARE SECURITY GROUP (SSG)

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 9

PAGE 10 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

For a study of CISOs and their organizations, see https://www.synopsys.com/software-integrity/resources/analyst-reports/ciso.html

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 11

PAGE 12 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

STRATEGY & METRICS ATTACK MODELS ARCHITECTURE ANALYSIS PENETRATION TESTING

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 13

SECURITY SECURITY FEATURES

CODE STANDARDS &

USING THE BSIMM TO START OR IMPROVE AN SSI

HOW TO USE THIS SECTION

PAGE 14 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 15

THE NEW WAVE OF ENGINEERING CULTURE

PAGE 16 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

WAYPOINTS ALONG YOUR JOURNEY

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 17

PAGE 18 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

MATURING GOVERNANCE-LED SSIs

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 19

PAGE 20 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 21

EMERGING ENGINEERING-LED CULTURE

PAGE 22 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 23

MATURING ENGINEERING-LED EFFORTS

PAGE 24 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 25

PAGE 26 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

GOVERNANCE INTELLIGENCE SSDL TOUCHPOINTS DEPLOYMENT

GOVERNANCE INTELLIGENCE SSDL TOUCHPOINTS DEPLOYMENT

1. Strategy & Metrics 4. Attack Models 7. Architecture Analysis 10. Penetration

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 27

LEVEL 1 LEVEL 1 LEVEL 1

LEVEL 2 LEVEL 2 LEVEL 2

LEVEL 3 LEVEL 3 LEVEL 3

PAGE 28 | BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10

SECURITY FEATURES STANDARDS

LEVEL 1 LEVEL 1 LEVEL 1

LEVEL 2 LEVEL 2 LEVEL 2

LEVEL 3 LEVEL 3 LEVEL 3

BUILDING SECURITY IN MATURITY MODEL (BSIMM) – VERSION 10 | PAGE 29

ARCHITECTURE ANALYSIS (AA) CODE REVIEW (CR) SECURITY TESTING (ST)

LEVEL 1 LEVEL 1 LEVEL 1

LEVEL 2 LEVEL 2 LEVEL 2

LEVEL 3 LEVEL 3 LEVEL 3