Software Assurance Maturity Model (SAMM) Interview Template

Version: 1.00

Author: Nick Coblentz

Nick.Coblentz@gmail.com
The Software Assurance Maturity Model (SAMM) includes a set of questions used to evaluate an organ
http://nickcoblentz.blogspot.com
SAMM Interview Template expands on those questions to include assertions that give further assurance
This document is intended to be used to help document and evaluate responses during interviews with
Description: appropriate individuals.

Contributors:

License: Creative Commons Attribution-ShareAlike 3.0 License

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license, visit
sa/3.0/legalcode; or, (b) send
The Software Assurance a letterModel
Maturity to Creative
(SAMM)Commons, 171 2nd
was created by Street, Suite 300, San Francisco, California, 94105, U
Pravir Chandra.
It is licensed under the Creative Commons Attribution-Share Alike 3.0 License
SAMM Website: http://www.opensamm.org
w Template

used to evaluate an organization against the maturity model. The

that give further assurance as to the quality of individual's answers.
nses during interviews with development staff, managers, or other

a copy of this license, visit http://creativecommons.org/licenses/by-

ancisco, California, 94105, USA.
 SAMM Assessment Interview: <Project Name Here> Fo
Instructions
Interview an individual based on the questions below organized according to SAMM Business Functions and Security Prac
Place a "Yes" or "No" next to each question or assertion based on the individual's response.
Document additional information such as how and why in the "Interview Notes" column.
In order to mark "Yes" on a question, each assertion below that question must also be satisfied.
Once the interview is complete, go to the "Scorecard" sheet and follow instructions.

Organization:
Project:
Interview Date:
Interviewer:
Person Interviewed:

Governance
Level Strategy & Metrics
SM1 Is there a software security assurance program already in place?
Assertion:
Assertion:
Assertion:

SM1 Is most of your development staff aware of future plans for the assurance program?
Assertion:
Assertion:
Assertion:

SM1 Do most of the business stakeholders understand your organization’s risk profile?
Assertion:
Assertion:
Assertion:
Assertion:

SM2 Are most of your applications and resources categorized by risk?

Assertion:
Assertion:
Assertion:
Assertion:

SM2 Are risk ratings used to tailor the required assurance activities?
Assertion:

SM2 Does most of the organization know about what’s required based on risk ratings?
Assertion:

SM3 Is per-project data for cost of assurance activities collected?

Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
 Assertion:

SM3 Does your organization regularly compare your security spending with other organizations?
Assertion:
Assertion:
Assertion:

Level Policy & Compliance

PC1 Do most project stakeholders know their project’s compliance status?
Assertion:

PC1 Are compliance requirements specifically considered by project teams?

Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

PC2 Does the organization utilize a set of policies and standards to control software development?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

PC2 Are project teams able to request an audit for compliance with policies and standards?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

PC3 Are projects periodically audited to ensure a baseline of compliance with policies and standards?
Assertion:
Assertion:
Assertion:

PC3 Does the organization systematically use audits to collect and control compliance evidence?
Assertion:
Assertion:
Assertion:

Level Education & Guidance

EG1 Have most developers been given high-level security awareness training?
Assertion:
Assertion:
Assertion:

EG1 Does each project team have access to secure development best practices and guidance?
Assertion:
Assertion:
 Assertion:

EG2 Are most roles in the development process given role-specific training and guidance?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

EG2 Are most stakeholders able to pull in security coaches for use on projects?
Assertion:
Assertion:
Assertion:

EG3 Is security-related guidance centrally controlled and consistently distributed throughout the organizatio
Assertion:
Assertion:
Assertion:
Assertion:

EG3 Are most people tested to ensure a baseline skillset for secure development practices?
Assertion:
Assertion:
Assertion:
Assertion:

Construction
Level Threat Assessment
TA1 Do most projects in your organization consider and document likely threats?
Assertion:
Assertion:
Assertion:
Assertion:

TA1 Does your organization understand and document the types of attackers it faces?
Assertion:
Assertion:
Assertion:

TA2 Do project teams regularly analyze functional requirements for likely abuses?
Assertion:
Assertion:

TA2 Do project teams use a method of rating threats for relative comparison?
Assertion:
Assertion:

