Secure Software Development / Advanced: components, evidence, and response / Lesson 17

Review release and recovery readiness

Connect verified changes, remaining risks, diagnostic signals, and recovery assumptions before a release decision.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish release evidence from an operational deployment action.
Explain why rollback needs compatibility and security review.

Assemble the evidence for the exact change

Release readiness is a decision about a specific artifact and operating context, not a permanent badge attached to a repository. Connect the source change, component inventory, verified requirements, actual test results, open findings, and accepted exceptions. For the workshop export, identify which organizer scope and field projection were verified and which deployment assumptions remain pending. A successful local program cannot establish the actual identity middleware or storage configuration. Keep the accountable decision separate from the evidence so readers can assess both the factual observations and the risk accepted by the release owner.

Make pending critical evidence visible

A release gate should explain why evidence is missing rather than silently converting absence into success. The first program checks three fictional critical claims and returns the unverified ones. Its list is a classroom policy, not a universal release checklist. An organization may have additional operational, accessibility, legal, or business requirements; those need their own accountable process. This program does not authorize a deployment. It simply demonstrates that a record marked planned or not-executed cannot satisfy a verified-evidence condition, even when every other local check is green.

python A local evidence-readiness calculation

critical = {"organizer-scope", "field-projection", "artifact-binding"}
results = {"organizer-scope":"verified", "field-projection":"verified", "artifact-binding":"not-executed"}
missing = sorted(name for name in critical if results.get(name) != "verified")
assert missing == ["artifact-binding"]
assert bool(missing) is True
print("pending artifact-binding evidence preserved")

Expected output

pending artifact-binding evidence preserved

The complete program checks declared status values only. It runs none of the named verifications and performs no release action. The output names the missing boundary so an owner can obtain evidence or make an explicit policy decision.

Review what rollback would actually restore

Rollback is not automatically safe. An older application may reject a new data format, lose a migration assumption, or reintroduce a vulnerability that the new artifact corrected. Identify compatible application and data versions, necessary recovery evidence, and the protected outcome during interruption. The second program evaluates invented compatibility facts and deliberately rejects a rollback candidate that would restore an unresolved security defect. It does not choose a real recovery procedure. Actual restore, migration, routing, and deployment operations remain outside this course, and no production or configured resource is touched.

python A recovery-policy model without operational commands

def recovery_candidate(facts):
    return facts["dataCompatible"] is True and facts["securityDefectReintroduced"] is False and facts["procedureReviewed"] is True

case = {"dataCompatible":True, "securityDefectReintroduced":False, "procedureReviewed":True}
assert recovery_candidate(case) is True
assert recovery_candidate({**case, "dataCompatible":False}) is False
assert recovery_candidate({**case, "securityDefectReintroduced":True}) is False
print("fictional recovery constraints checked")

Expected output

fictional recovery constraints checked

The complete program checks three combinations of declared facts. It does not restore a backup, run a migration, assess a real vulnerability, or verify a recovery-time objective. Those claims require approved environment-specific evidence.

Define useful detection and response information

A released feature needs signals that reveal relevant failures without exposing attendee contact data. For exports, useful nonsecret categories may include permission refusal, assignment lookup unavailable, and result expiry. A signal should have an owner and a documented response question; collecting every payload is not a substitute for actionable diagnostics. Distinguish expected denials from system errors so ordinary protection does not look like a product outage. This lesson authors no alert or service configuration. It identifies what an approved operational plan would need to verify before claiming effective detection and recovery.

Keep the final decision concrete and accountable

Write what was verified, which artifact it applies to, what remains uncertain, and who owns the next action. If an exception is accepted, retain its scope, rationale, compensating controls, and review trigger. Do not hide an unexecuted boundary behind an all-green summary. A release review may conclude that local policy evidence is sufficient for continued development while actual deployment readiness remains pending. That conclusion is useful because it tells the next reviewer exactly what is needed, without pretending that an editorial course example performed operational approval or recovery.

Common errors and fixes

Green local checks approve every deployment boundary

Why it happens: Evidence scope is expanded without observations.
How to fix it: List verified and pending claims for the exact artifact.
Prevent it next time: Keep release authority and test evidence distinct.

Rollback restores a corrected weakness

Why it happens: Recovery review ignores security history.
How to fix it: Review compatible alternatives and retained protections before selecting recovery.
Prevent it next time: Include security and data compatibility in recovery assumptions.

Diagnostic volume replaces an actionable signal

Why it happens: Payload collection has no response owner or question.
How to fix it: Define minimal categories, ownership, and approved response steps.
Prevent it next time: Review privacy and usefulness together.

Check your understanding

1. Why can a previously working artifact be an unsafe rollback candidate?

Show worked solution

The data format or dependencies may have changed, and the old artifact may restore a known weakness. Review the exact compatible state and security assumptions instead of equating old with safe. A local policy model identifies the questions; an approved recovery exercise must establish actual operational behavior.

2. The artifact-binding claim is not executed. Write an accurate readiness statement.