D487: SECURE SOFTWARE DESIGN EXAM QUESTIONS AND

ANSWERS (VERIFIED AND WELL ELABORATED ANSWERS) LATEST

UPDATE 2025/2026

Building Security In Maturity Model (BSIMM)

A study of real-world software security initiatives organized so that you can
determine where you stand with your software security initiative and how to
evolve your efforts over time
SAMM
offers a roadmap and a well-defined maturity model for secure software
development and deployment, along with useful tools for self-assessment and
planning.
Core OpenSAMM activities
Governance
Construction
Verification
Deployment
static analysis
Source code of an application is reviewed manually or with automatic tools
without running the code
dynamic analysis
Analysis and testing of a program occurs while it is being executed or run
Fuzzing
Injection of randomized data into a software program in an attempt to find
system failures, memory leaks, error handling issues, and improper input
validation
OWASP ZAP
-Open-source web application security scanner-Can be used as a proxy to
manipulate traffic running through it (even https)
ISO/IEC 27001
Specifies requirements for establishing, implementing, operating, monitoring,
reviewing, maintaining and improving a documented information security
management system
ISO/IEC 17799
ISO/EIC is a joint committee that develops and maintains standards in the IT
industry. 17799 is an international code of practice for information security
management. This section defines confidentiality, integrity and availability
controls.
ISO/IEC 27034
A standard that provides guidance to help organizations embed security
within their processes that help secure applications running in the
environment, including application lifecycle processes
Software security champion
a developer with an interest in security who helps amplify the security
message at the team level
waterfall methodology
a sequential, activity-based process in which each phase in the SDLC is
performed sequentially from planning through implementation and
maintenance
Agile Development
A software development methodology that delivers functionality in rapid
iterations, measured in weeks, requiring frequent communication,
development, testing, and delivery.
Scrum
an agile project management framework that helps teams structure and
manage their work through a set of values, principles, and practices
Daily scrum
daily time-boxed event of 15 minutes, or less, for the Development Team to re-
plan the next day of development work during a Sprint. Updates are reflected
in the Sprint Backlog.
Sprint review
A meeting that occurs after each sprint to show the product or process to
stakeholders for approval and to receive feedback.
Sprint retrospective
an opportunity for the Scrum Team to inspect itself and create a plan for
improvements to be enacted during the next Sprint.
Sprint planning
A collaborative event in Scrum in which the Scrum team plans the work for
the current sprint.
Scrum master
A person who ensures that the team is productive, facilitates the daily Scrum,
enables close cooperation across all roles and functions, and removes barriers
that prevent the team from being effective
White-box
A test where the tester has an in-depth knowledge of the network and systems
being tested, including network diagrams, IP addresses, and even the source
code of custom applications.
Gray-box
a testing technique in which the tester has limited knowledge of the internal
workings of the software.
Black-box
a testing technique in which the internal workings of the software are not
known to the tester.
Fail-safe
a design feature or practice that, in the event of a specific type of failure,
inherently responds in a way that will cause minimal or no harm to other
equipment, to the environment or to people
Privacy compliance report
provide progress against privacy requirements provided in earlier stages and
assess any changes to identify & add any new requirements
SDLC
Software Development Life Cycle. A software development process. Many
different models are available.
SDLC Phase 1
planning - a vision and next steps are created
SDLC Phase 2
requirements - necessary software requirements are determined
SDLC Phase 3
design - requirements are prepared for the technical design
SDLC Phase 4
implementation - the resources involved in the application from a known
resource are determined
SDLC Phase 5
testing - software is tested to verify its functions through a known
environment
SDLC Phase 6
deployment - security is pushed out
SDLC Phase 7
maintenance - ongoing security monitoring is implemented
SDLC Phase 8
end of life - the proper steps for removing software completely are considered
OWASP SAMM
flexible framework for building security into a software development
organization
Static Analysis
the analysis of computer software that is performed without executing
programs
Dynamic Analysis
the analysis of computer software that is performed when executing programs
on a real or virtual processor in real time
Waterfall Development
software development methodology that breaks down development activities
into linear sequential phases; each phase depends on the deliverables of the
previous one and corresponds to a specialization of tasks
Waterfall Phases (typical)
plan -> build -> test -> review -> deploy
Iterative Waterfall Development
each phase of a project is broken down into its own waterfall phases
Agile Development
software development methodology that delivers functionality in rapid
iterations called timeboxes, requiring limited planning but frequent
communication
Scrum Master (Scrum Role)
responsible for ensuring a Scrum team is operating as effectively as possible
by keeping the team on track, planning and leading meetings, and working
out any obstacles the team might face
Product Owner (Scrum Role)
ensures the Scrum team aligns with overall product goals by managing the
product backlog by ordering work by priority, setting the product vision for
the team, and communicating with external stakeholders to translate their
needs to the team
Development Team (Scrum Role)
professionals who do the hands-on work of completing the tasks in a Scrum
sprint by lending their expertise to program, design, or improve products
Lean Development
software development methodology that focuses on further isolating risk to
the level of an individual feature
V-Model
a variation of the waterfall model, where the stage is turned back upwards
after the coding phase
Extreme Programming (XP)
an Agile methodology that is intended to improve software quality and
responsiveness
Software Security Architect
ensures that the stakeholder security requirements necessary to protect the
organization's mission and business processes are adequately addressed
Software Security Champion
an expert on promoting security awareness, best practices, and simplifying
software security
Software Security Evangelist
an expert to promote awareness of products to the wider software community
Functional Requirements
describe what the system will do and its core purpose
ex: login functionality, data processing
Non-Functional Requirements
describe any constraints or restrictions on a design but do not impact the core
purpose of the system
ex: performance, security, usability
Privacy Impact Assessment
process that evaluates issues and privacy impact rating in relation to the
privacy of PII in the software
Product Risk Profile
helps to determine the actual cost of the product from different perspectives
Requirement Traceability Matrix
a table that lists all of the security requirements
DREAD model
damage, reproducibility, exploitability, affected users, discoverability
PASTA
the process for attack simulation and threat analysis; gives a software security
team a repeatable framework for identifying threats
STRIDE
classifies threats into categories: spoofing, tampering, repudiation,
information disclosed, denial of service, and elevation of privilege
Application Decomposition
determining the fundamental functions of an app
Trike
a unified conceptual framework for security auditing
Alpha Level Testing
testing done by the developers themselves
Beta Level Testing
testing done by those not familiar with the actual development of the system
Abstract Syntax Tree (AST)
the basis for software metrics and issues to be generated at a later stage
Control Flow Analysis
the mechanism used to step through logical conditions in the code
Data Flow Analysis
the mechanism used to trace data from the points of input to the points of
output
SonarQube
open-source platform for static code analysis that can detect bugs, code smells,
vulnerabilities, and hotspots in over 25 programming languages
Spider
identifies inputs and supplies those to the scanning components of the security
tool
PSIRT
Product Security Incident Response Team