TA2 Are stakeholders aware of relevant threats and ratings?

Assertion:
TA3 Do project teams specifically consider risk from external software?
Assertion:
Assertion:

TA3 Are all protection mechanisms and controls captured and mapped back to threats?
Assertion:
Assertion:
Assertion:
Assertion:

Level Security Requirements

SR1 Do most project teams specify some security requirements during development?
Assertion:
Assertion:
Assertion:
Assertion:

SR1 Do project teams pull requirements from best practices and compliance guidance?
Assertion:
Assertion:
Assertion:

SR2 Are most stakeholders reviewing access control matrices for relevant projects?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

SR2 Are project teams specifying requirements based on feedback from other security activities?
Assertion:

SR3 Are most stakeholders reviewing vendor agreements for security requirements?
Assertion:

SR3 Are the security requirements specified by project teams being audited?
Assertion:
Assertion:
Assertion:
Assertion:

Level Secure Architecture

SA1 Are project teams provided with a list of recommended third-party components?
Assertion:
Assertion:
Assertion:

SA1 Are most project teams aware of secure design principles and applying them?
Assertion:
Assertion:
SA2 Do you advertise shared security services with guidance for project teams?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

SA2 Are project teams provided with prescriptive design patterns based on their application architecture?
Assertion:
Assertion:
Assertion:

SA3 Are project teams building software from centrally controlled platforms and frameworks?
Assertion:
Assertion:

SA3 Are project teams being audited for usage of secure architecture components?
Assertion:
Assertion:

Verification
Level Design Review
DR1 Do project teams document the attack perimeter of software designs?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

DR1 Do project teams check software designs against known security risks?
Assertion:
Assertion:
Assertion:
Assertion:

DR2 Do most project teams specifically analyze design elements for security mechanisms?
Assertion:
Assertion:
Assertion:

DR2 Are most project stakeholders aware of how to obtain a formal design review?
Assertion:
Assertion:
Assertion:

DR3 Does the design review process incorporate detailed data-level analysis?
Assertion:
Assertion:
Assertion:
DR3 Does routine project audit require a baseline for design review results?
Assertion:
Assertion:
Assertion:
Assertion:

Level Code Review

CR1 Do most project teams have review checklists based on common problems?
Assertion:
Assertion:

CR1 Are project teams generally performing review of selected high-risk code?
Assertion:
Assertion:
Assertion:

CR2 Can most project teams access automated code analysis tools to find security problems?
Assertion:
Assertion:

CR2 Do most stakeholders consistently require and review results from code reviews?
Assertion:
Assertion:

CR3 Do project teams utilize automation to check code against application-specific coding standards?
Assertion:

CR3 Does routine project audit require a baseline for code review results prior to release?
Assertion:
Assertion:

Level Security Testing

ST1 Are projects specifying some security tests based on requirements?
Assertion:
Assertion:
Assertion:

ST1 Do most projects perform penetration tests prior to release?

Assertion:
Assertion:
Assertion:

ST1 Are most stakeholders aware of the security test status prior to release?
Assertion:
Assertion:
Assertion:

ST2 Are projects using automation to evaluate security test cases?

Assertion:
Assertion:
ST2 Do most projects follow a consistent process to evaluate and report on security tests to stakeholders?
Assertion:
Assertion:

ST3 Are security test cases comprehensively generated for application-specific logic?
Assertion:

ST3 Do routine project audits demand minimum standard results from security testing?
Assertion:
Assertion:

Deployment
Level Vulnerability Management
VM1 Do most projects have a point of contact for security issues?
Assertion:
Assertion:

VM1 Does your organization have an assigned security response team?

Assertion:
Assertion:

VM1 Are most project teams aware of their security point(s) of contact and response team(s)?
Assertion:

VM2 Does the organization utilize a consistent process for incident reporting and handling?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

VM2 Are most project stakeholders aware of relevant security disclosures related to their software projects?
Assertion:

VM3 Are most incidents inspected for root causes to generate further recommendations?
Assertion:
Assertion:
Assertion:
Assertion:

VM3 Do most projects consistently collect and report data and metrics related to incidents?
Assertion:
Assertion:
Assertion:

Level Environment Hardening

