Secure development is a product lifecycle, not a final scan

A secure software development lifecycle integrates product-security outcomes into planning, design, implementation, verification, release, operation, vulnerability response, and retirement. NIST SSDF 1.1 groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. These practices supplement an organization's delivery model rather than requiring one waterfall or agile process. CISA's secure-by-design guidance adds an important accountability boundary: manufacturers should take ownership of customer security outcomes, ship secure defaults, communicate transparently, and fund structures that remove systemic defect classes instead of transferring avoidable burden to users.

Begin with requirements and design decisions

Define security, privacy, safety, abuse-resistance, resilience, update, logging, support, and vulnerability-handling requirements from product use, data, customers, deployment models, threat actors, law, contracts, and end-of-life obligations. Assign product and engineering owners, record risk decisions, and create verification criteria before implementation. Threat models trace trust boundaries, data and control flows, identities, dependencies, administrative paths, build and update mechanisms, and recovery. Architecture should minimize attack surface and privilege, establish resource-level authorization and tenant isolation, choose memory-safe or otherwise risk-appropriate technologies, and make the secure path the easiest supported path.

Protect source, build, and release integrity

Use strongly authenticated, least-privilege development identities; protected branches and reviewed changes; separated production and build authority; isolated, reproducible where feasible, and monitored build environments; pinned and verified dependencies; and governed secrets. Generate inventories and provenance for released components. Signing and provenance establish statements about artifact identity and process—they do not prove the source is benign, free from vulnerabilities, or suitable for every consumer. Verify artifacts and policy at deployment, retain rollback and revocation, and preserve runtime controls because upstream controls can fail.

Verify risk through complementary evidence

Code review, compiler and language defenses, SAST, secret scanning, dependency and license analysis, IaC and container checks, fuzzing, property and unit tests, DAST, API and authorization tests, penetration testing, and abuse-case exercises cover different weaknesses. Tools need scoped populations, tuned policies, owners, triage, suppression expiry, and regression tests. A green scanner can mean missing coverage, unsupported languages, stale rules, or an unreachable path; findings require exploitability and consequence analysis without using "not currently exploitable" as permanent dismissal. Release criteria should be risk-based, explicit, exception-governed, and capable of blocking material unresolved exposure.

Govern change without turning security into ceremony

Apply review depth from consequence, novelty and exposure. A small copy change should not wait for the same ceremony as a new authentication flow, cryptographic protocol, tenant boundary or autonomous tool permission. Encode stable requirements in libraries, templates, policy checks and test harnesses; reserve expert review for high-risk designs, exceptions and ambiguous business logic. A material change trigger should include new data, identity, privilege, integration, region, dependency, deployment authority or recovery behavior, not merely the number of changed lines. Record the decision and its evidence so later maintainers know which assumptions require revalidation.

Exceptions name the unmet requirement, affected release and population, exploitation path, compensating controls, approver with risk authority, expiry, monitoring and closure test. Bind approval to the exact artifact or plan digest so code cannot change after review without reopening the gate. Emergency fixes may use an accelerated path, but still require protected access, peer visibility where feasible, complete audit, immediate verification and scheduled retrospective work. Measure false blocks and developer effort alongside escaped defects so teams improve the paved road instead of bypassing it.

Secure dependencies, updates, and customers

Inventory direct and transitive components with version and provenance, but treat an SBOM as a starting point rather than proof. Define intake for advisories and researcher reports, determine affected configurations, prioritize by exploitability and customer consequence, and retain a reproducible path from source and dependency inputs to released artifact. Protect package namespaces, maintainers, build runners, artifact stores, signing keys and deployment controllers as one supply chain. After compromise, revoke trust and rebuild from known foundations; signing the same compromised artifact again is not recovery.

Product security continues at the customer boundary. Ship supported secure defaults, minimize privileged setup, document deployment assumptions, provide actionable logs and authenticated updates, and make version/support state observable. Advisories distinguish affected and fixed versions, mitigations, known exploitation, update risk and residual limitations without exposing unnecessary victim detail. Track whether customers can adopt the fix and whether rollback, migration or end-of-life creates new exposure. Retirement removes hosted data and credentials, protects or destroys signing authority deliberately, and gives customers a realistic exit rather than converting an unsupported product into permanent hidden risk.

Operate, disclose, learn, and retire

Ship secure defaults, authenticated updates, actionable logging, version and support visibility, safe recovery, and customer guidance without paywalling essential security. Maintain intake for external researchers, coordinated disclosure, vulnerability validation, affected-version analysis, severity and exploitability assessment, fixes, advisories, CVE coordination when applicable, and verifiable update delivery. Monitor incidents, exploitation, patch adoption, recurring root causes, escaped defects, and customer friction. Correct entire vulnerability classes through safe libraries, frameworks, linters, templates, and architectural changes. End-of-life plans provide notice, migration/export, final fixes where committed, credential and signing-key handling, and transparent residual risk.

Secure SDLC effectiveness is measured with product outcomes: critical path and component coverage, defect escape and recurrence, time to validate and remediate, update adoption, secure-default use, exception age, build/provenance verification, response quality, and customer harm. Activity counts—training attendance, scans, tickets, SBOM rows, or maturity scores—are useful only when tied to coverage and risk reduction. Human review remains necessary for context, business logic, privacy, safety, and attacker creativity; automation supplies fast, repeatable evidence rather than automatic assurance.

Worked example: a green pipeline is not coverage

Friday's PR: SAST, SCA, and container scan all passed. Monday a tenant-IDOR ships because no test exercised object ownership.

gate	Friday result	what it actually checked	IDOR
SAST	green	injected SQL/XSS patterns	miss
SCA	green	known CVEs in lockfile	miss
container scan	green	OS packages in the image	miss
authz fixture GET /invoices/813 as tenant A	not in CI	object ownership	would fail

Three greens, one untested invariant. Adding a fourth scanner that also never reads tenant IDs does not close the gap. That table is the interview.