D487 - SECURE SOFTWARE DESIGN ACTUAL EXAM QUESTIONS AND ANSWERS (VERIFIED AND

WELL ELABORATED ANSWERS) LATEST UPDATE 2025/2026

Software Development Life Cycle (SDLC)

A structured process that enables the production of software

What are the 8 phases of the Software Development Lifecycle (SDLC)?

planning
requirements
design
implementation
testing
deployment
maintenance
end of life

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

Security Development Life Cycle (SDL)

A process that standardizes security best practices

Secure Code

A principle design in coding that refers to code security best practices, safeguards, and
protection against vulnerabilities

Threat Modeling

A structured process to protect against vulnerabilities

process to pinpoint security threats and potential vulnerabilities that will help prioritize
remediation

Application Security

developing, adding, and testing security features to prevent vulnerabilities within applications

Building Security in Maturing Model (BSIMM)

a study of real-world software security that allows you to develop your software security over
time

OWASP Software Assurance Maturity Model (SAMM)

flexible framework for building security into a software development organization

Open Web Application Security Project (OWASP)

A flexible and prospective framework to build security into your software development
organization for web applications

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

National Institute of Standards and Technology (NIST)

provides research, information, and tools for government and corporate information security

Measurement Model

A set of data security methods that developers take to protect against vulnerabilities

Metric Model

Allows an organization to determine the effectiveness of its security controls

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. Mizes traditional and
new software development practices.

Scrum

framework for Agile that prescribes for teams to break work into goals to be completed
within sprints

flexible, holistic product development strategy where a development team works as a unit to
reach a common goal

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 (SSA)

ensures that the stakeholder security requirements necessary to protect the organization's
mission and business processes are adequately addressed

Software Security Champion (SSC)

an expert on promoting security awareness, best practices, and simplifying software security

Software Security Evangelist (SSE)

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

Threat Profile

environment in which the product will operate and potential threats in that environment

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

Spoofing

illegally accessing and using another user's credentials

Tampering

maliciously changing or modifying persistent data

Denial of Service

Denying access to valid users

Elevation of Privilege

privileged access to resources for gaining unauthorized access to information

Information Disclosure

Read a file that one was not granted access too

Repudiation

performing illegal operations in a system that lacks the ability to trace the prohibited operations

Software Security Policy

defines what needs to be protected and how it will be protected

Risk Model

assess vulnerabilities during the software development process

Third Party Codes

reusable software developed externally from the organization's platforms

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

Data Flow Diagrams

a visual representation of the threat flow

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

What are the 5 phases of the Security Development Life Cycle (SDL)?

A1 - Security Assessment
A2 - Architecture
A3 - Design and Development
A4 - Design and Development
A5 - Ship

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

Application-Centric Threat Modeling

threat models that start with visualizing the application you are building

Asset-Centric Threat Modeling

threat models focused around senior management and protecting the assets of an organization

Threat Source

entity carrying out the attack

Threat Vector

the path an attacker can take to exploit a vulnerability

Trike

A unified conceptual framework for security auditing

Vulnerability

A weakness that can be exploited

External Resources

resources hired on a temporary basis to come into a project, test the application, and report
findings
Functional Testing Scripts

step-by-step instructions for a specific scenario or situation

Internal Resources

resources from the company's organization

Secure Testing Scripts

scripts created specifically for the application being tested

Scripts

Detailed, logical steps of instructions to tell a person or tool what to do during the testing

System Test

test the system and its interaction with other systems

Vulnerability Assessments

examining a product to identify security deficiencies

Active Scanner

modifies the HTTPS inputs and analyzes the response to identify vulnerabilities

AppSec

the process of finding, fixing, and preventing security vulnerabilities at the application level

Benchmarks

tests used to compare estimates to actual results

Code Review

a process done to identify security vulnerabilities during software development and

Documentation

details and guides that are necessary to support hte ongoing use of the software

Exploratory Tests

done by the dev tester to continually assess the quality of his or her work

Open Source Security Testing Methodology Manual (OSSTMM)

a manual that provides templates and standards used when developing a test strategy
OWASP Zed Attack Proxy

an open-source security tool used widely by software security developers

Passive Scanner

silently analyzes all the http requests and responses passing through the web application
security tool

Pull Request

a request to merge your code into another branch