EH1 Do the majority of projects document some requirements for the operational environment?
Assertion:
 Assertion:
Assertion:
Assertion:

EH1 Do most projects check for security updates to third-party software components?
Assertion:
Assertion:

EH2 Is a consistent process used to apply upgrades and patches to critical dependencies?
Assertion:
Assertion:
Assertion:

EH2 Do most project leverage automation to check application and environment health?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

EH3 Are stakeholders aware of options for additional tools to protect software while running in operations?
Assertion:
Assertion:

EH3 Does routine audit check most projects for baseline environment health?
Assertion:
Assertion:
Assertion:
Assertion:

Level Operational Enablement

OE1 Do you deliver security notes with the majority of software releases?
Assertion:
Assertion:
Assertion:
Assertion:

OE1 Are security-related alerts and error conditions documented for most projects?
Assertion:
Assertion:
Assertion:
Assertion:

OE2 Are most project utilizing a change management process that’s well understood?
Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

OE2 Do project teams deliver an operational security guide with each product release?
 Assertion:
Assertion:
Assertion:
Assertion:
Assertion:

OE3 Are most projects being audited to check each release for appropriate operational security information?
Assertion:
Assertion:

OE3 Is code signing routinely performed on software components using a consistent process?
Assertion:
Assertion:
Assertion:
Assertion:
 SAMM Assessment Interview: <Project Name Here> For <Interview Date
Instructions
ndividual based on the questions below organized according to SAMM Business Functions and Security Practices.
or "No" next to each question or assertion based on the individual's response.
ditional information such as how and why in the "Interview Notes" column.
ark "Yes" on a question, each assertion below that question must also be satisfied.
rview is complete, go to the "Scorecard" sheet and follow instructions.

<Org Name Here>

<Project Name Here>
<Interview Date Here>
<Interviewer Here>
<Person Interviewed Here>

Governance
Strategy & Metrics
there a software security assurance program already in place?
Assurance program is documented and accessible to staff.
Assurance program has been used in recent development efforts.
Staff receives training against assurance program and responsibilities.

most of your development staff aware of future plans for the assurance program?
Assurance program goals are documented and accessible to staff.
Assurance program goals have been presented to staff.
A plan has been put in place to reach those goals in a specific period of time.

o most of the business stakeholders understand your organization’s risk profile?

Organization has documented motivation behind creating a software security assurance program.
Assurance program has been customized to align with the organization's motivation and goals.
Worst-case scenarios for organization's application and data assets have been collected and documented.
Scenarios, contributing factors, and mitigating factors have been reviewed with business owners and other stakeholders.

re most of your applications and resources categorized by risk?

A data and application risk classification system has been documented.
An evaluation criteria has been created to apply the classification system to data and applications.
Staff receives training in how to apply evaluation criteria to application and data assets.
Most applications and data have been categorized using this evaluation criteria.

re risk ratings used to tailor the required assurance activities?

The assurance program is customized based on data and application risk classification.

oes most of the organization know about what’s required based on risk ratings?
Staff receives training according to documented assurance program and risk classifications.

per-project data for cost of assurance activities collected?

Statistics are collect for spending related to security incidents or breaches.
Baseline security costs are estimated based on each project based on it's assigned security assurance road map and risk
Actual security spending is tracked for each project.
Actual spending vs. estimated spending is evaluated on a quarterly basis.
Spending statistics and historical data are used to make case-by-case decisions on security expenditures.
 Security spending decisions are made on a per project basis with consideration for expense versus loss potential.

oes your organization regularly compare your security spending with other organizations?
Statistics regarding similar organization's security spending is collected regularly.
Compare potential cost savings by purchasing products or switching vendors for security tools.
Security cost-comparison exercises are conducted at least annually.

Policy & Compliance

o most project stakeholders know their project’s compliance status?
Project stakeholders review project's compliance status biannually.

re compliance requirements specifically considered by project teams?

External, third-party regulatory or compliance requirements have been identified.
A consolidated
Control list oforregulatory
statements responsesand compliance
have requirements
been created has been
for each security mapped toindicating
requirement security requirements.
how the organization will mee
requirement.
Security requirements are added to each project based on applicable regulatory and compliance standards.
The organization researches and updates regulatory or compliance requirements biannually.

