Secure Software Development / Basic: outcomes, models, and decisions / Lesson 1

Make security a lifecycle responsibility

Connect a software change to protected outcomes, accountable decisions, and evidence across its lifecycle.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate security activities, product properties, and supporting evidence.
Choose a concrete risk question for a small fictional workshop service.

Begin with the harm the change could cause

A community workshop service stores invented attendee contacts and lets organizers manage registrations. A new export feature could expose contacts to the wrong organizer even when its interface is convenient and its tests return success. Start with the protected outcome: only an authorized organizer receives the permitted fields for assigned workshops. This gives design, implementation, and verification a common question. “Run a security tool” is an activity, while preventing unauthorized disclosure is a property. Completing the activity does not establish the property unless its evidence addresses that particular boundary.

Assign work before and after coding

Secure development includes preparation, protection of development inputs, production of safer software, and response to discovered weaknesses. Use SSDF as a reference framework, then tailor concrete responsibilities to the team and product. A requirement needs an owner, a design decision, an implementation boundary, and a verification plan. A released feature also needs a way to receive reports and correct defects. Avoid treating release as the point where responsibility ends. The first record is a fictional work assignment, not a claim that the listed activities were performed or that an organization conforms to a standard.

json A fictional lifecycle responsibility record

{"change":"workshop-export","protectedOutcome":"assigned-organizers-only","requirementsOwner":"product-role","implementationOwner":"feature-role","verificationOwner":"review-role","reportingOwner":"response-role","evidenceState":"planned"}

The role names are classroom responsibilities, not real people or credentials. This non-runnable record separates ownership from completion. Planned evidence must remain planned until actual observations support a stronger conclusion.

Use risk to ask better questions

Risk reasoning considers what could go wrong, the impact, plausible paths, and existing controls. A short numeric score can help organize review, but it cannot replace the scenario and assumptions behind it. A contact export affects confidentiality; an unauthorized cancellation also affects integrity and availability of a registration. Name the affected data and action rather than labeling the whole application high risk. Keep uncertainty explicit when exposure or usage is unknown. The local example classifies invented findings by a declared classroom policy and does not calculate an objective real-world risk level.

python Route synthetic scenarios to a review question

def review_priority(exposes_contacts, crosses_organizer_boundary):
    if exposes_contacts and crosses_organizer_boundary:
        return "design-review-required"
    return "review-context-needed"

assert review_priority(True, True) == "design-review-required"
assert review_priority(True, False) == "review-context-needed"
assert review_priority(False, True) == "review-context-needed"
print("three review-routing cases checked")

Expected output

three review-routing cases checked

This complete program verifies three decisions in an invented triage rule. The fallback requests context rather than declaring safety. It performs no scan, assessment of a real product, or standard-conformance calculation.

Distinguish records from observations

A threat model, review checklist, and test report serve different purposes. A threat model explains assumptions and possible failures; a review records human reasoning about a change; an executed test provides bounded observations. None should be silently substituted for the others. Record the source revision, fixture, relevant control, and environment for each observation. If the export authorization was modeled in memory, say so. That result cannot establish storage scoping, identity middleware, or deployed configuration. Evidence remains valuable when its limitations are visible and its claim is narrow enough to assess.

Close the loop after a weakness is found

A defect report should lead to a protected reproduction, a narrow repair, verification of adjacent behavior, and a decision about similar paths. If the export omitted an ownership predicate, search authorized source code for equivalent export flows rather than running probes against real accounts. Improve the requirement or review rule that missed the issue. Preserve a useful regression without storing private incident data in tests. The goal is a repeatable learning loop that reduces recurrence while acknowledging that no checklist or passing suite proves the absence of every vulnerability.

Common errors and fixes

A tool run is reported as proof of safety

Why it happens: An activity is confused with a protected product outcome.
How to fix it: Name the boundary and the evidence the tool actually supplied.
Prevent it next time: Review claims against observations rather than activity counts.

Security ownership ends at release

Why it happens: No report and remediation responsibility was assigned.
How to fix it: Define the response owner and verification workflow.
Prevent it next time: Include maintenance and response in the lifecycle plan.

An unexplained score replaces the risk scenario

Why it happens: The numeric ranking hides impact and uncertainty.
How to fix it: Write the affected asset, action, boundary, and assumptions.
Prevent it next time: Keep rationale alongside any prioritization scale.

Check your understanding

1. The export feature has a completed checklist but no authorization observation. What can the report conclude?

Show worked solution

It can conclude that the checklist activity was recorded, while the organizer-scoping property remains unverified. Assign a concrete owner/resource/action case and capture the response and protected state at the appropriate boundary. Do not relabel a planned check as a pass.

2. A contact leak is repaired. What additional lifecycle work is justified?