I9.1 Secure Development Lifecycle and Security Requirements
Learn how fictional teams turn business and privacy needs into specific, testable, owned, traceable, operational security requirements across planning, design, implementation, review, testing, deployment, monitoring, maintenance, and retirement.
Lesson Progress
Secure Development Lifecycle and Security Requirements
High School Intermediate • I9: Secure Coding Basics • Lesson 1 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
Security Requirements Turn Good Intentions into Verifiable Work
A fictional team may agree that student records should be secure, sessions should be protected, and logs should help defenders. Those ideas are not enough. A professional requirement identifies the exact user, object, action, condition, expected result, evidence, owner, test, exception process, monitoring signal, and closure rule.
Weak requirement
“The fictional portal must be secure and use strong access control.”
Strong requirement
“Before returning a protected record, the fictional server must verify the account, role, tenant, assignment, object, action, and session state; approved access must work and unauthorized cases must be denied with structured evidence.”
Objective 1
Explain how fictional security requirements belong in planning, design, implementation, review, testing, deployment, operations, and retirement.
Objective 2
Distinguish business requirements, security requirements, privacy requirements, misuse cases, acceptance criteria, evidence sources, owners, and closure conditions.
Objective 3
Translate fictional risks into clear, testable requirements for authentication, authorization, data handling, logging, secrets, dependencies, configuration, monitoring, and recovery.
Objective 4
Evaluate fictional requirements without making them vague, impossible to test, disconnected from owners, or dependent on one tool or person.
Objective 5
Create a professional fictional Secure Development Requirements Package with traceability, tests, evidence, owners, due dates, exceptions, and residual risk.
Why This Matters
Late Security Work Creates Weak Controls and Expensive Exceptions
If fictional identity, privacy, access, logging, dependency, configuration, recovery, and monitoring requirements appear only before release, the architecture and schedule may already prevent a strong solution. Integrating security early allows teams to choose safer patterns, assign ownership, build testability, preserve legitimate workflows, and reduce permanent workarounds.
Secure Development Lifecycle
Eight Stages from Planning to Retirement
1. Planning and discovery
Define the fictional business problem, users, data, owners, legal or policy needs, critical workflows, dependencies, and acceptable risk.
Security work
Classify data, identify high-impact actions, define baseline security and privacy requirements, assign owners, and document assumptions.
Evidence
Business brief, data inventory, owner list, risk statement, security requirement set, privacy review, and scope approval.
Failure mode
Security is added after architecture and deadlines are fixed, creating expensive redesign or weak exceptions.
2. Architecture and design
Choose fictional components, trust boundaries, identity flows, data paths, storage, integrations, deployment model, and recovery behavior.
Security work
Threat model the design, define authorization boundaries, encryption needs, secrets handling, logging, failure behavior, and resilience.
Evidence
Architecture diagram, data-flow diagram, threat model, design decisions, security patterns, dependency plan, and review notes.
Failure mode
The design assumes internal systems, trusted users, or browser controls are sufficient without server-side enforcement.
3. Implementation
Build fictional application code, configuration, infrastructure, integrations, and operational features.
Security work
Use approved secure patterns for validation, parameterization, output handling, sessions, access control, errors, logs, secrets, dependencies, and defaults.
Evidence
Pull requests, peer review, secure-coding checklist, tests, configuration, build output, secret references, and implementation notes.
Failure mode
Developers use local shortcuts, raw dynamic construction, hard-coded secrets, weak errors, or inconsistent authorization.
4. Verification and testing
Confirm the fictional application meets functional, security, privacy, performance, accessibility, and reliability expectations.
Security work
Run positive, negative, misuse-case, authorization, session, input, rendering, configuration, regression, and monitoring tests.
Evidence
Test plan, test results, defects, retests, coverage report, reviewer approval, evidence gaps, and residual-risk record.
Failure mode
Testing proves only the happy path and misses invalid, unauthorized, expired, duplicate, cross-tenant, or failure conditions.
5. Deployment and release
Move the fictional build into an approved environment using controlled change and rollback.
Security work
Validate artifact integrity, runtime identity, secrets, ports, headers, certificates, feature flags, migration, monitoring, and rollback readiness.
Evidence
Release ticket, build ID, artifact verification, deployment template, environment comparison, smoke tests, owner approval, and rollback plan.
Failure mode
A secure code review is weakened by debug mode, broad permissions, wrong secrets, outdated dependencies, or configuration drift.
6. Operations and monitoring
Run the fictional service safely while supporting users, responding to issues, and preserving business workflows.
Security work
Monitor source health, authentication, authorization, errors, configuration drift, certificate lifecycle, dependencies, alerts, user reports, and business outcomes.
Evidence
Dashboards, alerts, source-health reports, access reviews, incident records, certificate alerts, dependency reports, and owner reviews.
Failure mode
The team assumes deployment completed the security work and does not monitor drift, abuse, outages, or control failures.
7. Maintenance and change
Update fictional features, dependencies, configurations, integrations, data models, and infrastructure safely.
Security work
Revisit requirements and threat models, review changed trust boundaries, test regression, update detections, and revalidate exceptions.
Evidence
Change request, updated architecture, impact analysis, dependency review, test results, deployment validation, and exception review.
Failure mode
Small changes bypass security review even though they alter data flow, access, browser behavior, or deployment settings.
8. Retirement and disposal
Remove the fictional service or feature without leaving data, accounts, secrets, integrations, domains, certificates, or monitoring behind.
Security work
Revoke access, archive or delete data safely, remove secrets, disable integrations, update inventories, preserve required evidence, and confirm ownership transfer.
Evidence
Retirement plan, data disposition record, account and secret revocation, dependency cleanup, DNS and certificate changes, and owner sign-off.
Failure mode
Old services remain reachable, credentials stay active, data is retained indefinitely, and monitoring no longer covers the environment.
Requirement Writing
Turn Eight Vague Ideas into Testable Requirements
Identity and authentication
Weak statement
Users must log in securely.
Strong requirement
Fictional staff accounts must use approved multifactor authentication; sign-in events must record account, factor, device, policy, result, and request ID; recovery must require separate verification.
Acceptance criterion
Approved staff sign-in succeeds, missing-factor and failed-recovery cases are denied, and all results appear in structured identity logs.
Accountable owner
Identity and Access Team
Authorization and least privilege
Weak statement
Users should access only what they need.
Strong requirement
The fictional server must verify role, tenant, object relationship, requested action, and workflow state before returning or changing protected records.
Acceptance criterion
Assigned-record access succeeds; unassigned, wrong-tenant, wrong-role, and expired-session cases are denied before protected data is returned.
Accountable owner
Application Team
Input and data handling
Weak statement
Validate all input.
Strong requirement
The fictional API must reject unknown fields, invalid types, unsupported choices, excessive sizes, malformed identifiers, and unauthorized objects before database operations.
Acceptance criterion
Approved requests pass; invalid or unauthorized requests produce safe errors, no database operation, and a structured validation event.
Accountable owner
Web Platform Team
Browser and output safety
Weak statement
Prevent browser attacks.
Strong requirement
Plain fictional text must use safe text binding; approved rich text must use a maintained sanitizer with a documented allowlist; sensitive pages must use the approved browser-policy baseline.
Acceptance criterion
Approved formatting renders correctly while unsupported elements, attributes, destinations, and inert markup-like samples are removed or displayed as text.
Accountable owner
Front-End and Platform Teams
Sessions and user actions
Weak statement
Sessions must be secure.
Strong requirement
Fictional sessions must rotate after sign-in and privilege elevation, expire after approved idle and maximum lifetimes, revoke on logout and account disablement, and require reauthentication for high-risk actions.
Acceptance criterion
Old identifiers fail after rotation, expired and revoked sessions are denied, and high-risk actions require fresh approved verification.
Accountable owner
Identity and Application Teams
Errors, logs, and monitoring
Weak statement
Log security events.
Strong requirement
Fictional security-relevant decisions must create structured events with time, request ID, account or service identity, route, object category, decision, reason, and result while excluding secrets and unnecessary personal data.
Acceptance criterion
Approved test events appear in monitoring with correct fields, safe redaction, owner routing, retention, and alert behavior.
Accountable owner
Application and Security Operations Teams
Secrets and service identities
Weak statement
Protect secrets.
Strong requirement
Fictional production secrets must be stored in managed secret storage, accessed only by named service identities, rotated on schedule and incident, and excluded from source code, images, logs, and tickets.
Acceptance criterion
The application retrieves only required secrets; old versions are retired; access is logged; source and image reviews contain no secret values.
Accountable owner
Platform Engineering
Dependencies and configuration
Weak statement
Keep software updated.
Strong requirement
Fictional dependencies and runtimes must be inventoried, locked, reviewed for support status and known risk, updated through tested change, and deployed using version-controlled secure baselines.
Acceptance criterion
The deployed build matches the approved manifest and configuration; exceptions are documented; update and rollback tests pass.
Accountable owner
Engineering and Infrastructure Operations
Core Concept
Use the Requirement–Control–Evidence Chain
Need
Which fictional business, security, privacy, reliability, or legal need must be protected?
Requirement
What exact fictional behavior, constraint, or evidence condition is required?
Control
Which fictional design, code, configuration, process, or owner implements it?
Test
Which fictional positive and negative cases prove expected behavior?
Evidence
Which fictional records show implementation, deployment, operation, and business result?
Closure
Which fictional monitoring, residual-risk, exception, rollback, and approval conditions complete the work?
Quality Review
Eight Tests for a Strong Requirement
Specific
Does the fictional requirement identify the exact system, user, data, action, control, and condition?
Weak signal
Words such as secure, strong, appropriate, or protected appear without measurable meaning.
Improvement
Name the route, role, object, session condition, browser context, log fields, or configuration value.
Testable
Can a fictional reviewer prove the requirement with repeatable positive and negative evidence?
Weak signal
The requirement depends on opinion or cannot produce a clear pass or fail.
Improvement
Add exact acceptance criteria, expected results, evidence sources, and test owners.
Owned
Is a fictional team accountable for implementation, operation, validation, monitoring, and review?
Weak signal
The owner is listed as everyone, security, engineering, or later.
Improvement
Assign one accountable owner and supporting teams with due dates and escalation.
Traceable
Can the fictional requirement be followed into design, code, configuration, tests, deployment, logs, and closure?
Weak signal
The requirement appears only in a planning document and is disconnected from implementation evidence.
Improvement
Use a requirement ID and link every artifact, test, change, finding, and exception.
Risk aligned
Does the fictional control strength match data sensitivity, action impact, exposure, user type, and business consequence?
Weak signal
Every feature receives the same control regardless of risk.
Improvement
Use stronger verification, approval, monitoring, or recovery for higher-impact workflows.
Operational
Does the fictional requirement include logging, monitoring, maintenance, renewal, review, and failure behavior?
Weak signal
The control is implemented once but has no owner after deployment.
Improvement
Add source health, alerting, drift review, certificate or dependency lifecycle, and incident actions.
Privacy safe
Does the fictional requirement minimize collection, retention, display, logging, and sharing of user data?
Weak signal
The control collects or stores more personal information than needed.
Improvement
Limit fields, access, retention, export, display, and monitoring content to the business need.
Maintainable
Can the fictional requirement survive new features, environments, roles, dependencies, and architecture changes?
Weak signal
The requirement is hard-coded to one page, person, tool, or temporary workaround.
Improvement
Use reusable patterns, versioned baselines, automated tests, documented exceptions, and periodic review.
Requirement Traceability
Six Requirements Connected to Design, Code, Tests, and Evidence
SR-01 Object authorization
Design
Fictional server resolves tenant, assignment, role, and object before returning a support record.
Implementation
Protected record service uses a central authorization policy.
Test
Assigned access passes; unassigned, wrong-tenant, wrong-role, and expired-session cases fail.
Evidence
Requirement record, architecture note, pull request, test IDs, application decisions, and database results.
SR-02 Safe report input
Design
Fictional report requests use strict schemas and server-defined sort and filter mappings.
Implementation
Approved values are bound through supported data APIs.
Test
Unknown fields, invalid types, excessive limits, unsupported sort choices, and unauthorized objects fail before database access.
Evidence
Schema, code review, test result, safe error, no-operation database record, and monitoring event.
SR-03 Protected sessions
Design
Fictional sessions rotate at trust changes and use approved idle, maximum, logout, and revocation rules.
Implementation
Central session service issues and revokes session identifiers.
Test
Old, expired, revoked, and wrong-device-risk sessions are denied while approved sessions work.
Evidence
Session policy, configuration, identity logs, application decisions, and test report.
SR-04 Safe announcement rendering
Design
Fictional plain text and approved rich text follow separate rendering paths.
Implementation
Plain text uses safe binding; rich text uses a maintained sanitizer and content policy.
Test
Approved formatting works; unsupported content is removed or displayed as text.
Evidence
Component review, sanitizer configuration, browser result, policy event, and regression test.
SR-05 Sensitive-action protection
Design
Fictional approvals require POST, anti-forgery validation, authorization, confirmation, reauthentication, and idempotency.
Implementation
Central action service validates token, origin, user, object, workflow, and transaction state.
Test
Approved action creates one result; missing-token, wrong-origin, framed, canceled, GET, and duplicate cases create none.
Evidence
Request logs, application decisions, transaction records, confirmation view, and test report.
SR-06 Secure production baseline
Design
Fictional hosts, certificates, headers, cookies, services, secrets, runtime, and errors use a version-controlled standard.
Implementation
Deployment templates define approved settings and identities.
Test
Approved workflows pass; HTTP redirects, unapproved framing, debug details, unnecessary services, and drift fail.
Evidence
Baseline, build, deployment, certificate, header, cookie, listener, drift, and validation records.
Security Gates
Six Decision Points with Evidence and Exceptions
Planning gate
Required evidence
Fictional scope, owners, data classification, critical workflows, security requirements, privacy needs, and initial risk statement.
Decision
Proceed only when high-impact requirements and accountable owners are identified.
Exception rule
A time-limited discovery exception may allow research work but not production data or real users.
Design gate
Required evidence
Fictional architecture, data flow, trust boundaries, threat model, control decisions, logging plan, and recovery design.
Decision
Proceed only when critical risks have approved controls or documented exceptions.
Exception rule
Unresolved design risk requires an owner, compensating control, decision date, and approval.
Implementation gate
Required evidence
Fictional peer review, secure-coding checklist, dependency review, secret scan, unit tests, and requirement traceability.
Decision
Proceed only when critical code paths use approved patterns and blocking findings are resolved.
Exception rule
A temporary code exception must be isolated, monitored, tested, and scheduled for removal.
Release gate
Required evidence
Fictional integration tests, negative tests, environment comparison, artifact validation, monitoring readiness, rollback, and owner approval.
Decision
Release only when acceptance criteria pass and residual risk is approved.
Exception rule
Emergency release requires narrow scope, extra monitoring, rapid follow-up, and documented business approval.
Operational gate
Required evidence
Fictional source health, alert routing, access reviews, certificate and dependency lifecycle, drift monitoring, user support, and incident readiness.
Decision
Keep the service active only while required controls remain healthy and owned.
Exception rule
A degraded control requires temporary protection, owner, due date, monitoring, and escalation.
Retirement gate
Required evidence
Fictional data disposition, account and secret revocation, integration removal, inventory updates, evidence preservation, and owner sign-off.
Decision
Close only when no unintended service, data, credential, domain, certificate, or dependency remains active.
Exception rule
Required archival retention must be narrow, access controlled, time limited, and documented.
Evidence Matrix
What Lifecycle Evidence Can and Cannot Prove
Evidence source
Requirement record
Can support
The fictional control statement, scope, owner, priority, acceptance criteria, exception, and review date.
Limitation
A written requirement does not prove implementation or operational effectiveness.
Evidence source
Architecture and threat model
Can support
The fictional components, users, data flows, trust boundaries, risks, control decisions, and assumptions.
Limitation
Architecture can become stale or omit implementation and runtime differences.
Evidence source
Code and configuration review
Can support
The fictional implementation pattern, control logic, dependency, runtime setting, secret reference, and baseline alignment.
Limitation
Review must be confirmed against the deployed build and actual behavior.
Evidence source
Positive test
Can support
The fictional approved workflow works for the correct user, object, data, environment, and business state.
Limitation
A positive test does not prove invalid or unauthorized conditions are denied.
Evidence source
Negative or misuse-case test
Can support
The fictional application denies invalid, unauthorized, expired, duplicate, cross-tenant, unsafe, or misconfigured conditions.
Limitation
Test coverage may not include every role, object, browser, integration, or failure path.
Evidence source
Deployment and drift record
Can support
The fictional build, environment, secrets, runtime, listeners, flags, configuration, change, and baseline comparison.
Limitation
A documented deployment can still be incorrect or change later.
Evidence source
Monitoring and business record
Can support
The fictional control health, alert, user effect, transaction, workflow state, availability, and business outcome.
Limitation
Short monitoring periods and missing sources can leave residual uncertainty.
Evidence source
Owner approval and exception
Can support
The fictional accountability, decision, business context, accepted residual risk, expiration, and follow-up.
Limitation
Approval does not make an unsafe condition technically secure or permanent.
Traceable Requirement Timeline
Follow a Fictional Authorization Requirement from Planning to Operations
Day 1
Planning
A fictional team proposes a student-support portal with teacher and administrator workflows.
The application scope and user groups begin to form.
Day 2
Data review
The team classifies support summaries and case notes as nonpublic student information.
Privacy, authorization, logging, retention, and export requirements become higher priority.
Day 3
Requirement
SR-01 requires teachers to view only assigned student records and administrators to use reauthentication for district export.
Two high-impact authorization expectations are documented.
Day 4
Design
The fictional architecture places browser requests behind a reverse proxy, application API, identity service, and reporting database.
Trust boundaries and evidence sources are identified.
Day 5
Threat model
The team identifies unassigned-record access, unsafe report input, exposed administrative routes, weak sessions, and overbroad logs as misuse cases.
Security requirements are connected to specific failure paths.
Day 8
Implementation review
A fictional route checks authentication but does not verify the record assignment relationship.
The code does not meet SR-01.
Day 9
Negative test
A fictional teacher can request another teacher’s assigned record in the safe test environment.
The object-authorization weakness produces an unauthorized result.
Day 10
Containment
The affected test feature is blocked from release while the central authorization policy is corrected.
The release gate prevents the known weakness from reaching production.
Day 11
Remediation
The server resolves tenant, record, assignment, role, and action using trusted data before returning content.
The implementation now aligns with the requirement.
Day 12
Positive test
A fictional teacher can view an assigned record successfully.
Legitimate use remains available.
Day 12
Negative test
Unassigned, wrong-tenant, wrong-role, expired-session, and missing-session requests are denied before data access.
Several misuse and failure conditions are controlled.
Day 13
Release review
The requirement, design, code, tests, logs, deployment baseline, rollback, and owner approvals are linked in the release record.
Traceability supports a defensible gate decision.
Day 14
Deployment
The fictional build is released through the approved production template.
The reviewed implementation and configuration move into operation.
Day 21
Monitoring
Assigned access remains normal and no unexplained authorization denials or cross-tenant results appear.
Short-term operational evidence supports the control.
Day 30
Review
The owner confirms the requirement remains current after a new reporting feature is proposed.
Maintenance work triggers requirement and threat-model review.
Key Vocabulary
Secure Development and Requirement Terms
Secure development lifecycle
A fictional process that includes security and privacy activities throughout planning, design, implementation, review, testing, deployment, operations, maintenance, and retirement.
Security requirement
A fictional statement describing a protection, constraint, behavior, or evidence condition that the application must meet.
Acceptance criterion
A fictional measurable condition used to decide whether a requirement has been implemented successfully.
Misuse case
A fictional description of how a feature, role, workflow, or dependency could be used incorrectly, abused, or misunderstood.
Threat model
A fictional structured review of assets, users, data flows, trust boundaries, entry points, dependencies, and possible failures.
Traceability
A fictional connection from requirement to design, code, configuration, test, evidence, owner, deployment, and monitoring.
Security gate
A fictional decision point that requires selected evidence or approval before work moves to the next lifecycle stage.
Exception
A fictional approved and documented temporary or narrow departure from the security baseline.
Residual risk
The fictional risk that remains after controls, validation, monitoring, and exceptions are considered.
Definition of done
A fictional set of technical, security, privacy, testing, documentation, and operational conditions required before work is complete.
Evidence source
A fictional record such as a test, log, review, configuration, deployment result, owner approval, or business-system state used to support a conclusion.
Control owner
The fictional team or person accountable for implementation, operation, validation, monitoring, and review of a control.
Fake Dashboard
Fake Secure Development Requirements Dashboard
Training dashboard for the fictional Meadowbrook student-support portal.
Security requirements
42
Fictional identity, access, data, browser, session, logging, secret, dependency, configuration, recovery, and privacy requirements.
Traceable requirements
37
Requirements linked to design, implementation, tests, deployment, monitoring, owners, and closure evidence.
Open gaps
5
Missing negative test, incomplete owner, stale threat model, temporary exception, and operational-monitoring cases.
Fake SOC Alert
Object-Authorization Requirement Fails Negative Testing
Source: Fake Secure Development Review Console • Time: 02:15 PM
Fake Log Panel
Fake Requirement Traceability Timeline
DAY1 PLAN application='student-support-portal' users='teacher,admin' DAY2 DATA_CLASSIFICATION support_notes='nonpublic' DAY3 REQUIREMENT id='SR-01' teacher_access='assigned_only' DAY4 DESIGN proxy='defined' identity='defined' api='defined' database='defined' DAY5 THREAT_MODEL misuse='unassigned_record_access' DAY8 CODE_REVIEW route_authentication='present' assignment_check='missing' DAY9 NEGATIVE_TEST teacher_other_record='allowed' DAY10 RELEASE_GATE result='blocked' DAY11 REMEDIATE tenant='verified' assignment='verified' object='verified' DAY12 POSITIVE_TEST assigned_record='pass' DAY12 NEGATIVE_TEST unassigned='deny' wrong_tenant='deny' expired_session='deny' DAY13 TRACEABILITY requirement='linked' code='linked' tests='linked' rollback='linked' DAY14 DEPLOY release='approved_template' DAY21 MONITOR unexplained_authorization_denials='0' cross_tenant_results='0' DAY30 CHANGE_REVIEW reporting_feature='threat_model_update_required'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Secure Development Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Security Requirements
Safe Practice Lab
Build a Fictional Secure Development Requirements Package
Fictional Evidence Set
Meadowbrook Student-Support Portal
Review forty supplied fictional records covering planning, owners, users, data, architecture, threat modeling, requirements, code review, configuration, tests, deployment, monitoring, exceptions, change, retirement, and closure.
Required Analysis
- Define fictional business, security, privacy, reliability, and recovery needs.
- Write eight requirements with exact scope, owners, acceptance criteria, evidence, and review dates.
- Create misuse cases and connect each requirement to architecture and threat-model decisions.
- Link each requirement to implementation, positive tests, negative tests, deployment, and monitoring.
- Design planning, design, implementation, release, operational, and retirement gates.
- Document exceptions, compensating controls, residual risk, rollback, lessons learned, and closure criteria.
Scenario Decision Lab
A Requirement Is Too Vague to Test
A fictional project requirement says, “The portal must use strong access control,” but it does not identify roles, objects, tenants, actions, sessions, owners, or evidence.
Scenario Decision Lab
A Release Has One Temporary Security Exception
A fictional reporting feature meets most requirements, but one low-impact legacy export path cannot use the new monitoring format before the deadline.
Defender Habits
Secure Development Lifecycle and Requirements Checklist
Check Your Understanding
I9.1 Mini Quiz: Secure Development Lifecycle and Security Requirements
Choose your answers first. Explanations appear only after submission.
1. What makes a fictional security requirement strong?
2. Why should fictional security work begin during planning and design?
3. Which acceptance criterion best supports an object-authorization requirement?
4. What does traceability provide?
5. When should a fictional threat model be updated?
6. Which release-gate decision is strongest?
7. Which exception design is strongest?
Portfolio Prompt
Portfolio Prompt
Create a fictional Secure Development Requirements Package using at least forty planning, architecture, threat-model, requirement, owner, code-review, configuration, test, deployment, monitoring, exception, maintenance, retirement, and closure records. Include eight requirements, acceptance criteria, misuse cases, traceability links, gate decisions, owners, positive tests, negative tests, evidence gaps, exceptions, residual risk, rollback, and closure criteria.
Key Takeaways
What You Should Remember
Navigation