oes the organization utilize a set of policies and standards to control software development?
A set of security policies has been created based on compliance drivers.
Optional or recommended compliance items have been added to security policies.
Requirements based on known business drivers for security have been added to security policies.
Common or similar policies have been grouped, generalized, and rewritten to satisfy compliance and security requirements
Security policies do not include requirements that are too costly or difficult for project teams to comply.
Awareness programs have been created to advertise and spread awareness of security policies.

re project teams able to request an audit for compliance with policies and standards?
A process has been created for project teams to request an audit against security policies and compliance requirements.
Internal audits are prioritized based on business risk indicators.
Each project undergoes an audit at least biannually.
Awareness programs have been created to advertise and spread awareness of the organization's audit process.
Audit results are reviewed by project stakeholders including per requirement pass/fail status, impact, and remediation.

re projects periodically audited to ensure a baseline of compliance with policies and standards?
Compliance and security gates are established throughout the development process.
An exception approval process has been created for legacy or other specialized projects.
Automated tools (code review, penetration testing, etc) are used to assist in identifying non-compliance prior to the audit pr

oes the organization systematically use audits to collect and control compliance evidence?
An automated system is used to capture, organize, and display audit data and documentation.
Access to audit data is controlled based on a need to know
Instructions and procedures for accessing audit data are published and advertised to project groups.

Education & Guidance

ave most developers been given high-level security awareness training?
Application security awareness training is provided to all developers.
Training covers topics such as common vulnerabilities and best practice recommendations for eliminating vulnerabilities.
Training is conducted at least annually as well as on demand based on need.

oes each project team have access to secure development best practices and guidance?
Resources regarding secure development practices have been assembled and made available to developers.
Management informs development groups that they are expected to utilize secure development resources.
 A checklist based on the secure development resources has been created to ensure guidelines are met during developme

re most roles in the development process given role-specific training and guidance?
Role specific
Managers andapplication security
requirements training
specifiers is given
receive to developers,
training in securityarchitects, QA, planning,
requirements etc. vulnerability and incident manag
threat modeling, and misuse/abuse case design.
Testers and auditors receive training in code review, architecture and design analysis, runtime analysis, and effective secu
planning.
Developer training includes security design patterns, tool-specific training, threat modeling and software assessment techn
Role specific training is provided at least annually as well as on demand based on need.

re most stakeholders able to pull in security coaches for use on projects?

Internal or external security experts are available to project teams for consultation.
The process for requesting these experts is advertised to project teams.
A set security analysts or security-savvy developers have been selected as security coaches.

security-related guidance centrally controlled and consistently distributed throughout the organization?
A centralized repository has been created to organize secure development information, resources, and processes.
An approval board and change control management process is in place to control modification of information in this reposi
A method for collaboration and communication of secure development topics has been provided.
Content is searchable based on common factors like platform, language, library, life-cycle stage, etc.

re most people tested to ensure a baseline skillset for secure development practices?
Exams are used to verify retention of security knowledge in a per training module or per role context.
Exams are given to staff at least biannually.
Staff are organized or ranked based on exam scores.
Some security activities or gates require staff of a certain rank to sign off before the item is marked as complete.

Construction
Threat Assessment
o most projects in your organization consider and document likely threats?
Likely worst-case scenarios are documented for each project based on its business risk profile.
Attack trees or a threat model is created for each project tracing the preconditions necessary for a worst-case scenario to b
Attack trees or threat models are expanded to include potential security failures in current and historical functional requirem
When new features are added to a project, attack trees or threat models are updated.

oes your organization understand and document the types of attackers it faces?
Potential external threat agents and their motivations are documented for each project.
Potential internal threat agents, their associated roles, and damage potential are documented for each project or architectu
A common set of threat agents, motivations, and other information is collected at the organization level and re-used within

o project teams regularly analyze functional requirements for likely abuses?

Each project derives abuse-cases from its use-cases.
As project requirements or features are added, abuse-cases are updated.

o project teams use a method

A documented of rating
weighting threats
system foron
based relative comparison?
documented threat agents, exploit value, technical difficulty, and other factors is
rank threats.
Remediation of vulnerabilities is prioritized based on the weighting system.

re stakeholders aware of relevant threats and ratings?

