9.1 Secure SDLC Governance and Requirements

Security Belongs In The Lifecycle

Software security is a management system before it is a testing activity. The secure SDLC defines how the organization identifies risk, writes requirements, reviews designs, builds software, tests controls, approves releases, and learns from incidents. A CISSP should think in terms of repeatable decision points, accountable owners, and evidence that supports risk acceptance.

The current CISSP outline treats Software Development Security as a domain focused on application security governance, SDLC practices, secure design and coding, environments, source control, CI/CD, deployment, vulnerability management, supply chain, threat modeling, and DevSecOps. That breadth matters. A narrow answer such as run a scanner at the end is usually incomplete because it does not address requirements, ownership, or residual risk.

Secure requirements translate business obligations into verifiable controls. If a product processes health, payment, export-controlled, or employee data, the application team needs requirements for authentication, authorization, encryption, retention, logging, privacy, error handling, resilience, and administrative access. These requirements should be clear enough for design review and test planning. Vague phrases such as make it secure do not create acceptance criteria.

Requirements should be risk-based, not copied blindly. A public marketing site, a hospital medication workflow, and an internal billing platform should not receive identical treatment. The difference is not whether security matters; the difference is the level of assurance, evidence, and approval required. A manager should align controls to business criticality, data classification, legal duties, threat exposure, and operational dependency.

Governance also defines roles. Product owners own business outcomes and help prioritize risk treatment. Data owners define classification, retention, and permitted use. Architects select patterns that meet requirements. Developers implement controls. Security engineers advise, test, and set standards. Operations teams monitor and recover. Legal, privacy, procurement, and compliance teams may be required when contractual, third-party, or regulated data issues exist.

A useful secure SDLC policy does not need to be heavy, but it must be specific. It should define which work items require threat modeling, what security reviews are mandatory for high-risk changes, which tools are required in pipelines, how exceptions are approved, how release blockers are defined, and how production defects are tracked. It should also distinguish mandatory standards from guidance so teams know what can be tailored.

Security requirements need traceability. When a requirement says all administrative actions must be logged, the team should know why it exists, where it is implemented, how it is tested, and who accepts a deviation. Traceability becomes important during audits, incidents, and acquisitions. It also prevents a common failure: a control is promised in a policy, partially built in code, missed in testing, and never owned in operations.

Consider a team building a customer portal that allows address changes and refund requests. A security manager should ask about identity proofing, session management, authorization checks, fraud signals, transaction logging, customer notification, rate limiting, and support staff access. The manager should also ask whether customer data is used for analytics, whether data retention matches policy, and whether third-party services receive personal information. These are requirements questions before they are code questions.

DevSecOps does not remove governance. It changes where governance is implemented. Instead of a security board manually approving every small change, approved standards, automated checks, reusable secure templates, and risk-based escalation can make delivery faster and more consistent. The organization still needs accountable control owners and documented exceptions. Automation without policy authority is only a collection of scripts.

Use this requirements checklist before a feature enters design:

• Identify data types, data owners, and classification.
• Identify user roles, privileged actions, and service identities.
• Define authentication, authorization, logging, encryption, retention, and error handling expectations.
• Define abuse cases and misuse conditions, not only normal user stories.
• Map requirements to tests and release criteria.
• Record unresolved risk with an owner, expiration date, and compensating controls.

At the CISSP level, the best SDLC decision is often the one that preserves both delivery and accountability. Blocking a release without explaining business impact is weak governance. Approving a release with untracked critical defects is also weak governance. Mature programs make risk visible early, let the right owners decide, and retain evidence that decisions were informed and authorized.