Trace
Connect the code change back to requirements, design decisions, and threat-model concerns.
High School AdvancedA11.7Secure Software Architecture
Lesson A11.7
Code Review for Security
Security code review asks whether implementation evidence still matches the security requirements and architecture decisions that were approved earlier in the lifecycle.
This lesson uses inert pseudocode, fictional review notes, synthetic identifiers, and safe metadata. It does not teach exploitation, bypass techniques, malicious payloads, or unauthorized testing.
Lesson Progress
Code Review for Security
High School Advanced • A11: Secure Software Architecture • Lesson 7 of 10
70% complete
Readiness Check
A11.7 Entry Readiness
0/4 ready
Professional Hook
A Passing Build Does Not Prove Secure Behavior
Imagine a fictional feature compiles successfully, passes its ordinary functional tests, and looks clean. That still does not tell a security reviewer whether authorization is enforced in the trusted component, whether the feature returns too much private data, whether secrets are handled correctly, whether important actions are logged, or whether a changed dependency has current validation.
Security code review adds one question to the development process: does the implementation still match the secure design?
Review the code against the requirement — not against intuition.
Learning Objectives
Five Capabilities for This Lesson
1
Explain how security-focused code review verifies that implementation still matches approved security requirements and architecture intent.
2
Review fictional code-like pseudocode and design notes for authorization, input handling, data minimization, secret handling, logging, dependency, configuration, and error-handling concerns.
3
Separate observed implementation evidence from interpretation, risk, and required follow-up.
4
Write bounded security review findings with evidence, confidence, owner, recommendation, and validation needs.
5
Build a security code-review checklist and finding register that becomes the seventh artifact in the A11 Secure Software Design Assessment.
Why It Matters
Implementation Can Drift From Design
Secure requirements may be correct and the architecture may be strong, but implementation choices can still drift. A shortcut can move authorization to the wrong place. A new field can expand data sharing. A debug statement can expose private information. A dependency update can change behavior. An error handler can reveal internal detail.
Observe
Record exactly what the supplied implementation evidence shows.
Validate
Identify what code review cannot prove and require the right follow-up evidence.
Core Framework
Seven Steps for Security-Focused Code Review
01
Understand the change
What feature, bug fix, refactor, dependency update, or configuration change is being reviewed?
Start with the change purpose, affected components, relevant requirements, expected behavior, and whether the change affects a trust boundary, privileged action, data flow, secret, dependency, or logging path.
Evidence: Change request, requirement IDs, architecture note, design decision, pull-request summary.
02
Identify security expectations
Which A11 requirements should this change satisfy?
Map the change to identity, authorization, data handling, logging, resilience, configuration, dependency, secret, and release requirements before reading implementation evidence.
Evidence: Requirements register, threat model, secrets register, dependency register, logging design.
03
Trace sensitive paths
Where does identity, privilege, private data, configuration, or sensitive state move through the change?
Review the intended path from input to authorization decision, data access, state change, logging, and response without attempting to exploit the software.
Evidence: Inert pseudocode, safe implementation notes, data-flow map, function responsibilities.
04
Check defensive boundaries
Does the implementation preserve expected trust boundaries and least privilege?
Look for server-side authorization, safe defaults, narrow data access, secret references instead of values, approved dependencies, bounded errors, and required audit events.
Evidence: Review notes, pseudocode, configuration metadata, dependency metadata, logging schema.
05
Record findings
What does the evidence support, and what remains uncertain?
Separate observation from interpretation. Use statuses such as Confirmed, Conditional, Unknown, Needs Change, or Not Applicable instead of overstating certainty.
Evidence: Finding register, evidence references, reviewer notes.
06
Require validation
How will the team prove the final implementation meets the requirement?
Code review can support implementation claims, but safe authorized testing, configuration review, dependency evidence, and release validation may still be needed.
Evidence: Validation plan, test case IDs, configuration review, release checklist.
07
Close the review
Who owns each finding and what evidence is required for closure?
Assign an owner, remediation or clarification action, validation evidence, target stage, and residual risk or exception status.
Evidence: Closure record, owner sign-off, retest result, exception record.
Review Domains
Eight Areas to Check Consistently
AUTHZ
Authorization
Confirm protected actions use the approved authorization path and do not rely only on interface visibility or client-side checks.
Which requirement defines the allowed action?
Where is authorization enforced?
What identity, role, assignment, ownership, or workflow state is checked?
What happens when the decision is deny or Unknown?
DATA
Data handling
Check that the implementation uses the minimum data needed for the approved purpose and preserves expected data boundaries.
Which fields are read, written, returned, or shared?
Is the data purpose consistent with the requirement?
Are private fields unnecessarily copied or logged?
Does the change alter retention or export behavior?
INPUT
Input and output safety
Review how expected data is validated, normalized, rejected, encoded, or safely passed between components without providing harmful payloads.
What input shape is expected?
What happens to invalid input?
Does the output expose unnecessary internal detail?
Are boundary decisions made in the correct trusted component?
SECRET
Secrets and credentials
Confirm the change references approved secret mechanisms and does not embed or expose secret values.
Does the implementation request a managed secret reference or workload identity?
Are secret values excluded from source, errors, logs, and examples?
Is environment scope clear?
Does the change affect rotation or retirement dependencies?
DEP
Dependencies
Review new or changed packages, services, SDKs, or build components for approved source, ownership, support, and intended runtime role.
Why is the dependency needed?
Is the source approved?
Who owns update and support review?
Does the change alter runtime, privilege, or data exposure?
LOG
Logging and errors
Ensure important decisions are auditable while errors and telemetry remain privacy-aware and redacted.
Which security events should be recorded?
Are correlation IDs present where needed?
Are secret and private values excluded?
Does the user-facing error reveal internal detail?
CFG
Configuration
Check whether security behavior depends on approved settings, environment separation, feature flags, or defaults.
Which settings affect security behavior?
What is the approved baseline?
What happens when configuration is missing?
Does the change require a deployment or rollback update?
RES
Resilience and safe failure
Review whether failure preserves integrity, least privilege, and recoverability.
What dependency or state can fail?
What should remain available?
Does failure leave partial privileged state?
How is rollback or retry governed?
Vocabulary
Code-Review Terms
Security code review
A defensive review of implementation evidence to determine whether code and configuration align with security requirements and architecture intent.
Review scope
The specific change, files, functions, components, requirements, and behaviors included in a review.
Finding
A bounded review record describing an observation, why it matters, supporting evidence, owner, recommendation, and validation need.
Evidence reference
A stable pointer to the requirement, design note, pseudocode block, configuration record, or test artifact supporting a review statement.
False confidence
An unsupported belief that code is secure because it looks familiar, compiled successfully, or passed unrelated tests.
Server-side enforcement
A security decision performed in a trusted application or service component rather than relying only on user-interface behavior.
Safe default
A behavior that prefers a more restrictive or controlled outcome when required security context is missing or invalid.
Change scope
The intended boundaries of a software change, including what should and should not be affected.
Reviewer confidence
The strength of a review conclusion based on the quality and completeness of supplied evidence.
Remediation
A code, design, configuration, ownership, or process change intended to address a review finding.
Validation
Evidence gathered after implementation or remediation to show that the expected requirement behaves as intended.
Residual risk
Risk remaining after the review, remediation, controls, and validation evidence are considered.
Safe Review Evidence
Five Inert Pseudocode Examples
These examples are deliberately non-operational. They model review reasoning without exposing real source code or harmful procedures.
CR-01REQ-AUTHZ-03Conditional
Assignment-based record view
function viewRecord(user, recordRef):
assignment = AssignmentService.lookup(user.id, recordRef)
if assignment != APPROVED:
Audit.logDecision(user.ref, recordRef, 'view', 'deny')
return AccessDeniedReference()
record = RecordService.loadApprovedFields(recordRef)
Audit.logDecision(user.ref, recordRef, 'view', 'allow')
return record
Observation
Authorization appears before record retrieval, denied access is logged, and the record service returns approved fields only.
Limitation
The pseudocode does not prove AssignmentService freshness, runtime configuration, or final test behavior.
CR-02REQ-LOG-04Unknown
Privileged recovery logging
function completeRecovery(operator, target, approvalRef):
decision = RecoveryPolicy.check(operator, target, approvalRef)
if decision != ALLOW:
Audit.logRecovery(operator.ref, target.ref, 'deny', approvalRef)
return SafeDeniedMessage()
result = RecoveryService.applyApprovedChange(target)
Audit.logRecovery(operator.ref, target.ref, result, approvalRef)
return SafeResultReference(result)
Observation
The flow records approval reference and result without showing any secret or recovery-code value.
Limitation
The pseudocode does not show whether separation of duties is enforced inside RecoveryPolicy.
CR-03REQ-DATA-02Conditional
Scheduling integration data minimization
function buildSchedulingPayload(appointment):
return {
studentRef: appointment.studentRef,
date: appointment.date,
time: appointment.time
}
Observation
Only the three fields listed in the fictional requirement are present in the inert example.
Limitation
The review does not prove the deployed integration or vendor contract matches this example.
CR-04SEC-02Conditional
Secret retrieval pattern
function schedulingClient():
tokenRef = SecretProvider.reference('scheduling-prod')
return Client.withManagedCredential(tokenRef)
Observation
The example references a managed secret identifier and does not embed a credential value.
Limitation
Actual access scope, storage configuration, rotation, and environment controls require separate evidence.
CR-05LOG-04Conditional
Error response
try:
return RecordService.save(change)
catch StorageOperationError as error:
ref = Correlation.newReference()
Diagnostic.recordSanitized('StorageOperationError', ref)
return UserMessage('We could not complete the request', ref)
Observation
The user receives a bounded message and a correlation reference while sanitized diagnostics are recorded separately.
Limitation
The diagnostic schema and redaction behavior still require validation evidence.
Fake Dashboard
Northbridge Security Code Review Dashboard
Fictional review status only
Open security reviews
14
8 Confirmed, 3 Conditional, 2 Unknown, 1 Needs Change
Requirements traced
91%
Two changes lack complete requirement mapping
Findings with owners
100%
All current findings have accountable owners
Validation pending
5
Runtime, configuration, dependency, and logging evidence still required
Fake SOC Alert
Dependency Change Missing Compatibility Evidence
Source: Fictional Security Review • Time: 10:07
CHG-118 replaces the production messaging client library, but the change request does not include updated compatibility, rollback, or retry-behavior validation evidence.
Defensive recommendation: Keep the security review open until dependency metadata and authorized compatibility evidence are attached.
Finding Register
Six Example Security Review Findings
FIND-01AuthorizationConditional
Observation
The fictional viewRecord pseudocode checks AssignmentService before RecordService.loadApprovedFields.
Interpretation
The ordering is consistent with the assignment-based authorization requirement.
Risk
If assignment data is stale or the trusted service is misconfigured, the requirement may still fail.
Evidence / confidence
CR-01 + REQ-AUTHZ-03 + TM-01
Confidence: Medium
Owner
Application Owner
Recommendation
Keep the implementation pattern; validate stale-assignment and denial behavior in the authorized test plan.
FIND-02Privileged recoveryUnknown
Observation
RecoveryPolicy.check is called before the change, but the pseudocode does not show the internal separation-of-duty rule.
Interpretation
The call location is promising, but the specific privileged approval requirement is not established by this evidence.
Risk
A high-impact workflow could be reviewed as complete without proof that approval roles are separated.
Evidence / confidence
CR-02 + threat-model account-recovery concern
Confidence: Low
Owner
Identity Owner
Recommendation
Request the approved RecoveryPolicy design evidence and add a validation case before closure.
FIND-03Data minimizationConditional
Observation
The scheduling payload pseudocode includes studentRef, date, and time only.
Interpretation
The supplied example aligns with the current minimum-field requirement.
Risk
Future feature additions could silently expand the vendor payload.
Evidence / confidence
CR-03 + REQ-DATA-02
Confidence: Medium
Owner
Integration Owner
Recommendation
Require code-review trigger when new outbound fields are added and validate the final integration contract.
FIND-04SecretsConditional
Observation
The scheduling client requests a managed secret reference rather than containing a value.
Interpretation
The pattern supports the secret-management requirement at the code-review level.
Risk
Runtime permissions or environment mapping could still be broader than intended.
Evidence / confidence
CR-04 + SEC-02
Confidence: Medium
Owner
Integration Owner + Platform Owner
Recommendation
Validate runtime access scope, environment separation, and rotation metadata outside code review.
FIND-05Error handlingConditional
Observation
The catch path creates a correlation reference, records sanitized diagnostic metadata, and returns a bounded user message.
Interpretation
The implementation pattern aligns with A11.6 error-handling goals.
Risk
Sanitization effectiveness and restricted diagnostic access are not proven by pseudocode.
Evidence / confidence
CR-05 + A11.6 logging design
Confidence: Medium
Owner
Application Engineering
Recommendation
Validate the diagnostic schema and confirm forbidden values are absent.
FIND-06Dependency changeNeeds Change
Observation
A review note proposes replacing the messaging client library, but the change request does not include updated compatibility evidence.
Interpretation
The dependency change is not ready to close at code-review stage.
Risk
Retry, queue, or error behavior could change without being captured in the release evidence.
Evidence / confidence
DEP-02 + change request CHG-118
Confidence: High
Owner
Notification Service Team
Recommendation
Keep the review open until compatibility validation, rollback, and updated dependency metadata are attached.
Fake Log Panel
Fictional Security Code Review Log
training-log-viewer.log
[08:44] REVIEW CHG-116 scope=record-view authz_req=REQ-AUTHZ-03 status=CONDITIONAL [09:02] REVIEW CHG-117 recovery-policy separation_of_duty=UNKNOWN [09:19] FIND FIND-02 owner=IdentityOwner evidence-request=OPEN [09:46] REVIEW CHG-118 dependency=DEP-02 compatibility=NOT_ATTACHED [10:07] FIND FIND-06 status=NEEDS_CHANGE owner=NotificationService [10:33] REVIEW CR-05 error-redaction pattern=ALIGNED validation=PENDING [11:01] REVIEW scheduling-payload fields=3 requirement=REQ-DATA-02 status=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Review Questions
Eighteen Questions for a Repeatable Review
1
What change is being reviewed?
2
Which security requirements apply?
3
Which threat-model concerns are affected?
4
Does the change alter a trust boundary?
5
Does it change identity or authorization behavior?
6
Does it change privileged actions?
7
Does it read, write, return, export, or log sensitive data?
8
Does it introduce or alter a secret dependency?
9
Does it add or update a software dependency?
10
Does it change error handling?
11
Does it change logging or audit evidence?
12
Does it change security-sensitive configuration?
13
Does failure preserve integrity and least privilege?
14
What evidence supports the current review conclusion?
15
What remains Unknown?
16
Who owns remediation or clarification?
17
What validation is needed before release?
18
What change trigger should reopen this review later?
Analyze the Evidence
Evidence Analysis: Hidden Recovery Policy
The pseudocode calls RecoveryPolicy.check before applying the privileged recovery change.
Denied recovery attempts are logged.
The supplied evidence does not show the internal RecoveryPolicy rules.
The design requirement expects separation of duties for high-impact recovery.
What is the strongest review conclusion about the fictional recovery workflow?
Review Quality
Observation Is Not the Same as Conclusion
Strong findings make it easy for another reviewer to understand what the evidence actually showed and how the security conclusion was reached.
| Layer | Question | Example |
|---|---|---|
| Observation | What did the supplied evidence show? | The pseudocode checks assignment before loading the record. |
| Interpretation | What does that mean relative to the requirement? | The order is consistent with server-side assignment authorization. |
| Limitation | What does the evidence not prove? | Assignment freshness and deployed configuration are not established. |
| Risk | Why does the limitation matter? | Stale assignment data could produce access inconsistent with the intended rule. |
| Recommendation | What should happen next? | Validate stale-assignment behavior and denial evidence. |
| Closure | What evidence closes the finding? | Authorized validation result linked to REQ-AUTHZ-03. |
Common Mistakes
Eight Ways Security Code Reviews Lose Value
1
Reviewing without requirements
Why it fails: The reviewer can spot style issues but cannot tell whether security behavior matches approved intent.
Better approach: Start by mapping the change to security requirements and threat-model concerns.
2
Assuming client-side checks are enough
Why it fails: A visible interface restriction does not prove the trusted service enforces authorization.
Better approach: Confirm sensitive actions are enforced in the appropriate trusted component.
3
Looking only for obvious bugs
Why it fails: Security review also needs to examine ownership, data flows, logging, secrets, dependencies, configuration, and safe failure.
Better approach: Use a repeatable review checklist across multiple security domains.
4
Treating code review as final proof
Why it fails: Code review cannot prove runtime configuration, deployed artifact identity, source health, or production behavior.
Better approach: Record what the review supports and what still requires validation.
5
Writing vague findings
Why it fails: “This looks insecure†gives developers little evidence or direction.
Better approach: Separate observation, interpretation, risk, evidence, owner, recommendation, and validation.
6
Copying secrets into review comments
Why it fails: Review systems can retain content for long periods and expose it to broader audiences.
Better approach: Use secret record IDs and metadata, never secret values.
7
Ignoring dependency changes
Why it fails: A small code diff can still change runtime behavior, support status, provenance, or update risk through dependencies.
Better approach: Review dependency metadata and required compatibility evidence.
8
Overstating confidence
Why it fails: Pseudocode or a narrow diff may not represent the entire deployed behavior.
Better approach: Use bounded confidence and explicitly request missing evidence.
Scenario Decision Lab
Scenario Decision Lab 1 — Policy Function Exists, Rule Unknown
The fictional account-recovery implementation calls RecoveryPolicy.check before applying the change. Review evidence does not show whether RecoveryPolicy enforces the required separation of duties.
Scenario Decision Lab
Scenario Decision Lab 2 — Messaging Dependency Update
A fictional change updates the production messaging client library. The code diff is small, but compatibility, retry behavior, rollback, and updated dependency metadata are not attached.
Safe Fictional Lab
Perform a Security Code Review
Use only the inert pseudocode and fictional evidence supplied in this lesson. Do not inspect real repositories, applications, APIs, systems, or accounts.
1
Choose one fictional change and state the review scope.
2
List the security requirements that apply.
3
List relevant threat-model concerns.
4
Identify the trusted components and trust boundaries.
5
Review authorization behavior.
6
Review data use and minimization.
7
Review secret handling.
8
Review dependency changes.
9
Review error handling and logging.
10
Review security-sensitive configuration assumptions.
11
Write at least four findings.
12
Separate observation, interpretation, limitation, and risk.
13
Assign confidence and owner.
14
Define remediation or clarification.
15
Define the evidence required for closure.
16
Define the test or validation follow-up.
Lab boundary
Review what the fictional evidence shows. Do not turn the lab into exploit development, bypass testing, malicious payload design, credential use, or real-system probing.
Analyze the Evidence
Evidence Analysis: Managed Secret Reference
The pseudocode requests a managed secret reference called scheduling-prod.
No credential value appears in the supplied code-like example.
The evidence does not include runtime permission policy.
The evidence does not include rotation or environment-separation validation.
What is the strongest conclusion about CR-04?
Advanced Challenge
Write a Review Finding That a Developer Can Close
Create one fictional finding for a high-impact account-recovery workflow. Your finding should be specific enough that the implementation owner knows exactly what evidence or change is required.
1
Finding ID
2
Affected requirement
3
Change scope
4
Observation
5
Interpretation
6
Evidence reference
7
Limitation / Unknown
8
Security impact
9
Reviewer confidence
10
Owner
11
Recommended change or evidence request
12
Validation requirement
13
Closure condition
14
Residual risk
The strongest finding is not the most dramatic. It is the one that accurately describes the evidence and has a clear path to closure.
Defender Habits
A11.7 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A11.7 Mini Quiz: Code Review for Security
Choose your answers first. Explanations appear only after submission.
1. What should a security code reviewer understand before reviewing implementation evidence?
2. Why is a client-side access restriction not enough to prove authorization?
3. A pseudocode block calls RecoveryPolicy.check, but the policy rules are not supplied. What is the strongest conclusion?
4. Why should code-review findings separate observation from interpretation?
5. A secret-management call references a managed secret ID and contains no value. What does code review still not prove?
6. What is the strongest response to a dependency update with no compatibility evidence?
7. What is a strong code-review finding?
Portfolio Prompt
Portfolio Build — Security Code Review Register
Create the seventh artifact for your A11 Secure Software Design Assessment: a fictional security code-review register containing at least six findings from inert pseudocode or design notes. For each finding include ID, requirement, change scope, observation, interpretation, evidence reference, limitation, risk, confidence, owner, recommendation, validation need, closure condition, and status.
Use only fictional code-like pseudocode and synthetic identifiers.
Include findings for authorization, data handling, secret handling, dependency change, error handling, and logging.
Keep code review separate from runtime validation.
Use Unknown when policy or configuration evidence is missing.
Never include real credentials, repositories, private source code, or harmful payloads.
Add a one-paragraph executive summary describing the strongest design alignment and the most important unresolved review gap.
Confidence / Readiness Reflection
Are You Ready for A11.8?
A11.8 turns secure requirements into safe validation plans. Before moving on, make sure you can explain what code review can support and what still requires testing or configuration evidence.
1
I can map a code change to security requirements and threat-model concerns.
2
I can review authorization, data, secrets, dependencies, errors, logging, configuration, and resilience.
3
I can separate code-review evidence from runtime validation.
4
I can write bounded findings with owners and closure criteria.
5
I can leave policy or configuration behavior Unknown when the evidence is not supplied.
Portfolio Build Guide
How to Make the Code-Review Register Look Professional
Use stable finding IDs
Give each review item a unique ID so remediation, validation, and release evidence can reference it.
Link the requirement
Every finding should explain which expected security behavior is affected.
Separate evidence layers
Observation, interpretation, risk, and limitation should be distinct.
Show confidence
Use High, Medium, or Low confidence based on how complete the supplied evidence is.
Show ownership
Every open finding should have an accountable implementation or design owner.
Show closure evidence
State what change, clarification, configuration record, or validation result closes the finding.
Use inert examples
Keep pseudocode conceptual and defensive rather than operational or harmful.
Connect forward
Make the validation requirement easy to reuse in A11.8 and deployment readiness later in the module.
Key Takeaways
What You Should Remember
1.Security code review begins with requirements and architecture intent, not with a generic search for suspicious-looking code.
2.The reviewer should trace sensitive paths such as authorization, data handling, secrets, dependencies, errors, logging, and configuration.
3.A policy call or control reference does not automatically prove the hidden rule or runtime behavior.
4.Code review supports implementation claims but does not replace safe testing, configuration review, or release validation.
5.Strong findings separate observation, interpretation, risk, evidence, confidence, owner, recommendation, and validation.
6.Secret values should never be copied into review comments or portfolio evidence.
7.Dependency changes deserve the same evidence discipline as source-code changes.
8.Unknown is an acceptable review status when required evidence is missing.
9.A professional review ends with accountable closure criteria, not just comments.
Lesson Safety Boundary
Code review is defensive evidence analysis
This lesson does not authorize exploitation, bypass testing, credential attacks, scanning, fuzzing, payload development, or access to real repositories, applications, APIs, devices, accounts, or networks. Use fictional pseudocode and supplied evidence only.
Lesson Complete
A11.7 Code Review for Security Complete
You now have a repeatable security code-review process that connects requirements, threat models, secrets, dependencies, errors, logging, configuration, findings, and closure evidence. Next, A11.8 focuses on Testing Security Requirements Safely.