Potential threats and ratings are reviewed with project stakeholders.
o project teams specifically consider risk from external software?
Third-party, external libraries and code used in each project are clearly identified and documented for each project.
Project threat models are updated based on identified threat agents and motivations for third party libraries and code.

re all protection mechanisms

An assessment forand
eachcontrols captured
project has and mapped
been conducted back tomitigating
to identify threats?controls that prevent preconditions identified in a
or threat models.
This assessment is updated each time new features or requirements are introduced or the attack tree is modified.
have
Mitigating controls or been requirements
security documented within the attack
have been addedtree or threat
to each model.
project to address any preconditions that still lead to
successful attack within attack trees.

Security Requirements
o most project teams specify some security requirements during development?
Security requirements are derived from functional requirements and customer/organization concerns.
A security auditor leads specification of security requirements within each project.
Security requirements are specific, measurable, and reasonable.
Security requirements are documented for each project.

o project teams pull requirements from best practices and compliance guidance?
Industry best practices are used to derive additional security requirements.
Existing
Plans to code bases
refactor are analyzed
existing by a security
code to implement auditor
security for opportunities
requirements to add security
are prioritized requirements.
by project stakeholders including risk ma
senior developers, and architects.

re most stakeholders reviewing access control matrices for relevant projects?

Users, roles, and privileges are identified in each project.
Resources and capabilities are identified in each project.
A matrix of roles and capabilities is documented for each project.
As new features are introduced, the matrix documentation is updated.
The matrix is reviewed with project stakeholders prior to release.

re project teams specifying

Additional requirements
security requirementsbased on feedback
are created from
based on other security
feedback from codeactivities?
reviews, penetration tests, risk assessments, o
security activities.

re most stakeholders reviewing vendor agreements for security requirements?

During the creation of third-party agreements, specific security requirements, activities, and processes are considered for i

re the security requirements specified by project teams being audited?

Audits are routinely performed to ensure security requirements have been specified for all functional requirements.
Audits also verify attack trees are constructed and mitigating controls are annotated.
A list of unfulfilled security requirements and their projected implementation date is documented.
Security requirement audits is performed on every development iteration prior to the implementation of code.

Secure Architecture
re project teams provided with a list of recommended third-party components?
A weighted
The librarieslist
areofinformally
commonlyevaluated
used third-party libraries
for security basedandoncode
pastisincidents,
collectedresponses
and documented across
to identified the organization.
issues, complexity, and
appropriateness to the organization. Risk associated with these components are documented.
A list of approved third-party libraries for use within development projects is published.

re most project teams aware of secure design principles and applying them?
A list of secure design principles (such as defense in depth) have been collected and documented.
These principles are used as a checklist during the design phase of each project.
 A list of reusable resources is collected and categorized based on the security mechanisms they fulfill (LDAP server, singl
o you advertise shared
server, etc.).security services with guidance for project teams?

The organization has selected a set of reusable resources to standardize on.

These resources have been thoroughly audited for security issues.
Design guidance has been created for secure integration of each component within a project.
Project groups receive training regarding the proper use and integration of these components.

re project teams provided with prescriptive design patterns based on their application architecture?
Each
A project
set of designis categorized based on architecture
patterns is documented (client-server,
for each architecture web application,
(Risk-based thick client,
authentication etc.).
system, single sign-on, centralized
etc.).
Architects, senior developers, or other project stakeholders identify applicable and appropriate patterns for each project du
design phase.

re project teams building

Reusable codesoftware frombased
components centrally controlled design
on established platforms and frameworks?
patterns and shared security services have been created for use
projects across the organization.
Reusable code components are regularly maintained, updated, and assessed for risk.

re project teams being

Audits audited
include for usage
evaluation of secure
of usage architecture
of recommended components?
frameworks, design patterns, shared security services, and reference
platforms.
Results are used to determine if additional frameworks, resources, or guidance need to be specified as well as the quality
provided to project teams.

