2. Secure Software Development Lifecycle and Threat Modeling

Introduction and Context

Security in a DevOps environment cannot be added reliably at the end of development. By the time an application reaches penetration testing, many important decisions—such as its trust boundaries, data flows, authentication model, cloud architecture, and third-party dependencies—have already been made. Correcting a design weakness at that stage is usually more expensive and disruptive than addressing it when requirements and architecture are still being shaped.

DevSecOps therefore extends the secure software development lifecycle (SSDLC) across the entire delivery system. Security becomes a shared engineering responsibility supported by governance, automation, threat intelligence, and informed professional judgement. This does not mean that every developer becomes a security specialist. It means that security requirements, privacy obligations, abuse cases, design risks, implementation controls, and operational safeguards are incorporated into normal product and platform work.

Threat modeling is central to this approach. It provides a structured way to ask what can go wrong, who may cause harm, which assets are at risk, how attacks might progress, and which controls reduce the risk. A useful threat model is not merely a diagram or a compliance document. It is a decision-making instrument that connects business objectives, system architecture, security engineering, and delivery priorities.

This chapter examines how security can be integrated into agile delivery, with particular attention to security requirements, abuse cases, data classification, privacy, architecture review, STRIDE, attack trees, and MITRE ATT&CK-informed analysis.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the purpose and characteristics of a secure software development lifecycle.

2. Translate business, security, privacy, and regulatory concerns into actionable requirements.

3. Distinguish misuse cases, abuse cases, security requirements, and security controls.

4. Classify information and use classification to guide architectural and operational decisions.

5. Conduct a practical threat-modeling exercise using data-flow diagrams and STRIDE.

6. Construct attack trees and relate threat scenarios to MITRE ATT&CK techniques.

7. Integrate threat modeling and architecture review into agile and DevOps workflows.

8. Evaluate limitations, governance issues, ethical concerns, and emerging practices in secure delivery.

Security as a Lifecycle Property

A conventional development lifecycle often treats security as a specialist review near release. An SSDLC distributes security activities throughout the lifecycle. The precise stages differ among organizations, but a useful model includes discovery and planning, requirements, design, implementation, verification, release, operation, and retirement.

During discovery, the team identifies business objectives, users, assets, legal obligations, and acceptable risk. During requirements analysis, security and privacy requirements are expressed in testable language. During design, architectural choices, trust boundaries, identity flows, data storage, external dependencies, and failure modes are examined. During implementation, developers use secure coding practices, approved libraries, secret-management mechanisms, and peer review. During verification, automated tests, static analysis, dependency analysis, dynamic testing, configuration checks, and targeted manual assessment provide evidence that controls work. Operations adds monitoring, incident response, patching, vulnerability management, and recovery. Retirement includes data disposal, credential revocation, decommissioning of infrastructure, and preservation of required records.

The lifecycle is not strictly sequential. DevOps uses short feedback loops, so security work is refined continuously. A new integration may create a new trust boundary; a change in data use may alter privacy obligations; a vulnerability in a dependency may require architectural decisions rather than a simple patch. Security activities must therefore be repeatable, risk-based, and connected to version control, issue tracking, continuous integration, and deployment processes.

A mature SSDLC has three characteristics. First, security responsibilities are explicit: product owners, architects, developers, security engineers, operations personnel, and suppliers understand their roles. Second, security work is traceable: requirements are linked to designs, code changes, tests, findings, and residual risks. Third, security decisions are proportionate: high-risk systems receive deeper analysis and stronger controls than low-impact internal tools.

From Business Objectives to Security Requirements

A security requirement states a condition that the system must satisfy to protect assets, users, or organizational interests. It should be sufficiently precise to guide design and verification. “The system must be secure” is not testable. “Administrative actions shall require phishing-resistant multifactor authentication and shall be recorded with user identity, timestamp, target resource, and outcome” is substantially more useful.

Security requirements originate from several sources:

• business risks and continuity objectives;
• threat and abuse analysis;
• privacy principles and data-protection obligations;
• contractual and industry requirements;
• organizational policies and standards;
• architectural constraints; and
• lessons from incidents and vulnerabilities.

Requirements can address confidentiality, integrity, availability, authenticity, accountability, privacy, resilience, and recoverability. They may be functional, such as requiring authorization before a payment is approved, or non-functional, such as requiring a defined recovery-time objective. They may also constrain implementation, for example by requiring secrets to be retrieved from an approved secret-management service rather than stored in source code or deployment files.

