Application
Northbridge Student Services Portal
A fictional staff-facing web application used for approved student-support workflows.
High School AdvancedA11.10Secure Software ArchitectureCapstone Lab
Lesson A11.10
Secure Software Design Lab
This capstone brings every A11 concept into one fictional software architecture assessment. Your goal is not to create more separate artifacts. Your goal is to determine whether the artifacts already built form one coherent, traceable, evidence-based security design.
You will review architecture areas, evidence conflicts, residual risks, decision records, release blockers, and portfolio quality without accessing or testing any real system.
Lesson Progress
Secure Software Design Lab
High School Advanced • A11: Secure Software Architecture • Lesson 10 of 10
100% complete
Readiness Check
A11.10 Capstone Readiness
0/4 ready
Capstone Scenario
Northbridge Student Services Portal
The fictional Northbridge team is preparing release candidate NB-PORTAL-11.10-RC1. The application has completed design review, code review, validation, and release preparation. Most evidence is strong, but several important conditions remain.
Your role is to act as the architecture reviewer. You must decide whether the software design is coherent, which residual risks remain, what blocks release, and what must be owned after release.
Primary users
Counselors, administrators, support staff
Roles differ in authorization scope and privileged capabilities.
Sensitive assets
Student-support records, account state, audit evidence
The architecture must protect privacy, integrity, least privilege, and traceability.
External services
Scheduling and notification providers
Only approved minimum data may cross external trust boundaries.
Critical dependencies
Identity SDK, messaging client, report renderer, signing service
Ownership, support, provenance, compatibility, and update evidence matter.
Release candidate
NB-PORTAL-11.10-RC1
The capstone asks whether the current fictional evidence supports release readiness.
Learning Objectives
Five Capstone Capabilities
1
Integrate the major A11 artifacts into one coherent secure software architecture assessment.
2
Evaluate whether requirements, threat-model concerns, secrets, dependencies, logging, code review, validation, and deployment evidence tell a consistent story.
3
Identify contradictions, missing ownership, stale evidence, and residual risk without overstating certainty.
4
Make defensible design and release recommendations for a fictional application using bounded evidence and explicit assumptions.
5
Produce a polished Secure Software Design Assessment suitable for the A11 portfolio outcome.
Architecture Review
Eight Security Areas in One Design
A secure architecture assessment should not review identity, dependencies, logging, and deployment as unrelated topics. The strongest design shows how each area supports the others.
Identity
ConfirmedRequirement
Staff access uses the approved workforce identity provider.
Threat concern
Disabled or stale identities could retain access if lifecycle assumptions fail.
Design
Application trusts the approved identity provider and rejects invalid or disabled staff sessions.
Evidence
Identity design note, test evidence, release configuration review.
Authorization
ConditionalRequirement
Counselors may view only records for students assigned to them.
Threat concern
Stale or incorrect assignment data could produce access inconsistent with policy.
Design
Central authorization service checks the approved assignment source before record access.
Evidence
Code-review evidence, positive/negative test results, audit events.
Data minimization
ConfirmedRequirement
Scheduling integration receives only studentRef, date, and time.
Threat concern
Future feature additions could expand outbound data beyond the approved purpose.
Design
Integration payload builder emits approved fields only.
Evidence
Requirement, pseudocode review, validation payload field list.
Secrets
ConfirmedRequirement
Production integrations use approved managed secret references.
Threat concern
Shared, unowned, stale, or cross-environment credentials increase lifecycle risk.
Design
Managed secret references and environment-specific access are used.
Evidence
Secrets register, ownership, rotation, environment metadata.
Dependencies
ConditionalRequirement
Business-critical dependencies have owner, source, version, support status, and review trigger.
Threat concern
Unsupported or unvalidated dependency changes can weaken release confidence.
Design
Dependency register and release gates track material components.
Evidence
Dependency inventory, supplier/source records, compatibility results.
Logging
ConfirmedRequirement
Privileged and authorization events must be auditable without exposing secrets or unnecessary private data.
Threat concern
Missing fields or degraded source health can weaken investigations and accountability.
Design
Structured audit events use actor/target/action/result/timestamp/correlation ID.
Evidence
Logging schema, redaction validation, source-health dashboard.
Resilience
ConditionalRequirement
Core record workflow remains available when notification provider is unavailable.
Threat concern
External service outage could cascade into core service failure.
Design
Notification work is queued separately from core record persistence.
Evidence
Failure-mode validation, retry state, operational logs.
Deployment
ConditionalRequirement
Release requires current blocking evidence, configuration baseline, rollback, and monitoring readiness.
Threat concern
A release could ship with stale evidence or unexpected environment drift.
Design
Release packet ties artifact identity to current review and validation evidence.
Evidence
Artifact record, configuration baseline, rollback plan, release decision.
Design Principles
What the Architecture Is Trying to Achieve
Least privilege
Users, services, dependencies, and secrets receive only the access needed for their approved purpose.
Evidence: Authorization requirements, service identities, secret scope, dependency privilege notes.
Explicit trust boundaries
The design identifies where identity, data, ownership, or control moves between different trust assumptions.
Evidence: Threat model, data-flow diagram, external integration review.
Traceable requirements
Important security behavior can be traced from requirement to design, review, validation, release, and maintenance.
Evidence: Requirement IDs linked across all A11 artifacts.
Safe failure
Dependency and application failures should preserve integrity and avoid expanding privilege or data exposure.
Evidence: Error design, resilience validation, rollback behavior.
Evidence-based confidence
Claims are based on current supplied evidence and limitations remain visible.
Evidence: Confirmed, Conditional, Unknown, and Blocking statuses.
Lifecycle ownership
Security responsibilities remain assigned after release for secrets, dependencies, logs, exceptions, and retirement.
Evidence: Owner fields, review dates, change triggers, closure criteria.
Vocabulary
Capstone Architecture Terms
Architecture assessment
A structured review of how software requirements, components, trust boundaries, controls, evidence, ownership, and residual risk fit together.
Design rationale
The reasoning that explains why a particular architecture decision was chosen and what requirement or risk it addresses.
Residual risk
Risk remaining after safeguards, evidence, validation, and exceptions are considered.
Evidence conflict
A situation where two pieces of evidence disagree or describe different versions, environments, configurations, or assumptions.
Traceability
The ability to follow a security requirement through design, implementation, review, validation, deployment, and maintenance.
Design exception
A governed, time-bounded acceptance of a condition that does not meet the normal architecture standard.
Decision record
A concise document explaining the decision, evidence, assumptions, alternatives, owner, and review trigger.
Security debt
Deferred security work that creates future maintenance, evidence, or risk-management burden.
Control objective
The security outcome a safeguard is intended to achieve.
Evidence freshness
Whether evidence still matches the current artifact, configuration, dependency, role, or environment.
Release confidence
The degree to which current evidence supports the claim that the release meets defined security expectations.
Change trigger
A future condition that requires architecture, requirement, threat, validation, or release evidence to be reviewed again.
Portfolio Integration
How the Nine Earlier Artifacts Fit Together
| Lesson | Artifact | Contribution |
|---|---|---|
| A11.1 | Lifecycle Security Map | Shows where security ownership, evidence, and review occur from planning through retirement. |
| A11.2 | Secure Requirements Register | Defines expected security behavior, owners, evidence, acceptance criteria, and change triggers. |
| A11.3 | Software Threat Model | Maps assets, trust boundaries, concerns, controls, evidence, priorities, and uncertainty. |
| A11.4 | Secrets Governance Model | Documents metadata-only ownership, purpose, environment, scope, rotation, monitoring, and retirement. |
| A11.5 | Dependency Risk Register | Tracks source, version, support, ownership, runtime use, exception, validation, and retirement. |
| A11.6 | Error and Logging Design | Defines safe user messages, audit evidence, redaction, correlation, retention, and source health. |
| A11.7 | Security Code Review Register | Connects implementation evidence to requirements, findings, confidence, owners, and closure conditions. |
| A11.8 | Security Validation Matrix | Shows expected outcomes, synthetic fixtures, evidence, stop conditions, limitations, and release impact. |
| A11.9 | Deployment Readiness Record | Brings artifact identity, configuration, access, dependencies, monitoring, rollback, and release decision together. |
Fake Dashboard
A11 Secure Software Design Assessment Dashboard
Fictional capstone evidence
Integrated artifacts
9 / 9
All A11 portfolio artifacts represented in capstone
Architecture areas
8
Identity, authorization, data, secrets, dependencies, logging, resilience, deployment
Open residual risks
5
1 currently release-blocking
Traceability
94%
Temporary counselor role and DEP-02 need stronger closure evidence
Fake SOC Alert
Capstone Release Blocker
Source: Fictional Architecture Assessment • Time: 15:50
DEP-02 messaging client compatibility evidence is missing for release candidate NB-PORTAL-11.10-RC1. The release policy treats this as a mandatory gate.
Defensive recommendation: Keep the final release recommendation on Hold until current authorized compatibility evidence is attached or the gate is resolved through valid governance.
Evidence Consistency
Find and Resolve Conflicts Across Artifacts
A capstone review should actively look for contradictions. A strong document can still be wrong if one section references an old artifact, a different role, or stale evidence.
EC-01
Conflict
Dependency register says DEP-02 compatibility is Unknown, while an old release note says the update was validated.
Why it matters
The old release note belongs to a previous candidate build and should not be treated as current evidence.
Resolution
Keep current DEP-02 status Unknown until compatibility evidence matching NB-PORTAL-11.10-RC1 is attached.
EC-02
Conflict
Threat model says temporary counselor role requires re-review, but the current authorization test matrix covers only the standard counselor role.
Why it matters
A new role changes privilege and assignment assumptions.
Resolution
Add the temporary role to requirements, threat model, code review, and validation before release if the role is included.
EC-03
Conflict
Secrets register lists all production records owned, but one legacy maintenance credential is still marked Blocked.
Why it matters
The blocked credential is outside the current release path but remains architecture debt.
Resolution
Keep the release scope explicit and retain the migration/retirement requirement rather than pretending the debt is resolved.
EC-04
Conflict
Logging design requires correlation IDs across critical workflows, but legacy report events do not include one.
Why it matters
Cross-service traceability is weaker for that workflow.
Resolution
Keep LOG-06 Conditional and include correlation support in the report-renderer replacement plan.
Fake Log Panel
Fictional Capstone Decision Log
training-log-viewer.log
[15:05] CAPSTONE artifact=NB-PORTAL-11.10-RC1 requirements=LOADED [15:14] TRACE REQ-AUTHZ-03 -> TM-01 -> CR-01 -> VAL-01/02 status=CONDITIONAL [15:22] TRACE REQ-DATA-02 -> TM-02 -> CR-03 -> VAL-04 status=CONFIRMED [15:31] RISK RISK-02 dependency=DEP-02 validation=MISSING residual=HIGH [15:42] CONFLICT EC-02 temporary-counselor coverage=INCOMPLETE [15:50] RELEASE blocker=DEP-02_COMPATIBILITY [16:02] CAPSTONE recommendation=HOLD_UNTIL_BLOCKER_RESOLVED
Training note: this is fake data for defensive analysis practice only.
Residual Risk
Strong Controls Do Not Mean Zero Risk
The final assessment should state what remains unresolved, who owns it, and what future evidence or change closes it.
RISK-01Residual: Medium
Authorization freshness
Condition / impact
Assignment data may become stale before synchronization completes.
A counselor could temporarily receive access inconsistent with the intended assignment rule.
Control / evidence
Central authorization service, assignment source, denial audit, change-trigger review.
Normal positive/negative tests passed; delayed-update evidence is incomplete.
Owner
Application Owner + Assignment Data Owner
Next action
Complete stale-assignment validation and define synchronization behavior.
RISK-02Residual: High until resolved
Messaging dependency
Condition / impact
Candidate dependency update lacks compatibility evidence for the current release candidate.
Queue, retry, or failure behavior may differ from the approved design.
Control / evidence
Dependency release gate and rollback plan.
Version is known; validation is missing.
Owner
Notification Service Team
Next action
Attach current authorized compatibility validation or hold the release.
RISK-03Residual: Medium
Legacy report renderer
Condition / impact
Support ends this quarter.
Maintenance and response capability may degrade.
Control / evidence
Time-bounded exception, monitoring, migration project.
Migration target and exception are current.
Owner
Reporting Team
Next action
Complete replacement and close exception before expiration.
RISK-04Residual: Low to Medium
Logging traceability
Condition / impact
Legacy report workflow lacks correlation ID.
Multi-service troubleshooting and investigation are slower and less reliable.
Control / evidence
Other event metadata remains available.
LOG-06 review identifies the gap.
Owner
Reporting Team + Monitoring Owner
Next action
Add correlation support during renderer replacement.
RISK-05Residual: High if included in release
Temporary counselor role
Condition / impact
Role is proposed but not fully represented in requirements and validation.
Authorization assumptions could be incomplete if the role ships.
Control / evidence
Change-trigger policy.
Role is identified in threat model; current test matrix does not cover it.
Owner
Product Owner + Identity Owner
Next action
Exclude from release or complete full requirement/design/review/validation chain.
Analyze the Evidence
Evidence Analysis: Current Release Recommendation
Artifact NB-PORTAL-11.10-RC1 is identified and linked to current review evidence.
Most requirements and architecture areas are Confirmed or Conditional with owned follow-up.
DEP-02 compatibility validation is missing for the current candidate.
The fictional release policy defines that compatibility result as a mandatory release gate.
Monitoring and rollback evidence are current.
What recommendation is best supported by the capstone evidence?
Architecture Decision Records
Preserve Why the Design Looks This Way
Future teams need more than the final diagram. They need the reason important decisions were made, the evidence behind them, the tradeoffs accepted, and the changes that should trigger re-review.
ADR-SEC-01
Use central assignment-based authorization
Rationale
Assignment rules should be enforced consistently by a trusted service rather than duplicated across clients.
Alternatives
Client-only visibility rules; direct record ownership checks in each feature.
Evidence
REQ-AUTHZ-03, TM-01, CR-01, VAL-01, VAL-02.
Tradeoff / trigger
The design depends on assignment-source freshness and service availability.
Re-review when: New counselor role, assignment-source change, authorization service redesign.
ADR-SEC-02
Keep external scheduling payload minimal
Rationale
The integration needs appointment coordination, not counseling-note content.
Alternatives
Send broader record payload; allow vendor-driven field expansion.
Evidence
REQ-DATA-02, TM-02, CR-03, VAL-04.
Tradeoff / trigger
Future scheduling features may require renewed purpose and data review.
Re-review when: New vendor field, new scheduling feature, supplier migration.
ADR-SEC-03
Use managed secret references
Rationale
Centralized secret governance reduces uncontrolled copying and supports ownership, rotation, and environment separation.
Alternatives
Embedded values; shared configuration files; long-lived shared credentials.
Evidence
A11.4 secrets register, CR-04, deployment metadata.
Tradeoff / trigger
Availability and permission of the managed secret system become architecture dependencies.
Re-review when: Secret platform change, workload identity migration, new environment.
ADR-SEC-04
Treat monitoring source health as release evidence
Rationale
A quiet dashboard is not trustworthy when the source itself is stale or degraded.
Alternatives
Assume no events means no activity.
Evidence
A11.6 source-health model and A11.9 monitoring readiness.
Tradeoff / trigger
Additional operational ownership and alerting are required.
Re-review when: Logging platform migration, parser change, new critical event source.
Capstone Review Questions
Questions That Reveal Whether the Design Is Coherent
1
Do the requirements describe the same system and release candidate as the later evidence?
2
Do threat concerns map to actual architecture boundaries and controls?
3
Do secret records match the environments and services in the architecture?
4
Do dependency records match the artifact and release packet?
5
Do code-review findings link to current requirements?
6
Do validation cases test the requirements and findings they claim to test?
7
Do logging requirements produce evidence useful to the threat model and release decision?
8
Does deployment readiness include the exact artifact reviewed and tested?
9
Are exceptions current and time-bounded?
10
Are stale or conflicting records labeled clearly?
11
Are Unknowns assigned to owners?
12
Are residual risks visible after controls are considered?
13
Do change triggers cover new roles, dependencies, vendors, data flows, and deployment changes?
14
Does the final recommendation follow the evidence and release policy?
Scenario Decision Lab
Scenario Decision Lab 1 — One Blocking Dependency Gap
The fictional capstone assessment is strong across identity, data minimization, secrets, logging, rollback, and monitoring. DEP-02 compatibility evidence for the current release candidate is still missing, and policy marks it as mandatory.
Scenario Decision Lab
Scenario Decision Lab 2 — New Temporary Counselor Role
A temporary counselor role is now requested for the same release. Existing requirements, threat-model evidence, and validation cover only the standard counselor role.
Safe Capstone Lab
Build the Secure Software Design Assessment
Combine your nine A11 portfolio artifacts into one final assessment. You do not need to repeat every page. Summarize the evidence that matters to the architecture decision.
1
Write a one-paragraph executive summary.
2
Describe the fictional application, users, data, dependencies, and external services.
3
Summarize the most important security requirements.
4
Summarize key trust boundaries and threat concerns.
5
Summarize secrets governance and dependency governance.
6
Summarize logging and error-handling architecture.
7
Summarize code-review findings and confidence.
8
Summarize validation evidence and limitations.
9
Summarize deployment readiness and release blockers.
10
Identify evidence conflicts or stale records.
11
Create a residual-risk register.
12
Create at least three architecture decision records.
13
Assign owners to every open item.
14
Define change triggers.
15
Give a final Release, Hold, Conditional Release, or Remediate recommendation.
16
Explain why the recommendation follows from the evidence.
Capstone boundary
Use fictional architecture and synthetic evidence only. Do not include real credentials, production diagrams, private source code, internal endpoints, real user records, or offensive test procedures.
Analyze the Evidence
Evidence Analysis: Temporary Role Change
Current requirement REQ-AUTHZ-03 covers the standard counselor role.
The threat model previously identified new roles as change triggers.
The current code-review and validation evidence does not cover the temporary role.
The role may use a different approval owner and shorter assignment period.
How should the capstone treat the new temporary counselor role?
Advanced Challenge
Write the Final Executive Architecture Recommendation
Write a 250–400 word fictional executive recommendation that could be read by engineering, security, operations, and leadership.
1
System and release candidate
2
Overall architecture confidence
3
Strongest confirmed controls
4
Most important residual risks
5
Blocking evidence gaps
6
Approved exceptions
7
Evidence conflicts resolved
8
Ownership of open items
9
Release recommendation
10
Conditions for changing the recommendation
11
Post-release obligations
12
Future change triggers
The goal is to sound precise, not dramatic. State what the evidence supports, what remains unresolved, and what action should follow.
Defender Habits
A11.10 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A11.10 Mini Quiz: Secure Software Design Lab
Choose your answers first. Explanations appear only after submission.
1. What is the main purpose of the A11 Secure Software Design Assessment?
2. Two pieces of evidence refer to different release candidates. What should the reviewer do?
3. A threat-model concern is still Conditional. Does that automatically block release?
4. What is the strongest response to a new role that is not covered by existing authorization validation?
5. Why should residual risk remain visible in the final assessment?
6. What makes a strong architecture decision record?
7. The final capstone has one mandatory blocking evidence gap. What is the strongest recommendation?
Portfolio Prompt
Final A11 Portfolio — Secure Software Design Assessment
Produce the final A11 portfolio artifact: a polished Secure Software Design Assessment for the fictional Northbridge Student Services Portal. Integrate the nine earlier artifacts into one coherent assessment covering lifecycle ownership, requirements, architecture, threat model, secrets, dependencies, logging, code review, validation, deployment readiness, evidence conflicts, residual risk, architecture decisions, owners, change triggers, and final release recommendation.
Use one coherent fictional release candidate throughout the assessment.
Do not copy all nine earlier artifacts in full; summarize the most decision-relevant evidence.
Include an executive summary, architecture overview, evidence table, residual-risk register, and final decision.
Resolve stale or conflicting evidence explicitly.
Keep Unknown and Conditional statuses visible.
Use fictional names, synthetic identifiers, and metadata-only sensitive records so the portfolio is safe to share publicly.
Confidence / Readiness Reflection
Are You Ready for the A11 Module Test?
The module test will check whether you can reason across the entire secure software architecture lifecycle rather than memorizing isolated terms.
1
I can trace a security requirement from lifecycle planning through deployment evidence.
2
I can explain how threat models, secrets, dependencies, logging, and code review influence architecture decisions.
3
I can interpret validation and release evidence without overstating what it proves.
4
I can identify residual risk, stale evidence, evidence conflicts, and change triggers.
5
I can make a defensible release recommendation from a fictional evidence packet.
Portfolio Build Guide
How to Present the Final A11 Assessment
Open with an executive summary
State the system, release candidate, strongest controls, major residual risks, and final recommendation.
Use traceability
Reference requirement, threat, review, validation, and release IDs so the evidence chain is visible.
Show architecture decisions
Explain why important choices were made and what tradeoffs they create.
Show evidence quality
Label evidence as current, stale, Conditional, Unknown, or Blocking when appropriate.
Show residual risk
Do not hide what remains after controls are applied.
Show ownership
Every open risk, exception, migration, and retest should have an accountable owner.
Show change triggers
Identify the roles, dependencies, vendors, data uses, or architecture changes that require renewed review.
Keep it publicly safe
Use fictional names, synthetic identifiers, and no real secrets, private data, source code, or internal infrastructure details.
Key Takeaways
What You Should Remember
1.Secure software architecture is a connected system of requirements, design decisions, evidence, ownership, and lifecycle controls.
2.The strongest assessment checks whether all artifacts tell a consistent story about the same software and release candidate.
3.Evidence conflicts, stale records, missing ownership, and Unknowns should be made visible rather than hidden.
4.Residual risk remains even when many controls are strong.
5.Architecture decision records preserve rationale, alternatives, tradeoffs, and change triggers.
6.A release recommendation should follow the defined policy and current evidence, not schedule pressure.
7.Traceability lets teams explain why a control exists and what evidence supports it.
8.Security debt should have owners, target states, and closure criteria.
9.The final A11 portfolio should be safe to share because it uses fictional systems, synthetic identifiers, and metadata-only sensitive records.
10.A11.10 prepares you for the A11 Module Test and for later Advanced architecture modules.
Lesson Safety Boundary
The capstone is an architecture assessment, not a real-system test
Do not use real credentials, private data, production systems, internal endpoints, confidential repositories, or offensive procedures. Keep the entire A11 assessment fictional, defensive, and safe to share.
Lesson Complete
A11.10 Secure Software Design Lab Complete
You have completed all ten A11 lessons and built the full Secure Software Design Assessment. The next page is the A11 Module Test, covering lifecycle security, requirements, threat modeling, secrets, dependencies, logging, code review, safe validation, deployment, and integrated architecture decisions.