Verification
Design Review
o project teams document the attack perimeter of software designs?
project group
Each component in creates a simplified
the diagram one-page
is analyzed architecture
in terms diagram
of accessibility representing
of the high-level
interface from modules.
authorized users, anonymous us
operators, application-specific roles, etc.
Interfaces and components with similar accessibility profiles are grouped and documented as the software attack surface.
One-page architecture diagram is annotated with security-related functionality.
Grouped interface designs are evaluated to determine whether security-related functionality is applied consistently.
Architecture diagrams and attack surface analysis is updated when an application's design is altered.

o project teams check software designs against known security risks?

Each project group documents a list of assumptions the software relies on for safe execution.
Each project
project'sgroup documents
one-page a list ofdiagram
architecture securityisrequirements
evaluated forfor the application.
security requirements and assumptions. Missing items are
documented as findings.
Evaluations are repeated when security requirements are added or the high-level system design changes occur within a pr

o most project teams

Each specifically
interface analyze
within the design
high-level elements
architecture for security
diagram mechanisms?
is formally inspected for security mechanisms (includes internal a
application tiers).
Analysis includes the following minimum categories: authentication, authorization, input validation, output encoding, error h
logging, cryptography, and session management.
Each software release is required to undergo a design review.

re most project stakeholders aware of how to obtain a formal design review?

A process for requesting a formal design review is created and advertised to project stakeholders.
The design
Design review
reviews process
include is centralized
verification and requests
of software's attack are prioritized
surface, based
security on the organization's
requirements, and securitybusiness risk profile.
mechanisms within mo
interfaces.

oes the design review process incorporate detailed data-level analysis?

Project teams identify
documentdetails on system
relevant behavior
software around
modules, data high-risk
sources, functionality (such as CRUD
actors, and messages of sensitive
that flow betweendata).
data sources o
functions.
Utilizing the data flow diagram, project teams identify software modules that handle data or functionality with differing sens
oes routine project audit require a baseline for design review results?
A consistent design review program has been established.
A criteria gates
Release is created to determine
are used within thewhether a project
development passes
process to the design
ensure reviewcannot
projects process (for example
advance no high-risk
to the next findings).
step until the proje
succesfully
A process iscompletes a design
established review.
for handling design review results in legacy projects, including a requirement to establish a time fr
successfully completing the design review process.

Code Review
o most project teams have review checklists based on common problems?
The organization has derived a light-weight code review checklist based on previously identified security requirements.
Developers receive training regarding their role and the goals of the checklist.

re project teams generally performing review of selected high-risk code?

High-risk software components are prioritized above other code during the review process.
Security auditors or code review tools are utilized to perform the checklist based code review.
Remediation of findings in high-risk components are prioritized appropriately.

an most project
The teams access
organization automated
has code source,
reviewed open analysiscommercial,
tools to find security
and problems?
other solution for performing automated code reviews and s
solution that will best fit the organization.
Automated code analysis has been integrated within the development process (at code check-in for example).

o most stakeholders consistently require and review results from code reviews?
Project stakeholders review and accept any risks that they choose not to address.
Project stakeholders have created a plan for addressing findings in legacy code.

o project teams utilize automation

Automated code review to check
tools are code against
customized to application-specific
perform additional APIcoding
checks,standards?
verify organization coding standards, etc. (
the addition of custom rules).

oes routine project audit contains

Each project require aa baseline forincode
checkpoint review results
the development priorthat
process to release?
requires a specific level of code review results to be m
release.
The organization has established an exception process for legacy code, which requires a certain level of assurance to be m
specific time period

Security Testing
re projects specifying some security tests based on requirements?
The organization has documented general test cases based on security requirements and common vulnerabilities.
Each project has documented test cases for security requirements specific to that project.
Staff ensures test cases are applicable, feasible, and can be executed by relevant development, security, and quality assu

o most projects perform penetration tests prior to release?

Project teams engage security auditors to perform penetration testing.
Penetration testing covers security requirements and test cases at a minimum.
Penetration testing issues are resolved to an acceptable level of risk prior to release.

re most stakeholders aware of the security test status prior to release?

Penetration testing issues are reviewed with project stakeholders.
Project stakeholders select issues to remediate prior to release.
Project stakeholders set a time line for addressing identified issues or accept outstanding risks.

re projects using automationhas