A useful requirement has an owner, a rationale, an acceptance criterion, and a method of verification. Traceability is especially important in regulated environments: auditors and engineering leaders should be able to determine why a control exists and whether it remains effective.

Abuse Cases and Misuse Cases

A user story describes a desirable capability. An abuse case describes how a malicious or negligent actor could use the system to cause harm. A misuse case focuses on unintended or improper use, while an abuse case usually emphasizes deliberate harmful behavior. For example, a normal story may state, “As an account holder, I can reset my password.” An abuse case may state, “An attacker repeatedly submits reset requests to take over another user’s account.”

Abuse cases improve requirements because they expose assumptions hidden in ordinary functional stories. They can lead to controls such as rate limiting, notification of password changes, verification of recovery factors, fraud detection, and session invalidation. In agile teams, abuse cases may be written as security stories, acceptance criteria, or threat scenarios linked to backlog items.

A security story should not be vague. It should identify the actor, target, harmful objective, relevant preconditions, and expected control. For example: “As the security team, we need failed administrator login attempts to be rate-limited and alerted so that credential-stuffing attacks are detected and constrained.”

Data Classification, Privacy, and Trust Boundaries

Threat modeling is strongly influenced by the value and sensitivity of data. Data classification assigns information to categories that determine handling requirements. Typical categories include public, internal, confidential, and restricted or highly sensitive. The labels themselves vary by organization; what matters is that each category has defined controls for access, storage, transmission, retention, logging, backup, sharing, and disposal.

Classification should consider more than secrecy. Integrity-sensitive data, such as configuration or financial records, may require strong change control even if it is not confidential. Availability-critical data may need replication and recovery controls. Personal data may create obligations concerning purpose limitation, transparency, retention, access rights, minimization, and breach response.

Privacy engineering examines how a system affects identifiable individuals. Important questions include:

• What personal or sensitive data is collected?
• Why is it needed, and is collection proportionate?
• Where is it stored and processed?
• Who can access it, including suppliers and administrators?
• How long is it retained?
• Can individuals exercise applicable rights?
• Is the data used for a new purpose or combined with other datasets?

Privacy impact assessments and data-protection impact assessments may be required for high-risk processing. They should not be treated as paperwork separate from architecture. Data-flow diagrams, retention mechanisms, consent or notice flows, pseudonymization, encryption, access controls, and deletion processes are architectural matters.

Trust boundaries identify points at which data or control moves between different security domains. Examples include a browser-to-API boundary, an application-to-database boundary, a cloud account boundary, a tenant boundary, and a connection to a supplier. A threat model becomes more useful when it explicitly shows these boundaries and identifies assumptions about authentication, validation, encryption, and authorization at each crossing.

Architecture Review Before Implementation

Architecture review is a risk-based examination of whether a proposed design can meet its security and privacy requirements. It is not simply approval by a security department. The review should include the people who understand business use, system behavior, operational constraints, and likely attack paths.

A practical review examines components, data flows, identities, privileges, trust boundaries, dependencies, administrative interfaces, failure modes, and recovery mechanisms. It asks questions such as:

• Which assets require protection, and what would be the impact of compromise?
• Which components are internet-facing or reachable from less trusted networks?
• Where are authentication and authorization decisions made?
• Can a lower-trust component invoke privileged functionality?
• What happens when identity, logging, a dependency, or a regional service fails?
• How are secrets, keys, and certificates created, rotated, and revoked?
• Does the design support tenant isolation and least privilege?
• Can security events be detected and investigated?

Architecture review should produce decisions, not only observations. A decision may be to redesign a service boundary, introduce an authorization service, isolate a database, reduce data collection, add compensating monitoring, or accept a documented residual risk. Threat models should be versioned with architecture artifacts because changing a component or data flow can invalidate earlier conclusions.

A Practical Threat-Modeling Method

Threat modeling is a structured process for identifying and treating threats. It is not prediction of every possible attack. Its purpose is to make important assumptions visible and enable rational prioritization.

A practical workflow is as follows:

1. Define scope and objectives. Identify the system, business process, environment, users, and decisions the model must support.

2. Identify assets. Include data, credentials, transactions, services, infrastructure, intellectual property, and safety-relevant functions.

3. Represent the system. Use a context diagram, data-flow diagram, sequence diagram, deployment view, or cloud architecture diagram.

4. Mark trust boundaries and entry points. Record external interfaces, privileged operations, administrative paths, and third-party connections.

