Primary Question
How do teams design, build, review, test, and release software so security is part of the lifecycle?
High School AdvancedModule A1110 Lessons + Module TestApplication, Cloud & Identity
Secure Software Architecture
Build Security Into Software Before Release Day
Secure software is not created by adding one security check at the end. It comes from a lifecycle where product goals, design requirements, threat models, dependencies, secrets, logging, review, testing, deployment, and maintenance support the same defensive expectations.
A11 teaches you to review software as a connected system of decisions. You will practice asking whether requirements are clear, whether architecture supports them, whether evidence is strong enough, whether dependencies and secrets are governed, and whether release risk is understood before software moves forward.
Module Snapshot
What A11 Adds to the Advanced Track
A10 focused on defensive web architecture. A11 expands the view to the full software lifecycle: how secure intent becomes requirements, design, review evidence, validation, release decisions, maintenance, and governance.
Main Focus
Lifecycle, design requirements, dependencies, secrets, review, testing, deployment, and risk decisions.
Portfolio
Secure Software Design Assessment
Assessment
25 questions across all A11 lessons.
Module Professional Meaning
The Main Question and Safety Boundary
Software security professionals need technical depth, but professional work still depends on authorization, scope, privacy, change control, evidence, and responsible communication.
Main Question
Can we explain why this software should be trusted to perform its intended job safely?
A strong answer connects requirements, architecture, implementation evidence, dependency choices, secrets governance, logging, review, validation, deployment, and operational learning. It also makes uncertainty visible instead of pretending every risk has disappeared.
Safety Boundary
Defensive architecture and review only
A11 uses fictional systems, inert pseudocode, supplied evidence, metadata-only secret records, and safe design exercises. It does not authorize scanning, probing, exploit development, credential attacks, bypass testing, fuzzing, destructive testing, or testing real software without permission.
Module Entry Readiness
What You Should Bring Into A11
You do not need professional software-engineering experience. The goal is to practice security reasoning and design review, not to build or attack a production application.
Architecture thinking
RequiredYou should be comfortable reasoning about components, trust boundaries, identities, authorization, APIs, configuration, logging, and monitoring from earlier Advanced modules.
Threat modeling
ReusedA11 reuses the risk-question approach from A3, but now applies it directly to software lifecycle and design decisions.
Web defense foundations
ReusedA10 authentication, authorization, API, secrets, input/output, browser, and monitoring concepts become inputs to secure software architecture.
Offensive testing
Not requiredThis module does not require scanning, probing, exploit development, credential attacks, bypass testing, or testing real applications.
Professional Workflow
Five Steps for Secure Software Decisions
The workflow is deliberately repeatable so a reviewer can show how evidence moves from understanding the system to requirements, architecture, validation, release, and continuous improvement.
Understand the software and its purpose
Start with users, business goals, important data, components, trust boundaries, dependencies, environments, privileged actions, and operational expectations. Security decisions are only meaningful when the intended behavior is clear.
Turn goals into secure design requirements
Translate ideas such as least privilege, privacy, integrity, resilience, safe defaults, auditability, and secure change into requirements with owners, evidence, scope, and acceptance conditions.
Review architecture and implementation evidence
Compare design decisions against requirements using threat models, dependency records, configuration summaries, code-review evidence, logging design, error handling, and documented assumptions.
Validate before release
Require safe evidence that security expectations were checked in authorized environments, important changes were reviewed, deployment controls are ready, and unresolved risk is visible.
Operate, learn, and improve
Monitoring, maintenance, dependency updates, configuration changes, incidents, and new requirements feed back into the next lifecycle decision.
Learning Outcomes
Six Capabilities You Will Build
By the end of A11, you should be able to move beyond isolated controls and reason about whether software security is supported across the complete development and release process.
Explain how security fits across the full software lifecycle instead of appearing only at the end.
Write secure design requirements that can be assigned, reviewed, validated, and governed.
Use software threat modeling to connect assets, trust boundaries, assumptions, risks, and controls.
Evaluate secrets, dependencies, error handling, logging, and code-review evidence as architecture concerns.
Design safe validation and deployment-readiness processes using fictional or explicitly authorized evidence only.
Produce a professional Secure Software Design Assessment with findings, priorities, owners, validation needs, and residual risk.
Role Readiness Preview
How Different Professionals Read the Same Design
Secure software architecture is collaborative. Different roles ask different questions, but strong teams connect those questions through shared evidence and explicit ownership.
Security Architect
Can the design explain where trust begins and ends, which controls protect important actions, and which assumptions still need evidence?
Software Engineer
Can implementation choices be traced back to requirements, reviewed safely, tested, maintained, and deployed with clear ownership?
Application Security Reviewer
Can you identify design gaps from supplied evidence without turning the review into unauthorized offensive testing?
Release Engineer
Can you decide whether artifacts, configuration, monitoring, rollback, approvals, and validation evidence are ready for release?
Risk Owner
Can you understand what is known, what remains uncertain, which risks are accepted, and what evidence is still required?
Security Program Lead
Can you build repeatable security gates and feedback loops that improve software without making delivery impossible?
Lesson Roadmap
A11.1–A11.10
Each lesson contributes to the final Secure Software Design Assessment. Complete them in order so later lessons can reuse the requirements, evidence models, review habits, and decision frameworks built earlier.
Lesson
A11.1
Step 1 of 10
Security in the Software Lifecycle
Focus
Understand where security belongs across planning, design, implementation, review, testing, release, operation, maintenance, and retirement.
Defensive Lab
Map security questions, evidence, owners, and decision points across a fictional software lifecycle.
Portfolio Contribution
A lifecycle security map that connects early design choices to later validation and operational learning.
Lesson
A11.2
Step 2 of 10
Secure Design Requirements
Focus
Turn broad security goals into clear requirements for identity, authorization, data handling, logging, resilience, configuration, and change.
Defensive Lab
Convert a fictional product brief into measurable security requirements with owners and evidence expectations.
Portfolio Contribution
A secure requirements register separating goals, assumptions, constraints, and acceptance evidence.
Lesson
A11.3
Step 3 of 10
Threat Modeling for Software
Focus
Apply threat-modeling reasoning to components, trust boundaries, data flows, dependencies, privileged actions, assumptions, and defensive controls.
Defensive Lab
Review a supplied fictional architecture and record assets, trust boundaries, risk statements, safeguards, and Unknowns.
Portfolio Contribution
A bounded software threat model supporting design decisions without offensive testing.
Lesson
A11.4
Step 4 of 10
Secrets Management Concepts
Focus
Study how teams govern credentials, keys, tokens, and sensitive configuration through ownership, storage boundaries, access, rotation, and redaction.
Defensive Lab
Review metadata-only fictional secret records and design safer ownership, separation, rotation, and monitoring.
Portfolio Contribution
A secrets governance model that never exposes or tests real secret values.
Lesson
A11.5
Step 5 of 10
Dependency and Supply Chain Risk Concepts
Focus
Understand how libraries, packages, build tools, vendors, registries, versions, provenance, maintenance, and update paths affect software risk.
Defensive Lab
Analyze a fictional dependency inventory and prioritize governance actions using impact, maintenance, exposure, provenance, and replacement difficulty.
Portfolio Contribution
A dependency risk register and supply-chain review workflow focused on prevention and governance.
Lesson
A11.6
Step 6 of 10
Secure Error Handling and Logging
Focus
Design user-facing errors and defender-facing logging so both are useful without exposing unnecessary sensitive information.
Defensive Lab
Classify fictional events into user messages, operational logs, security telemetry, and protected diagnostic channels.
Portfolio Contribution
An error-and-logging design balancing usability, privacy, observability, and investigation needs.
Lesson
A11.7
Step 7 of 10
Code Review for Security
Focus
Learn how security-focused code review checks design intent, trust boundaries, authorization assumptions, data handling, dependencies, errors, and configuration.
Defensive Lab
Review inert pseudocode and fictional design notes, recording findings, questions, owners, and required evidence.
Portfolio Contribution
A security code-review checklist and bounded finding register for defensive peer review.
Lesson
A11.8
Step 8 of 10
Testing Security Requirements Safely
Focus
Connect security requirements to safe validation using test environments, expected results, configuration review, integration evidence, and release criteria.
Defensive Lab
Create a fictional security validation plan with boundaries, expected results, owners, evidence needs, and stop conditions.
Portfolio Contribution
A safe requirements-validation matrix with no live-system probing or exploit procedures.
Lesson
A11.9
Step 9 of 10
Secure Deployment Concepts
Focus
Study artifact approval, environment separation, configuration baselines, change control, rollback, monitoring, access, and post-release validation.
Defensive Lab
Review a fictional release packet and classify evidence as sufficient, missing, stale, or blocking.
Portfolio Contribution
A secure deployment readiness checklist and release decision record.
Lesson
A11.10
Step 10 of 10
Secure Software Design Lab
Focus
Integrate lifecycle, requirements, threat modeling, secrets, dependencies, logging, code review, testing, deployment, and governance.
Defensive Lab
Complete a fictional capstone assessment using supplied architecture, requirements, dependency records, review notes, and release evidence.
Portfolio Contribution
The portfolio-ready Secure Software Design Assessment.
Fictional Evidence Preview
What a Software Architecture Review Might Receive
A11 repeatedly separates observation from interpretation. You will work from supplied evidence, record what it actually supports, and mark Unknowns when evidence is missing.
| ID | Source | Observation | Review Question |
|---|---|---|---|
| SSA-01 | Product requirement | The fictional service lets customers view records and lets approved staff perform higher-impact account actions. | Which security requirements should differ between ordinary customer access and privileged staff actions? |
| SSA-02 | Architecture diagram | The design includes a browser client, application service, identity provider, API layer, database, logging service, and third-party dependency. | Where are the trust boundaries, important data flows, privileged actions, and dependency assumptions? |
| SSA-03 | Dependency inventory | One business-critical library is several versions behind the team's approved baseline and is maintained externally. | What evidence is needed before deciding whether to update, replace, isolate, or formally accept the risk? |
| SSA-04 | Release packet | A release has functional-test and code-review evidence, but one high-impact security requirement has no recorded validation result. | Should the release pause, proceed under a governed exception, or wait for additional evidence? |
Evidence discipline
A missing fact should not become an invented conclusion. “Unknown,” “not supplied,” “not yet validated,” and “requires owner confirmation” are professional outcomes when the evidence does not support a stronger claim.
Decision Preview
Architecture Is a Series of Defensible Decisions
The goal is not to memorize one perfect pattern. The goal is to make decisions that can be explained using requirements, evidence, constraints, ownership, uncertainty, and validation.
Requirement decision
A team writes, “The application must be secure.” Is that enough?
Strong approach: No. Convert the goal into specific requirements with scope, owner, rationale, expected evidence, and acceptance conditions.
Dependency decision
A dependency is old but stable. Should the team automatically update it or automatically leave it alone?
Strong approach: Neither. Review maintenance, provenance, exposure, compatibility, validation evidence, replacement options, and rollback before deciding.
Release decision
A deadline has arrived, but a high-impact requirement has no validation evidence. What should happen?
Strong approach: Make the missing evidence visible, identify the accountable risk owner, and use the formal release or exception process rather than hiding uncertainty.
Portfolio Outcome
Secure Software Design Assessment
The A11 portfolio is not a vulnerability report. It is a structured defensive architecture assessment showing how lifecycle, requirements, evidence, validation, deployment, and residual risk connect.
Section 1
System and lifecycle context
Summarize the fictional product, users, important data, components, environments, trust boundaries, dependencies, and lifecycle stages.
Section 2
Security requirements register
Record requirements with rationale, scope, owner, expected evidence, acceptance criteria, dependencies, and status.
Section 3
Software threat model
Document assets, trust boundaries, data flows, assumptions, misuse concerns, existing controls, planned controls, and Unknowns.
Section 4
Secrets and dependency review
Assess metadata-only secret governance plus important library, package, vendor, registry, build, version, and update risks.
Section 5
Review and validation evidence
Summarize code-review findings, security-test coverage, logging/error behavior, configuration evidence, and gaps.
Section 6
Deployment readiness
Record artifact approval, environment controls, configuration baseline, monitoring, rollback, blockers, exceptions, and post-release checks.
Section 7
Findings and priorities
Separate observation, interpretation, potential impact, uncertainty, owner, recommended action, and validation requirement.
Section 8
Executive summary
Explain the strongest controls, most important risks, unresolved Unknowns, release posture, and next actions in clear language.
Public-Safe Portfolio Version
Show the reasoning without exposing sensitive implementation details
Use fictional names, abstract architecture, synthetic evidence, generic dependency labels, metadata-only configuration examples, and no real credentials, private endpoints, customer information, proprietary source code, or internal vulnerabilities.
Risk Preview
Common Secure-Software Failure Patterns
These are defensive architecture and governance problems. A11 teaches you how to reduce them through better lifecycle design, evidence, ownership, and review.
Risk
Security added too late
Weak approach
Wait until release week for one final security review.
Stronger approach
Place requirements, review questions, evidence, and checkpoints throughout the lifecycle.
Risk
Unclear requirements
Weak approach
Use broad statements such as “secure authentication” without defining expected behavior.
Stronger approach
State scope, owner, rationale, expected behavior, evidence, and acceptance criteria.
Risk
Dependency blindness
Weak approach
Treat third-party packages as invisible implementation details.
Stronger approach
Track important dependencies, versions, provenance, maintenance, update paths, and replacement risk.
Risk
Unsafe logging
Weak approach
Log everything because more information always seems better.
Stronger approach
Record useful security events while minimizing sensitive data and defining access, retention, and redaction.
Risk
Release by deadline alone
Weak approach
Treat the calendar as proof that the software is ready.
Stronger approach
Use release criteria, evidence, exceptions, rollback, monitoring, and accountable risk decisions.
Conceptual Boundaries
What A11 Practices — and What It Does Not
These boundaries keep the module useful, ethical, defensive, and school-appropriate.
In scope
Review fictional architecture diagrams, requirements, dependency metadata, release evidence, and inert pseudocode.
Out of scope
Scan, probe, attack, or test a real application, account, API, repository, device, or network.
In scope
Discuss threat models, misuse concerns, secure design requirements, and defensive controls conceptually.
Out of scope
Create exploit payloads, bypass procedures, credential attacks, privilege-escalation instructions, or offensive automation.
In scope
Use metadata-only fictional secret records and configuration summaries.
Out of scope
Expose, retrieve, validate, test, or use real passwords, tokens, keys, cookies, or credentials.
In scope
Create safe validation plans using expected outcomes, fictional evidence, and authorized test boundaries.
Out of scope
Provide live-system fuzzing, enumeration, exploitation, authentication bypass, or destructive-testing instructions.
Module Test
A11 Secure Software Architecture — 25 Questions
After all ten lessons, the test checks whether you can connect software lifecycle security, design requirements, threat modeling, secrets, dependency risk, logging, code review, safe validation, and deployment decisions.
Assessment Coverage
From secure intent to release evidence
Expect questions about SDLC security, secure requirements, software threat models, secrets, dependencies, error handling, logging, code review, safe testing strategy, deployment readiness, evidence quality, ownership, exceptions, and residual risk.
Module Navigation
Start A11
Begin with the lifecycle. Every later lesson depends on understanding when security decisions are made, who owns them, what evidence they require, and how they feed the next stage.
After A11
A12 — Cloud Security Architecture
A12 extends the architecture mindset into cloud identity, storage, networks, logging, secrets, resilience, configuration, and governance.
Preview A12 route