The organization to evaluate
reviewedsecurity test cases?
open source, commercial, and other solution for performing automated security testing and
solution that will best fit the organization.
Automated security testing has been integrated within the development process.
o most projects follow a consistent process to evaluate and report on security tests to stakeholders?
Automated security testing occurs across projects on a regular, scheduled basis.
A process has been created for reviewing security testing results with project stakeholders and remediating risk.

re security test cases

Using comprehensively
automated generated
tools, unit tests, or otherfor application-specific
similar logic?
methods, a comprehensive set of security test cases is constructed and
for each project.

o routine project
Eachaudits
projectdemand
containsminimum standard
a checkpoint results fromprocess
in the development securitythat
testing?
requires a specific level of security testing results to b
before
The release. has established an exception process for handling security testing results in legacy projects, which requir
organization
level of assurance to be met within a specific time period

Deployment
Vulnerability Management
o most projects have a point of contact for security issues?
Each project or development group has assigned a security-savvy developer to be the point of contact for security issues.
The organization maintains a centralized list of applications, projects, and points of contact regarding security issues.

oes your organization have an

The organization hasassigned
defined asecurity response
centralized securityteam?
response team responsible for managing incidents, vulnerability report
remediation, and reporting.
During an incident, the security response team provides briefings and upward communication.

re most project teams aware of their security point(s) of contact and response team(s)?
The security response team meets with project groups at least annually to brief individuals on the incident response proces

oes the organization utilize a consistent process for incident reporting and handling?
The
The organization has aprocess
incident response documented process
includes itemsfor incident
such handling
as triage and reporting,
to prevent additionalincluding
damage,team members'
change roles and
management andrespo
patc
The incident response team receives training at least annually.
application, managing project personnel and others involved in the incident, forensic evidence collection and preservation,
communication about the incident to stakeholders, well-defined reporting to stakeholders and/or communications trees, etc
The organization has adopted and documented a security issue disclosure process.
The organization has adopted and documented a patch release process.
The organization has adopted and documented a process for collaborating with individuals exercising responsible disclosu
The organization advertises
has adopteda process for handling
and documented issues disclosed
a practice responsibly
for disclosing incidentsbytothird-parties.
the public (if necessary and in complia
state and federal laws).

re most project stakeholders aware of relevant security disclosures related to their software projects?
A formal, documented process has been established for tracking, handling, and communicating incidents internally.

re most incidents inspected for root causes to generate further recommendations?

Incident response teams investigate root causes of security failures leading to an incident or security issue.
The root cause is used to analyze the project or software for additional potential failures.
The root cause is compared to security requirements and existing processes to determine how to improve security assuran
The root cause is reviewed with project stakeholders and management to determine a mitigation process and time frame.

o most projects consistently

Metrics collect and
such as frequency report data
of software and affected
projects metrics by
related to incidents?
incidents, system downtime and cost from loss of use, human r
The organization's
taken centralized
in handling and cleanup incident response
of the incident, processofislong-term
estimates expandedcosts
to collect
such and record metrics.
as regulatory fines or brand damage, etc.
collected.
Past security incidents are recorded and reviewed every six months and recommendations to improve the organization or
assurance process are made.

Environment Hardening
o the majority of projects document some requirements for the operational environment?
The organization documents and maintains a set of baseline operating platforms.
 project teams expand on existing, approved baseline operating platforms to meet project requirements.
Project teams document assumptions made about operating environments during development.
Organization and project operating platforms are reviewed at least every six months.

o most projects check for security updates to third-party software components?

Project teams or the operations team regularly monitors software components for security updates.
Project teams or the operations team apply critical software component updates once identified.

a consistent process used to apply upgrades and patches to critical dependencies?

A documented ongoing process has been created at the organization level to consistently identify and apply security patch
The patch management process requires security patches to be applied within a specific time window based on risk.
Project teams share a list of third-party components and a source for updates with the operations team.

o most project
Theleverage automation
organization to check
has reviewed openapplication and environment
source, commercial, and otherhealth?
solution for performing automated monitoring and patc
management
Automated and has selected
monitoring and patcha management
solution that will best
tools and fit processes
the organization.
has been integrated within the organization's operation
environments.
Project teams and
The automated the operations
monitoring team
and patch document and
management implement
tools generateapplication-level heath checks.
alerts and a documented process for handling and resp
these alerts
Project teamshas been
and the established.
operations team reviews configuration changes and alerts at least quarterly in order to improve curr
processes.