5. Identify threats. Apply a framework such as STRIDE, construct attack trees, and consider attacker behavior using MITRE ATT&CK.

6. Assess risk. Consider likelihood, impact, exploitability, exposure, detectability, and existing controls.

7. Select treatments. Eliminate, reduce, transfer, accept, or monitor the risk. Treatments should become backlog items or design decisions.

8. Validate and maintain. Revisit the model when architecture, data use, dependencies, threats, or operational conditions change.

Threat modeling is most effective when performed early and collaboratively. A workshop may include a product owner, developer, architect, security practitioner, privacy specialist, and operations representative. Lightweight models can be created for ordinary changes, while high-impact systems may require formal analysis, multiple scenarios, and independent review.

STRIDE

STRIDE is a mnemonic for six categories of threats:

• Spoofing: pretending to be another user, service, device, or process.
• Tampering: unauthorized modification of data, code, configuration, or messages.
• Repudiation: denying an action where reliable evidence is required.
• Information disclosure: exposing data to unauthorized parties.
• Denial of service: reducing availability or preventing legitimate use.
• Elevation of privilege: obtaining capabilities beyond those authorized.

STRIDE is commonly applied to elements in a data-flow diagram. A login token crossing a boundary may raise spoofing and tampering concerns. A transaction database may raise tampering, information disclosure, and repudiation concerns. An internet-facing endpoint may raise denial-of-service concerns. STRIDE is a coverage aid rather than a complete risk assessment. It does not automatically establish likelihood, business impact, or the appropriate control.

Attack Trees

An attack tree represents an attacker’s objective as a root node and decomposes it into sub-goals. Logical relationships help show whether all conditions are needed or whether alternative paths are sufficient. For example, the goal “obtain unauthorized access to a customer account” might be achieved through credential theft, recovery-process abuse, session theft, or exploitation of an authorization flaw. Credential theft might further decompose into phishing, malware, password reuse, or a compromised supplier.

Attack trees are valuable for comparing controls and identifying single points of failure. If several branches lead to the same outcome, addressing only one branch may provide limited protection. Trees can also support qualitative or quantitative analysis, although numerical estimates should not create false precision. Their main value is exposing attack logic and control dependencies.

MITRE ATT&CK-Informed Analysis

MITRE ATT&CK is a knowledge base describing adversary tactics and techniques observed in real-world operations. It organizes activity according to objectives such as initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact.

ATT&CK-informed threat modeling adds an operational perspective to design analysis. Instead of asking only whether an endpoint can be exploited, the team asks what an attacker might do after gaining access, how credentials could be obtained, how lateral movement might occur, which telemetry would reveal the behavior, and whether controls interrupt the attack chain. ATT&CK mappings should be treated as analytical aids, not proof that a particular adversary will use a technique.

For example, a compromised build runner may provide an avenue for credential access, execution, persistence, and lateral movement into deployment environments. Controls may include workload identity, short-lived credentials, network segmentation, hardened runners, artifact signing, approval gates, and monitoring of unusual deployment behavior.

Integrating Security into Agile and DevOps Delivery

Security integration is most effective when it follows the team’s existing flow of work. During backlog refinement, teams identify abuse cases, security acceptance criteria, data classifications, and dependencies. During sprint planning, security work is estimated and prioritized rather than hidden as an unfunded obligation. During design, a threat-modeling checkpoint is triggered by meaningful architectural change. During coding, secure coding guidance, pre-commit checks, code review, secret scanning, and dependency analysis provide rapid feedback. During continuous integration, tests validate security properties. During deployment, infrastructure policy checks, image verification, configuration validation, and controlled promotion reduce release risk.

Automation is useful when it is deterministic, explainable, and connected to remediation. Static analysis can identify certain coding patterns; software composition analysis can identify vulnerable or poorly governed dependencies; infrastructure-as-code scanning can detect unsafe configurations; dynamic tests can probe running services; and secret scanning can prevent accidental exposure. None of these tools replaces threat modeling or expert review. Tools have false positives, false negatives, and limited understanding of business context.

Security gates should be risk-based. Blocking every build for every low-confidence finding creates alert fatigue and encourages bypasses. A better approach defines severity thresholds, exploitability considerations, compensating controls, exception expiry, and ownership. High-risk findings should block release or require explicit risk acceptance; lower-risk findings may generate tracked remediation work.

Illustrative Case Study: Secure Multi-Tenant Document Processing Service

