Abstract
Secure code review is strongest when it begins with a model of what the system must protect. Line-by-line inspection finds local defects, while threat modeling reveals failures that emerge between services, identities, data stores, build systems, and operational controls. Combining the two produces a review that explains how trust enters the system, where it changes, and whether code enforces the intended security properties.
Build the model from the running system
Start with what is deployed, not what the architecture diagram once promised. Identify entry points, privileged operations, data classifications, identities, administrative planes, third-party services, queues, storage layers, agent tools, model endpoints, and delivery pipelines. Trace where data is parsed, transformed, authorized, stored, logged, and returned.
For each boundary, state a security property in testable language. Examples include: one tenant cannot name or retrieve another tenant’s object; a build job cannot publish an unsigned artifact; an external connector cannot invoke a tool that was not approved for the current identity; and a recovery operator cannot bypass separation of duties. A property that cannot be tested is probably too vague.
Threat models should record assumptions. If the design assumes a gateway validates tokens, confirm which routes bypass the gateway. If a service assumes queue messages are trusted, identify every publisher and whether the queue can be replayed. If the design assumes a human approves an agent action, verify where approval state is created, bound to parameters, expired, and audited.
Follow data and authority through code
Review code along trust paths rather than file order. Begin at the entry point and follow untrusted data through parsing, canonicalization, authorization, business logic, persistence, serialization, and audit. In parallel, follow authority: which identity executes each step, which credentials are loaded, which resources can be named, and where privilege is reduced or expanded.
Look for mismatches between checks and use. A path may validate an object ID and later replace it from another field. A policy may authorize a project but not verify that the requested secret belongs to that project. A filesystem check may inspect one path representation and open another after normalization. A user-facing permission may be enforced in the UI but absent from the API.
Review failure behavior as carefully as success behavior. Determine whether timeouts fail open, whether partial transactions leave privileged state behind, whether retries duplicate sensitive actions, whether error messages disclose identifiers, and whether exception handling skips audit events. Inspect concurrency controls where access decisions and state updates are separated in time.
Treat dependencies and delivery as code
Application logic is only one layer. Inspect dependency resolution, lockfiles, registries, source verification, build permissions, generated code, container bases, infrastructure modules, deployment gates, and runtime configuration. Determine who can alter each layer and what evidence proves that the deployed artifact corresponds to reviewed source.
Generated and AI-assisted code deserves the same review standard as human-written code. The relevant question is not who produced the text; it is whether the code preserves required security properties and passes meaningful tests. Daybreak Blue can help reviewers navigate large codebases, map trust paths, identify candidate weaknesses, and compare implementation with policy. Human reviewers must validate findings, resolve ambiguous intent, and approve changes.
Convert threats into review tests
A threat statement should lead to a testable assertion. “An attacker may cross tenant boundaries” becomes a matrix of identities, resource ownership, endpoints, alternate identifiers, bulk operations, asynchronous workers, imports, exports, and administrative overrides. “A connector may expose secrets” becomes tests for parameter binding, destination allowlists, token scope, redaction, confirmation, logging, and revocation.
Use negative tests to verify that the system refuses dangerous combinations, not merely that approved cases succeed. Add property tests for canonicalization and parser boundaries. Add integration tests where controls span components. For particularly important properties, create invariants enforced in code and observed in production.
Document residual risk. Some threats are accepted because of architecture, mission need, or operational constraints. Acceptance should name an owner, expiration or review date, compensating controls, detection coverage, and the condition that triggers reconsideration.
Field checklist
- Reconstruct deployed components, identities, data flows, control planes, and delivery paths.
- State testable security properties for every meaningful trust boundary.
- Trace both untrusted data and effective authority through the implementation.
- Check authorization at the object, action, tenant, and workflow level.
- Inspect canonicalization, parsing, concurrency, retries, exceptions, and partial failure.
- Review dependencies, build provenance, secrets, infrastructure, and deployment gates.
- Turn each material threat into positive, negative, and integration tests.
- Record residual risk with owner, compensating controls, and review date.
Concrete deliverables
Deliverables include a current system and data-flow model; trust-boundary inventory; threat register; stated security properties; code-path review notes linked to commits; dependency and build review; prioritized findings; security test additions; architecture decisions; residual-risk records; and a remediation plan with validation criteria. For agentic systems, include a tool and connector capability map, approval-state model, and auditability assessment.
Common failure modes
Teams often treat threat modeling as a workshop artifact that never reaches code. Reviewers may focus on obvious input validation while missing authorization and workflow abuse. Other failures include assuming internal traffic is trusted, reviewing source without build or deployment controls, accepting generated tests that only exercise happy paths, and creating diagrams with no version or owner. A review also fails when it reports style preferences as security issues or labels theoretical possibilities as exploitable without tracing reachability.
What A6 delivers
A6 delivers a threat-informed code review that connects architecture, implementation, tests, and deployment evidence. The result tells leaders which security properties are enforced, which are assumed, where the evidence is weak, and what engineering work will reduce risk. Daybreak Blue can support code navigation and hypothesis generation in approved repositories; experienced reviewers remain responsible for conclusions and change approval.
—