Turn application risks into testable requirements, threat models, complementary tests and evidence-backed release decisions.
55 min 165 XPSkills: Threat modelling, Security testing, Release assurance
Brief
Halcyon Clinics is adding a patient-document download endpoint. Two days before release, a tester changes a document identifier and downloads another patient's file. The delivery lead says the application already passed its dependency scan, so this must be an operations problem. The scan never tested who was allowed to read which document.
A secure software development life cycle (SDLC) assigns security work to requirements, design, implementation, verification, release, operation and retirement. You will trace one download feature through these phases, distinguish testing categories, and decide what evidence can justify release. A green tool result is useful only when its scope matches the risk being claimed as controlled.
Security is a lifecycle responsibility: define the rule, design its enforcement, test the failure path, and retain evidence tied to the released artifact.
Requirements become tests, not aspirations
During planning and requirements, classify the data, identify affected users, and state measurable abuse-resistant behavior. Replace 'downloads must be secure' with requirement R-17: every download checks the authenticated user's access to the requested document on the server; a user without access receives a denial and no document bytes. Acceptance tests use two users and two documents: each user may retrieve their own document, while both cross-user attempts must fail. Authentication alone cannot satisfy this authorization requirement.
During design, choose where enforcement occurs and model failure paths. During implementation, review the authorization helper and its callers; during verification, exercise the two allowed and two denied combinations. Release binds passing results to the exact build. Operation adds monitoring, vulnerability intake and patching; retirement revokes service credentials and disposes of retained data according to policy. Iterative delivery repeats these activities for changes rather than waiting for one final security phase. Shift-left moves feedback into requirements, design and developer workflows; it does not remove runtime testing or monitoring.
For GRC, R-17 links the access-control objective to a design decision, reviewed change, test result and release record. An auditor can sample a shipped change and ask whether its acceptance tests ran on that artifact. A requirement document without execution evidence demonstrates intent, not operating effectiveness.
Draw the data flow, then apply all six STRIDE questions
A data flow diagram distinguishes external entities, processes, data stores and directed flows. For this feature, patient browser E1 sends a document request to download API P1; P1 queries document store D1 and returns bytes to E1. Label the request with its session token and document identifier. A trust boundary separates components governed by different identity or security assumptions: the public browser crosses into the application, and the API crosses into a separately authorized storage service. A network link is not automatically a new boundary, and encryption does not make untrusted input trustworthy.
STRIDE structures threat questions, not severity scores. Spoofing means impersonating another identity, such as replaying a stolen session token. Tampering means unauthorized modification, such as changing stored document bytes. Repudiation means denying an action when trustworthy attribution is missing; record actor, action, object, time and outcome in protected logs. Information disclosure includes reading another patient's document. Denial of service includes exhausting download workers with oversized requests. Elevation of privilege includes a patient reaching an administrator-only export function. A changed identifier may enable disclosure; classify the harmful outcome rather than automatically labelling every changed input as tampering.
Walk each flow and boundary, record threats with preconditions, and select mitigations: session validation, integrity checks, protected audit records, per-object authorization, resource quotas and role enforcement respectively. STRIDE is a prompt for discussion, not proof of completeness. Version the diagram and threat register with the design; an auditor asks which threats changed when a new export flow crossed a boundary, who owned their treatment, and how mitigation was verified.
Flows and trust boundaries reveal where assumptions require explicit validation.
Match each testing category to what it can observe
Static application security testing (SAST) analyzes source or compiled code without executing the application, looking for patterns and data paths such as untrusted input reaching an unsafe query. Dynamic application security testing (DAST) sends requests to a running application and observes responses, so authenticated roles and reachable routes determine coverage. Software composition analysis (SCA) inventories third-party components and matches versions to vulnerability and license information; it can produce an SBOM but does not prove that custom authorization logic is correct. Interactive application security testing (IAST) instruments a running application during tests to observe internal execution paths and data flow; unexercised paths remain unobserved.
Code review complements these tools by testing design intent against code. A reviewer checks that the document lookup includes an ownership or permission constraint, that denial occurs before bytes are streamed, and that error paths do not bypass the check. A scanner may find an unsafe query but miss a perfectly valid query returning the wrong patient's record. Conversely, a reviewer may miss a vulnerable transitive library that SCA identifies. Review by someone other than the author reduces self-approval risk; retain the reviewed revision and resolution of security comments.
For assurance, capture scan category, configuration, version, scope, completion status and findings against the commit and artifact digest. Record authenticated roles and exercised routes for runtime tests. An auditor asking 'what was not tested?' needs coverage and exclusions, not merely four green status icons. Test evidence contains sensitive routes and findings, so restrict access and retain it under the evidence policy.
Different observation points provide complementary evidence, not interchangeable coverage.
Gates must fail honestly and exceptions must expire
Define gate criteria before a deadline creates pressure to reinterpret them. For this release, all required jobs must complete successfully, authorization acceptance tests must pass, and zero unresolved critical findings may remain unless an approved exception applies. A scanner timeout is an unknown result, not zero findings. Block release when required evidence is missing; separately route lower-severity findings to owned remediation deadlines. Risk-based thresholds should consider exploitability, data sensitivity and reachability rather than treating a severity number as the whole decision.
Bind the gate record to commit identifier, artifact digest, test-run identifiers, policy version, decision time and approver. An exception must identify the finding and affected artifact, accountable risk owner, compensating controls, expiry and remediation plan. It is not a silent edit from failure to success. On expiry, unresolved risk must be reconsidered or blocked according to policy. Rebuilding after approval creates a different artifact and requires a new decision or validated evidence reuse under explicit policy.
These records support secure-development and change-control assurance. An auditor should be able to select a production digest, retrieve its test and review evidence, reproduce the gate decision, and determine whether any exception was valid at deployment. After release, feed incidents back into threat models and regression tests; shift-left is a shorter feedback loop, not a promise that production will never reveal a new threat.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The encrypted boundary
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
The architect removes the dashed line between an untrusted patient browser and the download API because the connection uses TLS. A tester then uses their own valid session to fetch another patient's document. The architect calls the successful read 'tampering' because the tester changed a document identifier; no stored bytes were altered.
Term bank, not all of these are right
trust boundaryinformation disclosuretamperingdenial of service
1.1What two-word diagram concept should remain between the differently trusted client and API? (two words)
1.2Which STRIDE category best describes the unauthorized reading of patient data? (two words)
Task 2: A dependency report with the wrong label
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
A pipeline report titled 'Dynamic test passed' lists installed libraries, their versions and known vulnerabilities. It sent no requests to any application. A second test did send requests and recorded responses from the running download API, but had no internal probes. The release lead insists both reports are the same testing category because both ran in the pipeline.
Term bank, not all of these are right
SCADASTSASTIAST
2.1Which testing category actually produced the component-version report? (an acronym)
2.2Which testing category describes the request-and-response test without internal instrumentation? (an acronym)
Task 3: Feedback is not a waiver
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
Developers now test authorization requirements during design and on each change rather than waiting for final verification. The delivery lead calls this 'retirement testing' and says it permits deletion of runtime tests. At release, a critical flaw remains. Policy allows a time-limited, risk-owner-approved deviation with compensating controls, expiry and a remediation plan; the lead instead proposes a permanent verbal waiver.
Halcyon Clinics needs a machine-readable plan for its document download change. The delivery lead proposes a dependency-only scan and treats an unavailable scanner as a clean result. Neither decision demonstrates that a patient cannot read someone else's document.
Complete the fields from the release contract below. Keep the field structure; use testing-category acronyms and a boolean where requested. This plan records the requirement, verification scope and release decision behavior, not a claim that checks have already run.
Download release contract
Requirement R-17: enforce per-document authorization on the server.
Acceptance test: a different patient requesting a document must be denied.
Design: model browser-to-API trust boundary before implementation.
Code gate: static analysis of application source, independent of execution.
Component gate: inventory third-party versions and known vulnerabilities.
Runtime gate: external requests against a running service, no internal probes.
Required test unavailable or failed: block release.
Maximum unresolved critical findings without an exception: 0.
Evidence must bind both commit identifier and artifact digest.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Checks
Requirement and denied cross-patient test are explicit
Design identifies the client-to-service boundary
Three testing methods match their observation points
Missing required results cannot pass the gate
Unexcepted critical findings respect the release limit
Evidence identifies both source and built artifact
A release coordinator has assembled six independent assurance claims. The coordinator argues that any green check is enough and that exceptions can be approved after deployment. Review each claim as written, not as you wish it had been implemented.
Accept claims supported by their stated evidence. Reject each unsupported claim using its single most specific reason code: category-mismatch, missing-evidence, stale-binding or invalid-exception.
Verdicts are accept or reject. Every rejection needs one reason code from: category-mismatch | missing-evidence | stale-binding | invalid-exception.
Release assurance claims
ASD-1 | A third-party component inventory proves custom authorization logic is correct; no authorization tests exist.
ASD-2 | Independent code review checked the permission constraint and denial path; reviewer and reviewed revision are retained. This supports the code-review control.
ASD-3 | A required source scan timed out with no results; the release claim is that the source gate passed.
ASD-4 | Authenticated external request tests covered both allowed downloads and cross-patient denials on the proposed artifact; report records roles, routes and digest. This supports the authorization test requirement.
ASD-5 | All gate evidence is for digest A; digest B was built afterward and proposed for deployment. No evidence-reuse policy exists; approval of A is claimed to cover B.
ASD-6 | A critical-finding exception has a remediation plan and compensating controls but no risk-owner approval or expiry; it is claimed to satisfy the time-limited exception policy.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Application Fundamentals
The OWASP Top 10 in Depth
Trace all ten 2021 application risk categories to their mechanisms, preventive controls, and defensible closure evidence.