Background

The fictional company Northstar Documents is developing a cloud service that allows organizations to upload documents, extract text, classify content, and share results with approved users. The service uses browser clients, an API gateway, containerized processing workers, object storage, a relational database, and an external machine-learning service.

Situation and Problem

The product team initially focused on rapid delivery. A preliminary review identified several concerns: uploaded documents may contain confidential information; tenants must not access one another’s files; processing workers require access to storage; administrators need operational access; and the external machine-learning service may process document content. The team had not yet defined retention, tenant isolation, administrative logging, or the response to malicious documents.

Analysis

The team first classified documents as confidential and certain customer categories as restricted. A data-flow diagram showed trust boundaries between browsers, the public API, internal services, storage, the processing workers, and the external provider. STRIDE analysis identified spoofing and elevation-of-privilege risks in tenant authorization, tampering risks in processing jobs, information disclosure risks in storage and external processing, repudiation risks for sharing actions, and denial-of-service risks from oversized or deliberately complex files.

An attack tree was created for the objective “access another tenant’s document.” Alternative branches included exploiting an object-storage key, manipulating a tenant identifier, abusing an administrator account, compromising a worker, and exploiting a sharing link. ATT&CK-informed analysis considered credential access, execution through malicious files, persistence in a worker environment, and exfiltration through an external service.

Privacy analysis identified purpose limitation, retention, deletion, customer notice, supplier processing, and regional processing questions. The team concluded that sending all documents to the external provider was not acceptable for every customer category.

Approach and Solution

The revised design introduced the following measures:

• authorization decisions based on server-side tenant context rather than client-supplied identifiers;
• short-lived workload identities for processing workers;
• separate storage prefixes and policy controls with explicit tenant conditions;
• encryption in transit and at rest, with managed key rotation;
• malware scanning, file-type validation, size limits, and isolated processing;
• signed internal job messages and idempotent processing;
• immutable audit records for sharing, administrative access, and deletion;
• configurable retention and verified deletion workflows;
• contractual and technical controls for the external provider, with restricted data excluded where required;
• rate limits, quotas, queue controls, and monitoring for resource exhaustion; and
• threat-model updates required for new integrations or changes to data handling.

Security acceptance criteria were added to the backlog. The deployment pipeline also required infrastructure policy checks, container image scanning, secret detection, and approval for production changes affecting tenant isolation.

Outcome

The exercise changed the architecture before implementation was complete. It reduced reliance on client-side controls, made privacy decisions visible, and identified operational telemetry required for incident response. The organization did not claim that the design was risk-free. Instead, it documented residual risks, assigned owners, and established review triggers for new suppliers, data types, and privileged capabilities.

Learning Points

The case demonstrates that threat modeling is most valuable before design decisions become expensive to change. It also shows why confidentiality alone is insufficient: tenant integrity, availability, accountability, privacy, and operational response must be considered together. Finally, a threat model is effective only when its conclusions become requirements, tests, monitoring, and governance decisions.

Challenges, Limitations, and Common Mistakes

Threat modeling can fail when it is treated as a one-time workshop. Systems evolve through feature changes, cloud configuration, dependency updates, and operational workarounds. Models must therefore have owners and review triggers.

Another common mistake is excessive abstraction. A diagram containing only “the cloud” and “the application” hides important trust boundaries and privileges. Conversely, an excessively detailed model may become unmaintainable. The appropriate level of detail is the level needed to make security decisions.

Teams may also confuse vulnerability scanning with threat modeling. A scanner can find a known weakness, but it may not understand a business abuse case, an authorization assumption, or the impact of data aggregation. Similarly, a threat catalog can produce long lists that obscure the most consequential risks. Prioritization is essential.

Other risks include incomplete stakeholder participation, weak asset classification, unverified assumptions about third-party providers, poor treatment of residual risk, and security controls that are specified but not tested. Threat models can also encode bias if they consider only sophisticated external attackers and ignore insiders, suppliers, automation failures, accidental disclosure, or vulnerable users.

Governance, Ethics, and Professional Responsibility

Security decisions affect customers, employees, suppliers, and the public. Engineers must avoid collecting excessive data merely because it is technically convenient. Monitoring should be proportionate, access should be justified, and security controls should not create unnecessary discrimination or exclusion. Automated detection may generate false positives and should support appropriate review and appeal where individual consequences are significant.

