Security in the Software Lifecycle

Imagine a fictional team spends six months building a student services portal. Three days before launch, someone asks a basic question: “Which staff members are allowed to perform high-impact account actions, and where is that rule enforced?”

If the team cannot answer, the problem is not only a missing test. The requirement may never have been defined clearly. The architecture may not have assigned responsibility. The implementation may have followed different assumptions. Reviewers may not have known what to check. Testers may not have known what result counted as success.

That is the central idea of this lesson: software security is strongest when each lifecycle stage prepares evidence for the next one.

Security gaps often look like isolated technical problems when they are discovered late. But many of them began much earlier as an unclear requirement, missing owner, undocumented assumption, unreviewed dependency, incomplete change process, or missing validation plan.

Lifecycle thinking helps defenders ask a different question: instead of only asking “Is there a problem now?”, ask “At which earlier stage should this expectation have been defined, reviewed, validated, or owned?”

Different organizations use different lifecycle names and delivery models. Some use sequential stages, others use continuous delivery, and many combine product, engineering, platform, and security workflows. The exact labels matter less than the underlying questions.

For A11, use this nine-stage model. A real team may combine several stages, but the security responsibilities still need to exist.

Planning and design determine what the team believes it is protecting. If important user roles, data categories, privileged actions, trust boundaries, and availability expectations are not understood early, later reviewers must guess what “secure” means.

Early security work does not require every detail. It requires enough clarity to create useful requirements and identify the areas that need deeper design.

Traceability means the team can follow a security expectation from the original requirement into architecture, implementation, review, validation, and release evidence.

“Someone should check this” is not an operational security control. The lifecycle needs named roles or accountable teams for each requirement, evidence source, exception, and follow-up.

A common review mistake is using one kind of evidence to support a claim it cannot actually prove.

A professional lifecycle review should distinguish what the supplied evidence says from what the reviewer concludes. The following fictional register models that separation.

Software evolves. A new feature may introduce a new privileged action. A new dependency may change maintenance responsibilities. A new supplier may create a new trust relationship. A new data type may change privacy or retention expectations.

Strong lifecycle programs define change triggers so teams know when an earlier requirement, threat model, design decision, validation plan, or release criterion must be revisited.

Teams often think about security while a service is active but forget what remains after it is replaced. An unused application can still leave behind accounts, credentials, secrets, data copies, integrations, scheduled jobs, monitoring rules, and dependencies.

You are reviewing the fictional Northbridge Student Services Portal. Use only the supplied evidence in this lesson. Do not inspect real software, repositories, accounts, APIs, or devices.

A weak security gate is a checkbox. A strong gate is a decision point that identifies exactly what evidence must exist, who reviews it, what happens when evidence is missing, and who can approve an exception.

Design a fictional gate for the transition from Validate → Release. Your gate should include:

The challenge is not to make the gate as strict as possible. It is to make it clear, evidence-based, repeatable, and useful for accountable decisions.

Before moving to secure design requirements, check whether you can explain how those requirements fit into the larger lifecycle.

If one of these still feels unclear, revisit the lifecycle stage table and the evidence-register section. A11.2 will assume that you understand where requirements come from and how they later connect to architecture, review, validation, release, and operations.

A strong portfolio artifact should be readable by someone who was not present during the lesson. It should show the logic of the review rather than only list security words.