re stakeholders aware of options for additional tools to protect software while running in operations?
The security team or operations team reviews optional tools for protecting software with project stakeholders.
Appropriate solutions such as a WAF, IPS, HIDS, etc. are adopted for each project's operational environment.

oes routine audit check most projects for baseline environment health?
Project-level audits include analysis and testing of the operational environment in which the software resides.
Audits include verification of compliance with the organization's patch management process.
Operational
The environment
organization audits occur
has established at least every
an exception six months.
process for legacy operational environments, which requires a certain level
assurance to be met within a specific time period.

Operational Enablement
o you deliverProject
security notes with the majority of software releases?
teams document security-relevant configuration and operations information and provide documentation to users an
operators.
Project teams document a list of security features built into the software, options for configuration, security impacts, and in
secure default.
Project stakeholders review security documentation prior to release.
Project teams update security documentation at least every six months.

re security-related alerts and error conditions documented for most projects?

Project teams document important security-related alerts and error conditions and provide the documentation to the opera
Project teams update alerts and error conditions documentation at least every six months.
Project teams document an automated or manual process for monitoring and responding to application alerts and errors.
Operations team regularly monitors and responds to application alerts and errors based on provided documentation.

re most project utilizing a change management process that’s well understood?

The organization has documented and implemented a change management process.
The development process includes steps intended to collect installation or upgrade related information.
Project teams document first-time installation and upgrade instructions.
Project teams review installation and upgrade instructions for completeness and accuracy prior to release.
Project teams communicate Installation and upgrade instructions to the operations team during for release cycle.

o project teams deliver an operational security guide with each product release?
 Project teams develop an operational security guide starting with information documented about security-related alerts and
all security
Guides include items such information needed configuration
as: security-related by users and options,
operators.
event handling procedures, installation and upgrade g
operational environment specifications, security-related assumptions about the deployment environment, etc.
Project teams work with project stakeholders to determine an appropriate level of detail for the operational security guide.
Project teams update the operational security guide with each release.

re most projects beingprocess

The audit auditedincludes
to check each release
verification for appropriate
that projects' operational
operational security
security guides areinformation?
complete, contain sufficient details, an
date.
The organization has established an exception process for legacy projects, which requires a certain level of assurance with
software's operational environment to be met within a specific time period.

code signing routinely performed on software components using a consistent process?

Code signing is used to ensure and verify the authenticity of developed code.
A code signing and key management process has been documented for the organization.
Project teams work with security auditors to determine which components warrant including within the code signing proces
List of included code components is reviewed and updated regularly.
Here>

Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes
Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes
Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes

Yes/No Interview Notes
 SAMM Assessment Scorecard: <Project Name Here> For <Interview Date Here
Instructions
Fill"Yes"
If out the
hasfollowing scorecard
been marked for a based on a
question, the "Yes"number
whole or "No"maturity
responses marked
level during
has been the interview
achieved (for example "1" or "2" rather th
"1+"
If a question has been marked "No", but assertions below that question have been marked "Yes" AND the question for the
previous maturity level has been marked "Yes", a "1+", "2+", or "3+" can be recorded

Organization: <Org Name Here>

Project: <Project Name Here>
Interview Date: <Interview Date Here>
Interviewer: <Interviewer Here>
Person Interviewed: <Person Interviewed Here>
Business Maturit 0 0 1 1 2 2 3 3
Functions Security Practices y Level _ + _ + _ + _ +
Governance Strategy & Metrics 1+ x x x x
Governance Policy & Compliance 2 x x x x x
Governance Education & Guidance 0+ x x
Construction Threat Assessment 3+ x x x x x x x x
Construction Security Requirements 0+ x x
Construction Secure Architecture 1 x x x
Verification Design Analysis 2 x x x x x
Verification Code Review 1 x x x
Verification Security Testing
Vulnerability 3 x x x x x x x
Deployment Management 2+ x x x x x x
Deployment Environment Hardening 0 x
Deployment Operational Enablement 0+ x x
re> For <Interview Date Here>

uring the interview

n achieved (for example "1" or "2" rather than
en marked "Yes" AND the question for the
rded