Governance requires clear ownership of risk acceptance, exception management, evidence retention, supplier assurance, incident escalation, and regulatory reporting. A risk acceptance decision should state the risk, rationale, compensating controls, owner, expiry or review date, and conditions under which it is no longer acceptable.

Professional responsibility also includes candor. Security documentation should not imply that a model proves safety. It should communicate uncertainty, assumptions, known gaps, and residual risk in language that decision-makers can understand.

Current Developments and Best Practices

Contemporary DevSecOps programs increasingly combine software supply-chain security, cloud-native identity, policy as code, provenance, artifact signing, and continuous authorization analysis. Infrastructure and application configurations are treated as code, making review and automated testing possible. Ephemeral environments can support safe testing, while workload identity reduces dependence on long-lived credentials.

Artificial intelligence is being used to summarize findings, suggest threat scenarios, analyze code, and correlate telemetry. These applications can improve analyst productivity, but generated recommendations require validation. AI systems may misunderstand architecture, reproduce insecure patterns, expose sensitive code to an external service, or create a false impression of completeness. Organizations should define data-handling rules, human review requirements, evaluation criteria, and accountability for AI-assisted decisions.

Useful practices include:

• begin threat modeling with high-impact assets and trust boundaries;
• express security and privacy requirements as testable acceptance criteria;
• maintain an architecture and data-flow view alongside code;
• use STRIDE for structured coverage and attack trees for attack logic;
• use ATT&CK to examine post-compromise behavior and detection;
• link findings to owners, deadlines, controls, and verification evidence;
• automate repeatable checks without treating tools as infallible;
• rehearse incident response and recovery assumptions; and
• review threat models whenever data use, privilege, dependencies, or deployment topology changes.

Chapter Summary

A secure software development lifecycle integrates security and privacy from planning through retirement rather than postponing them until release. Effective security requirements are specific, owned, traceable, and testable. Abuse cases reveal harmful uses that ordinary user stories may conceal, while data classification and privacy analysis clarify the controls required for different information and processing activities.

Architecture review connects business risk to components, data flows, trust boundaries, identities, privileges, dependencies, and operational safeguards. Threat modeling provides a repeatable method for identifying and treating threats. STRIDE supports systematic coverage of spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Attack trees expose alternative paths to an attacker objective, and MITRE ATT&CK-informed analysis extends the view from initial compromise to persistence, lateral movement, exfiltration, and impact.

In DevOps, these practices should be integrated with backlog refinement, design review, source control, continuous integration, deployment controls, monitoring, and incident response. Automation improves consistency but does not replace context, professional judgement, or governance. The central principle is that security is a lifecycle property maintained through informed decisions, evidence, and continuous adaptation.

Key Terms

Security requirement: A testable condition intended to protect a system, asset, user, or organizational interest.

Secure software development lifecycle: A lifecycle that incorporates security and privacy activities throughout planning, design, implementation, verification, operation, and retirement.

Abuse case: A scenario describing how an actor may deliberately misuse a system to cause harm.

Misuse case: A scenario describing unintended or improper use of a system, whether malicious or accidental.

Data classification: The assignment of information to categories that determine its handling and protection requirements.

Privacy engineering: The practice of incorporating privacy protections and responsible data use into system design and operation.

Trust boundary: A point where data, control, or privilege crosses between security domains with different levels of trust.

Architecture review: A structured examination of a system design against security, privacy, operational, and business requirements.

Threat model: A structured representation of assets, actors, attack possibilities, controls, assumptions, and residual risks.

STRIDE: A threat categorization model covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Attack tree: A hierarchical model that decomposes an attacker’s objective into alternative or combined sub-goals.

MITRE ATT&CK: A knowledge base organizing adversary tactics and techniques based on observed attack behavior.

Residual risk: Risk remaining after selected controls and treatments have been implemented.

Security acceptance criterion: A verifiable condition that must be satisfied for a work item to be considered complete from a security perspective.

Threat actor: An individual, group, process, or organization capable of causing harm to an asset.

Least privilege: The principle that an identity or component receives only the permissions necessary for its authorized function.

Data-flow diagram: A representation of components, data movements, stores, external entities, and trust boundaries.

Risk treatment: An action to avoid, reduce, transfer, accept, or monitor a risk.

Policy as code: The expression and automated enforcement of governance or security rules in machine-readable form.

Review Questions

Short Answer Questions

1. Why should security requirements be introduced before implementation begins?

2. Distinguish an abuse case from a normal user story.

3. What is the purpose of a trust boundary in threat modeling?

