HARBOR DESK / 07 / PRACTICE GUIDE
Secure software development lifecycle
Translate policy into testable product requirements. Trace owner, acceptance criteria, release gates and incident feedback in one record.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
From policy to acceptance / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.policyExistsA policy document without an owner and test evidence does not prove implementation. The model requires the complete traceable requirement.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
Trace the requirement
“The app must be secure” is not testable. “No role may read a foreign tenant’s record without explicit cross-tenant authority” is a testable invariant. The business owner owns scope, engineering implementation, QA negative cases and AppSec risk reasoning. Link a requirement ID to code, tests and release evidence; a checklist alone does not establish that trace.
02 / EXPLANATION
Gates and exceptions
Define release evidence before development begins. A deadline is not acceptance rationale for an open critical issue. Where risk acceptance is permitted, record authorized owner, expiry, compensating controls and review date; acceptance does not mean fixed. The model’s no-open-critical rule is an educational policy, not a universal organizational risk model.
03 / EXPLANATION
From incident to prevention
Security work does not end when an incident ticket closes. Link the root cause to a missing requirement, design boundary or retest gap. Add a regression test that catches recurrence and assign maintenance ownership. NIST SSDF 1.1 is final; 1.2 / SP800-218r1 is draft at this source check. Do not label a draft as an effective final requirement.
04 / EXPLANATION
Example requirement record
For HD-REQ-01, define the invariant “north/ada reads only tickets it owns within north.” The product owner defines exceptions, engineering implements the server predicate, QA tests owner/other-user/other-tenant/anonymous cases, and AppSec records assumptions and residual risk. The release owner checks evidence for the same revision. If administrators later gain cross-tenant support authority, do not silently bypass HD-REQ-01: introduce explicit authority, rationale, audit records and tests. This prevents a requirement change from disappearing as removal of a SQL filter. After an incident, review not only closure but also why the regression test missed the failure.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.