How the change is made

SDLC is a gate chain, not a phase poster

Bound → design → build → verify

Bound, design, build, and verify are layers. Ceremonies are lanes. A waterfall diagram is not a contract — name acceptance before anyone writes code. How the change lands lives on the Delivery card (window, proof, cutover).

BOUNDContract — what this change is, and is not

DESIGNCut — interfaces, data, threat model, smallest slice

BUILDCode — small batches on a releasable trunk

VERIFYEvidence — tests, review, security checks before merge

Problem → use → example

If the real problem is…	Use	Example case
“Build the thing” with no acceptance	Named bound	Credit-engine rule change: who, which products, what “done” looks like — not a two-line chat ticket
Security shows up after the demo	Threat model in design	New partner API: data class, auth, and abuse cases written before the first commit — SDL practice, not a retro finding
Secure practices live in a binder, not the loop	SSDF in the SDLC	Review, tests, and supply-chain checks are merge gates; a poster of Waterfall phases is not SSDF
Nobody can tell if the change is safe to merge	Test pyramid	Unit on the scoring function, contract on the engine API, one path through the UI — not a week of manual clicking
Main is a graveyard of long-lived branches	Small batches on trunk	Incomplete UI behind a flag; main stays releasable — same CD test the Delivery card uses at cutover
Review is a rubber stamp after the fact	Review before merge	PR names the bound and the test; Copilot draft is not the review — a person still owns the merge
“It works on my machine” is the evidence	CI on every change	Push to main runs tests and lint; broken trunk is the incident, not a Friday surprise
Don’t know what “secure enough” means for this app	ASVS level	Consumer-finance API: pick a verification level and fail the build on the controls that matter — not a 400-row audit dump
Dependencies are a mystery zip	Known supply chain	Lockfile + advisory scan on the credit-engine client; a new package is a change, not a convenience
Ceremony replaced the contract	Lead time, not stand-up theatre	Time from bound to mergeable change; a filled Scrum board is not evidence the software is safer

Default order: name the bound and owner → design the cut (incl. threat) → smallest build on trunk → verify (tests, review, security) → then the Delivery card for window and cutover.

Tool picker

NIST SSDFSecure practices inside the SDLC, not after

Microsoft SDLThreat model, supply chain, security tests

OWASP ASVSWhat “verified” means for this app

Trunk-basedSmall batches; main stays releasable

Pull requestsHuman review names the bound and the test

Test pyramidFast evidence close to the change

Continuous IntegrationBroken trunk is the incident

Contract vs ceremony

Contract · bound Acceptance named. A phase name is not a requirement. Design includes the threat, not only the happy path.

Ceremony · optional Stand-ups, story points, and SAFe trains are lanes. They do not replace VERIFY evidence or a merge owner.

Memory check BOUND = contract. DESIGN = cut. BUILD = smallest code. VERIFY = evidence before merge.

Ladder + gates

Named bound + owner
Design the cut + threat
Smallest build on trunk / flag
Tests that fail for the right reason
Review + security checks
Mergeable — then Delivery for cutover

Kill switch If you can’t name the bound, the test, and who reviews, you don’t merge.

Anti-patterns

Phase poster as the plan
Security as a late finding
Ceremony without a contract
Long-lived branches instead of flags
“Works on my machine” as evidence
Rubber-stamp review after merge
Framework shopping (SAFe/Waterfall) before gates
Calling it shipped — that’s the Delivery card

Always on

SecurityThreat model, ASVS level, supply chain

GovernanceWho owns the bound and the merge

ObservabilityCI evidence on every change

EvalsTests that fail for the right reason

Human ApproveA person still owns the merge