4. Name and briefly explain the six STRIDE categories.

5. Why is threat modeling not equivalent to vulnerability scanning?

Long Answer Questions

1. Explain how security activities can be integrated across an agile secure software development lifecycle.

2. Discuss the relationship among data classification, privacy analysis, and architecture design.

3. Describe a complete threat-modeling workflow using data-flow diagrams, STRIDE, and risk treatment.

4. Explain how attack trees and MITRE ATT&CK provide different but complementary perspectives.

5. Evaluate the governance and professional responsibilities associated with residual-risk acceptance.

Analytical / Application Questions

1. A payment API accepts a customer identifier from the browser and uses it to retrieve account data. Apply STRIDE to identify important threats and propose design-level controls.

2. Construct an attack tree for the objective “deploy unauthorized code to production.” Identify at least four branches and map suitable preventive or detective controls.

3. A company plans to send employee documents to an external AI service for classification. Analyze the situation using data classification, privacy, trust-boundary, and ATT&CK-informed considerations. Recommend whether and how the design should proceed.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the purpose of a secure software development lifecycle?

A. To move all security testing to the final release stage

B. To integrate security and privacy activities throughout the product lifecycle

C. To replace architecture review with automated scanning

D. To ensure that only security specialists make development decisions

Correct Answer: B. To integrate security and privacy activities throughout the product lifecycle

Question 2

Which is the strongest example of a testable security requirement?

A. The application must be secure

B. Developers should consider privacy

C. Administrators must use phishing-resistant multifactor authentication and all administrative actions must be recorded

D. The system should prevent all attacks

Correct Answer: C. Administrators must use phishing-resistant multifactor authentication and all administrative actions must be recorded

Question 3

A malicious user manipulates a tenant identifier to view another customer’s records. Which STRIDE category is most directly involved?

A. Elevation of privilege

B. Repudiation

C. Denial of service

D. Information disclosure only

Correct Answer: A. Elevation of privilege

Question 4

What is the primary value of an attack tree?

A. It proves that an application contains no vulnerabilities

B. It decomposes an attacker objective into alternative or combined attack paths

C. It replaces the need for data classification

D. It automatically calculates exact breach probabilities

Correct Answer: B. It decomposes an attacker objective into alternative or combined attack paths

Question 5

Which activity is most characteristic of MITRE ATT&CK-informed analysis?

A. Checking whether a password meets a length policy

B. Mapping possible post-compromise behavior such as credential access and lateral movement

C. Assigning public, internal, and confidential labels to documents

D. Writing functional user stories without considering misuse

Correct Answer: B. Mapping possible post-compromise behavior such as credential access and lateral movement

Question 6

Why are trust boundaries important in a data-flow diagram?

A. They show where data or control crosses between security domains

B. They identify only physical network cables

C. They eliminate the need for authentication within a system

D. They specify the programming language used by each component

Correct Answer: A. They show where data or control crosses between security domains

Question 7

A team finds that a vulnerable dependency is used in a highly privileged deployment service. What is the most appropriate next step?

A. Ignore it because dependency scanning already detected it

B. Assess exploitability and impact, then prioritize remediation or compensating controls

C. Delete all dependency-scanning results

D. Accept the risk automatically because the service is internal

Correct Answer: B. Assess exploitability and impact, then prioritize remediation or compensating controls

Question 8

Which practice best connects threat modeling with agile delivery?

A. Keeping the threat model confidential and separate from the backlog

B. Turning relevant threats into owned, testable security acceptance criteria or design tasks

C. Performing threat modeling only after production deployment

D. Blocking every build for every scanner warning

Correct Answer: B. Turning relevant threats into owned, testable security acceptance criteria or design tasks

Question 9

In the illustrative multi-tenant case, why was server-side tenant authorization necessary?

A. Client-side identifiers are sufficient if encrypted

B. It prevents the client from defining the security context used to authorize access

C. It removes the need for storage access policies

D. It guarantees availability during denial-of-service attacks

Correct Answer: B. It prevents the client from defining the security context used to authorize access

Question 10

Which statement about AI-assisted security analysis is most accurate?

A. AI recommendations are automatically complete and require no review

B. AI eliminates the need for threat modeling workshops

C. AI can assist analysis, but outputs require validation and appropriate data-handling controls

D. AI should always receive unrestricted access to source code and logs

Correct Answer: C. AI can assist analysis, but outputs require validation and appropriate data-handling controls