Scheduled Test

mandatory requirements testing to validate the security of the software and associated systems

Zed Attack Proxy (ZAP)

free, open-source penetration testing tool

Authenticated Scans

scans that require software to log onto a system to scan it

External Scans

scans that target security issues that are found outside the firewall

Internal Scans

scans to identify security issues that a malicious attacker could exploit from inside the network

Intrusive Target Search

scans to exploit a vulnerability when it is identified

NMAP

a tool used for network scanning and security auditing

Open-Source Software License Compliance

regulations regarding the software licensing of in-house products

Open-Source Software Security

identifying software security within in-house developed software

Penetration Testing
an authorized attack of an application to determine its weaknesses

Range

a networking laboratory created to conduct vulnerability analysis testing

SQL Injection

a code injection that might destroy your software

Target Machine

a virtual space to practice identifying attack surfaces of the machine

Virtualization

technology used to create software services

Vulnerability Scan

explore application and databases to attempt to identify weaknesses

Vulnerability Sites

websites with information on the latest known vulnerabilities

Common Vulnerability Scoring System (CVSS)

a model used to assess the severity of a vulnerability

Legacy Code

old code that is no longer supported

Merger and Acquisition (M&A)

when companies consolidate

Product Security Incident Response Team (PSIRT)

the team that receives, investigates, and reports security vulnerabilities

Post-Release Support Phase

the phase of the SDLC in which organizations prepare for vulnerabilities after the product has
been released

Post-Release PSIRT Response

responds to software product security incidents that involve the external discovery of post-
release software vulnerabilities
Digital Enterprise

technology used to enable and improve business activities

Design Review (DR)

a practice of verification involving inspecting artifacts that were created from the design process

Education and Guidance (EG)

a practice of governance involving increasing security knowledge among software developers

Environment Hardening (EH)

a practice of deployment involving implementing controls for the operating environment of an

organization's software

Operational Enablement (OE)

a practice of deployment involving identifying and capturing security-relevant information

Policy and Compliance (PC)

a practice of governance involving setting up security and compliance control

Security Architecture (SA)

a practice of construction involving activities to prompt secure-by-default designs during the

design process

Security Requirements (SR)

a practice of construction involving the promoting of inclusion security requirements during

software development

Security Testing (ST)

a practice of verification involving testing the organization's software in its environment

Strategy and Metrics (SM)

a practice of governance involving the strategies regarding software assurance and processes to
collect metrics on an organization's security

Threat Assessment (TA)

a practice of construction involving identifying and characterizing potential threats

Vulnerability Management (VM)

a practice of deployment involving establishing processes for managing internal and external
vulnerability reports

Secure Code Best Practices

Communication Security
system configuration
session management
access control
output encoding
database security
memory management
file management
session management
input validation
cryptographic practices
authentication and password management
data protection

Secure Code: Communication Security

vital in writing secure code, especially for applications that transmit sensitive data over
networks. ensures confidentiality, integrity, and authenticity of data exchanged between
systems, protecting it from eavesdropping, tampering, and unauthorized access.

Secure Code: System configuration

involves setting up and configuring the underlying operating system and environment where the
software will run. helps mitigate security risks, reduce attack surfaces, and protect against
vulnerabilities.

Secure Code: Output encoding

prevent cross-site scripting (XSS) attacks. XSS attacks occur when an attacker injects malicious
scripts into web pages, which are then executed in the context of other users' browsers, leading
to data theft, session hijacking, and other security breaches.

Secure Code: Access control

helps enforce restrictions on who can access what resources within an application or system.
prevent unauthorized users from accessing sensitive data, performing privileged actions, or
modifying critical functionality.

Secure Code: Memory Mangement

helps prevent memory-related vulnerabilities such as buffer overflows, use-after-free errors,
and memory leaks, which can lead to security vulnerabilities and software exploits.

Secure Code: Database Security

helps protect sensitive information that must be protected from unauthorized access,
disclosure, and manipulation

Secure Code: File Management

ensure the confidentiality, integrity, and availability of files stored and processed by an
application.

Secure Code: Session Management

involves handling user sessions securely to prevent unauthorized access and protect sensitive
data.

Secure Code: Input Validation

helps prevent various types of attacks such as injection, cross-site scripting (XSS), and command
injection by ensuring that data provided by users or external sources is safe and conforms to
expected formats