the team that receives, investigates, and reports security vulnerabilities

Phase A1
Security Assessment - the project team identifies the product risks and creates
a project outline for security milestones
Phase A2
Architecture - examines security from perspective of business risks
Phase A3
Design and Development - analyze and test software to determine security and
privacy issues as you make informed decisions moving forward with your
software
Phase A4
Design and Development - build onto the proper process of security testing
and continue to analyze necessities at the security level
Phase A5
Ship - verifies that the product complies with security policies
Policy Compliance Analysis
done in A5 - final review of security and compliance requirements
Open-Source Licensing Review
done in A5 - final review of open-source software used in the stack
Final Security Review
done in A5 - final review of compliance against all security requirements
identified during the SDL cycle - passed, passed with exceptions, not passed
and requires escalation
Final Privacy Review
done in A5 - final review of compliance against all privacy requirements
identified during the SDL cycle
Customer Engagement Framework
defines the process for sharing security-related information with customers
PRSA1
External Vulnerability Disclosure Response - stakeholders are clearly
identified and a RACI matrix should be created
PRSA2
Third-Party Security Reviews - security assessment performed by groups
other than internal testing teams
PRSA3
Post-Release Certifications - certifications from external parties to
demonstrate the security posture of products or services
PRSA4 & PRSA5
Security Strategy for Legacy Code, M&A, and EOL Plans - strategy to
mitigate security risk from legacy code and M&As
Governance (OpenSAMM function)
centered on how organizations manage overall software development activities
Construction (OpenSAMM function)
centered around how organizations define goals and create software within
development projects
Verification (OpenSAMM function)
centered around how an organization checks and tests artifacts produced
through software development
Deployment (OpenSAMM function)
centered around how an organization releases software
Threat Modeling (Definition)
- systematic approach to identifying and evaluating potential threats and
vulnerabilities in software systems.
- It helps in understanding and mitigating risks associated with software
applications early in the development process.
Threat Modeling (Stages)
1. Identify Assets: Determine what needs to be protected.
2. Identify Threats: Identify potential threats to those assets.
3. Identify Vulnerabilities: Analyze weaknesses that could be exploited by
threats.
4. Assess Risks: Evaluate the likelihood and impact of identified threats
exploiting vulnerabilities.
5. Mitigate Risks: Implement countermeasures to reduce or eliminate
identified risks
PASTA Stages
- Define Objectives: Establish goals and scope of the analysis.
- Create an Application Diagram: Visualize the application and its
components.
- Identify Threat Profiles: Define potential attacker personas and their
motivations.
- Analyze Threats: Assess how attackers could exploit vulnerabilities to
achieve their objectives.
- Prioritize Threats: Rank threats based on their severity and likelihood.
- Mitigate Threats: Develop and implement countermeasures to address
identified threats.
SHIP Steps
Select: Identify and prioritize critical assets and systems for protection.
Harden: Implement security controls and measures to strengthen the security
posture.
Identify: Identify potential threats and vulnerabilities.
Protect: Implement measures to protect against identified threats and
vulnerabilities.
SDLC Phase 1
planning - a vision and next steps are created
SDLC Phase 2
requirements - necessary software requirements are determined
SDLC Phase 3
design - requirements are prepared for the technical design
SDLC Phase 4
implementation - the resources involved in the application from a known resource
are determined
SDLC Phase 5
testing - software is tested to verify its functions through a known environment
SDLC Phase 6
deployment - security is pushed out
SDLC Phase 7
maintenance - ongoing security monitoring is implemented
SDLC Phase 8
end of life - the proper steps for removing software completely are considered
BSIMM
a study of real-world software security that allows you to develop your software
security over time
OWASP SAMM
flexible framework for building security into a software development organization
Static Analysis
the analysis of computer software that is performed without executing programs
Dynamic Analysis
the analysis of computer software that is performed when executing programs on a
real or virtual processor in real time
Fuzz Testing
automated or semi-automated testing that provides invalid, unexpected, or random
data to the computer software program
Waterfall Development
software development methodology that breaks down development activities into
linear sequential phases; each phase depends on the deliverables of the previous
one and corresponds to a specialization of tasks
Waterfall Phases (typical)
plan -> build -> test -> review -> deploy
Iterative Waterfall Development
each phase of a project is broken down into its own waterfall phases
Agile Development
software development methodology that delivers functionality in rapid iterations
called timeboxes, requiring limited planning but frequent communication
Scrum
framework for Agile that prescribes for teams to break work into goals to be
completed within sprints
Scrum Master (Scrum Role)
responsible for ensuring a Scrum team is operating as effectively as possible by
keeping the team on track, planning and leading meetings, and working out any
obstacles the team might face
Product Owner (Scrum Role)
ensures the Scrum team aligns with overall product goals by managing the product
backlog by ordering work by priority, setting the product vision for the team, and
communicating with external stakeholders to translate their needs to the team
Development Team (Scrum Role)
professionals who do the hands-on work of completing the tasks in a Scrum sprint
by lending their expertise to program, design, or improve products
Lean Development
software development methodology that focuses on further isolating risk to the
level of an individual feature
V-Model
a variation of the waterfall model, where the stage is turned back upwards after the
coding phase
Extreme Programming (XP)
an Agile methodology that is intended to improve software quality and
responsiveness
Software Security Architect
ensures that the stakeholder security requirements necessary to protect the
organization's mission and business processes are adequately addressed
Software Security Champion
an expert on promoting security awareness, best practices, and simplifying
software security
Software Security Evangelist
an expert to promote awareness of products to the wider software community
Functional Requirements
describe what the system will do and its core purpose
Non-Functional Requirements
describe any constraints or restrictions on a design but do not impact the core
purpose of the system
Privacy Impact Assessment
process that evaluates issues and privacy impact rating in relation to the privacy of
PII in the software
Product Risk Profile
helps to determine the actual cost of the product from different perspectives
Requirement Traceability Matrix
a table that lists all of the security requirements
DREAD model
damage, reproducibility, exploitability, affected users, discoverability
PASTA
the process for attack simulation and threat analysis; gives a software security team
a repeatable framework for identifying threats
STRIDE
classifies threats into categories: spoofing, tampering, repudiation, information
disclosed, denial of service, and elevation of privilege
Application Decomposition
determining the fundamental functions of an app
Trike
a unified conceptual framework for security auditing
Alpha Level Testing
testing done by the developers themselves
Beta Level Testing
testing done by those not familiar with the actual development of the system
Black Box Testing
tests from an external perspective with no prior knowledge of the software
Gray Box Testing
analyzes the source code for the software to help design the test cases
White Box Testing
tests from an internal perspective with full knowledge of the software
Abstract Syntax Tree (AST)
the basis for software metrics and issues to be generated at a later stage
Control Flow Analysis
the mechanism used to step through logical conditions in the code
Data Flow Analysis
the mechanism used to trace data from the points of input to the points of output
SonarQube
open-source platform for static code analysis that can detect bugs, code smells,
vulnerabilities, and hotspots in over 25 programming languages
Spider
identifies inputs and supplies those to the scanning components of the security tool
PSIRT
the team that receives, investigates, and reports security vulnerabilities
Phase A1
Security Assessment - the project team identifies the product risks and creates a
project outline for security milestones
Phase A2
Architecture - examines security from perspective of business risks
Phase A3
Design and Development - analyze and test software to determine security and
privacy issues as you make informed decisions moving forward with your software
Phase A4
Design and Development - build onto the proper process of security testing and
continue to analyze necessities at the security level
Phase A5
Ship - verifies that the product complies with security policies
Policy Compliance Analysis
done in A5 - final review of security and compliance requirements
Open-Source Licensing Review
done in A5 - final review of open-source software used in the stack
Final Security Review
done in A5 - final review of compliance against all security requirements identified
during the SDL cycle - passed, passed with exceptions, not passed and requires
escalation
Final Privacy Review
done in A5 - final review of compliance against all privacy requirements identified
during the SDL cycle
Customer Engagement Framework
defines the process for sharing security-related information with customers
PRSA1
External Vulnerability Disclosure Response - stakeholders are clearly identified
and a RACI matrix should be created
PRSA2
Third-Party Security Reviews - security assessment performed by groups other
than internal testing teams
PRSA3
Post-Release Certifications - certifications from external parties to demonstrate the
security posture of products or services
PRSA4 & PRSA5
Security Strategy for Legacy Code, M&A, and EOL Plans - strategy to mitigate
security risk from legacy code and M&As
Governance (OpenSAMM function)
centered on how organizations manage overall software development activities
Construction (OpenSAMM function)
centered around how organizations define goals and create software within
development projects
Verification (OpenSAMM function)
centered around how an organization checks and tests artifacts produced through
software development
Deployment (OpenSAMM function)
centered around how an organization releases software
BSIMM Categories
governance, intelligence, software security development life cycle touchpoints, and
deployment