Secure Code: Cryptographic practices

help protect sensitive data by ensuring confidentiality, integrity, and authenticity.

Secure Code: Authentication and Password Management

help verify the identity of users and protect sensitive data from unauthorized access.

Secure Code: Data Protection

involves safeguarding sensitive information from unauthorized access, disclosure, or

modification

Secure Software Best Practices

Architecture analysis
training
penetration testing
code review

Secure Software: Architecture Analysis

involves assessing the design and structure of a software system to identify potential security
risks and vulnerabilities.

Secure Software: Training

crucial in building secure software by equipping developers, engineers, and other stakeholders
with the knowledge and skills necessary to understand and address security threats effectively.

Secure Software: Code Review

aimed at identifying and mitigating security vulnerabilities and weaknesses in source code.

Secure Software: Penetration Testing

aimed at identifying and mitigating security vulnerabilities in software applications before they
are deployed into production environments

Privacy Impact Statement Requirements

Privacy control
Data integrity
Access
Education of stakeholders

Privacy Impact Statement: Privacy control

involves detailing the measures and safeguards implemented to protect the privacy of
individuals' personal data. Here's how you can cover privacy controls in a PIS

Privacy Impact Statement: Data integrity

Involves outlining measures taken to ensure that personal data is accurate, reliable, and
protected against unauthorizes alteration or corruption.

Privacy Impact Statement: Education of stakeholders

crucial to communicate clearly and effectively about the potential privacy implications of a
project or initiative.

Privacy Impact Statement: Access

involves detailing how stakeholders can access the document and providing mechanisms for
them to request further information or clarification.

What security testing technique does sonarqube use?

Source-code analysis
Design and development deliverables

updated threat modeling artifacts

privacy implementation assessment results
security test plans
design security review

Design and development: Privacy implementation

refers to the integration of privacy considerations and measures in the design, development,
and deployment of software applications.

Design and development: assessment results

refer to the findings and outcomes of evaluation conducted to assess the security posture of a
software application during its design and development phases.

Design and development: design security review

security of the system's design is evaluated to identify and mitigate potential security risks and
vulnerabilities before implementation begins

Design and development: security test plans

outlines the strategy and approach for evaluating the security of a software application during
the design and development phases.

Design and development: Updated Threat Modeling Artifacts

contains technical and executive level reports detailing any newly identified vulnerabilities

What is C++ vulnerable to

Highly susceptible to buffer overflow vulnerabilities

What is C# vulnerable to

Highly susceptibly to XSS1

What is Javascript vulnerable to

Highly susceptibly to XSS2

What is Java vulnerable to

Highly susceptibly to SQL injection

BSIMM Domains
Software Security Development Life Cycle (SSDL) touchpoints
Intelligence
Governance
Deployment

BSIMM: Software security development life cycle (SSDL) touchpoints

represent key stages or activities within the software development process where security
measures are integrates. Help organizations identify where security practices should be applied
throughout the software development lifecycle.

BSIMM: Intelligence

Refers to the maturity level of processes and practices related to gathering, analyzing, and
leveraging security intelligence within an organizations software security initiatives.

BSIMM: Governance

Refers to the maturity level of the processes and practices related to overseeing and managing
software security initiatives within an organization.

BSIMM: Deployment

Assesses the maturity of processes and procedures related to deploying software into
production environments. This includes activities such as packaging, versioning, and distributing
software releases

Requirement types

Bucket
One-time
every-sprint
final security review

Bucket Requirements

refers to a high-level or overarching requirement that encompasses several related

functionalities or features within a specific area or domain of the software. It holds together a
group of related requirements, often serving as a container or category for organizing and
managing them.

One-Time Requirements

These tasks are essential for setting up the project, establishing foundation elements, or
achieving specific objectives.
Every-Sprint Requirements

tasks or activities that need to be performed in each sprint of an agile development process.
Ensure a consistent approach to software development and help maintain project momentum.
Teams can maintain a steady pace of development, respond quickly to changes, and deliver
high-quality software iteratively

Final Security Review Requirements

Ensure that the software meets specified security standards and safe guards against potential
vulnerabilities. They aim to ensure that the software is resilient against security threats and
provides users with a secure computing environment.