The Architect's Glossary of Security Design Review Terms (That OWASP Doesn't Define)

Direct answer: This glossary defines the practitioner-level vocabulary security architects actually use while running design reviews — terms like trust boundary drift, risk acceptance threshold, design debt, and review gate criteria — that don't appear in OWASP's core glossaries because they describe the process of running a review, not a technical vulnerability class. Each entry below is organized by where it shows up in the review lifecycle: before, during, after, or in ongoing governance.

‍

Search "security glossary" and you'll get the same twenty terms recycled across a dozen vendor pages — SQL injection, XSS, CSRF, zero-day — all useful, all already well-defined by OWASP itself. What's missing is the vocabulary architects actually reach for while running a review: the words for how risk moves through a design process, not just what a vulnerability is called. That's the gap this glossary fills.

Pre-Review Terms

Trust Boundary

The point in a system where data or control crosses from one level of trust to another — between a user and your API, between two microservices with different privilege levels, between your network and a third-party integration. Example: the boundary between your public-facing API gateway and your internal billing service is a trust boundary — a request crossing it should be re-authenticated, not implicitly trusted because it came from "inside."

Attack Surface (Design-Time)

Every point in a proposed architecture where an external actor could potentially interact with, influence, or extract information from the system — assessed from the design itself, before a single line of code exists. Example: adding a webhook receiver to accept updates from a third-party CRM expands your design-time attack surface, even though nothing has been built yet.

Data Flow Diagram (DFD)

A visual map of how data moves through a system — where it enters, where it's transformed, where it's stored, where it exits — used as the base artifact most threat modeling techniques (STRIDE especially) are applied against. Example: a DFD for a checkout flow should show payment data moving from the client, through a tokenization service, to a payment processor — with every hop marked as a potential trust boundary.

Review Trigger

The specific, predefined condition that mandates a security design review — a new service, a change touching regulated data, a new third-party integration — as opposed to a review happening because someone happened to think of it. Example: "any change that adds a new external API integration" is a review trigger; "we should probably get security's eyes on this" is not.

Risk Appetite

The level and type of risk an organization has explicitly decided it's willing to accept in pursuit of its objectives, set by leadership rather than by whoever's running a given review. Example: a fintech startup might have a low risk appetite for anything touching payment data and a comparatively higher one for risks in an internal admin tool nobody outside the company can reach.

During-Review Terms

Trust Boundary Drift

When the actual, implemented trust relationships in a running system diverge from what was documented or assumed during the original design review — usually because of incremental changes nobody re-evaluated individually. Example: a service that was internal-only at review time quietly gains a public endpoint six months later for partner access; the trust boundary drifted, but the threat model never got updated to match.

Confused Deputy Pattern

A situation where a system component with legitimate, elevated privileges gets manipulated into performing an action on behalf of an actor who couldn't have taken that action directly — the component acts as an unwitting "deputy" for the attacker. Example: a low-privileged user tricks a highly-trusted internal service into making a request it wouldn't accept directly from that user, borrowing the service's authority to do something the user couldn't do alone.

Design Debt

Security-relevant shortcuts or simplifications accepted during a design review — usually to hit a deadline — that create risk intended to be revisited later but frequently never are. Distinct from technical debt: technical debt is about code quality and maintainability; design debt is specifically about accepted, unresolved security risk baked into an architecture decision. Example: shipping a new integration with a shared service account "temporarily" instead of per-service credentials, with a ticket to fix it later that never gets prioritized, is design debt.

Mitigating Control vs. Compensating Control

A mitigating control directly reduces the likelihood or impact of a specific identified risk (input validation mitigates injection). A compensating control doesn't fix the underlying issue but reduces overall exposure some other way (network segmentation compensates for a service that can't be patched immediately). Reviewers conflate these constantly, and the distinction matters for risk acceptance decisions. Example: if a legacy system can't be patched, isolating it on a segmented network is a compensating control — the vulnerability is still there, but its blast radius is reduced.

Threat Actor Profile

A defined description of a specific class of attacker relevant to a system under review — capability, motivation, and likely access level — used to keep a threat model grounded in realistic scenarios instead of an unbounded "anyone could do anything" analysis. Example: for an internal admin tool, your threat actor profile might reasonably exclude "unauthenticated internet attacker" and focus on "authenticated employee with excessive privilege" instead.

Post-Review Terms

Risk Acceptance Threshold

The specific level of risk — usually defined by severity, likelihood, or a combined score — below which a finding can be formally accepted and shipped without further mitigation, and above which it cannot proceed without additional controls or explicit sign-off from someone with the authority to accept that risk. Example: an organization might set a risk acceptance threshold that allows a team lead to accept "medium" findings but requires a CISO's signature for anything rated "high" or above.

Residual Risk

The risk that remains after mitigating and compensating controls have been applied — distinct from the original, unmitigated risk, and the actual number that should be measured against your risk acceptance threshold. Example: an endpoint with a known injection risk that's been fixed with input validation still carries some residual risk from validation logic bugs — smaller than the original risk, but not zero.

Finding Severity Rating

A standardized score — typically Critical, High, Medium, Low, or a numeric equivalent — assigned to each identified risk during a review, based on a documented, consistent methodology rather than a reviewer's gut feeling, so findings can be compared and prioritized across different systems and different reviewers. Example: two findings both called "High" by different reviewers should represent comparable actual risk — if they don't, your severity methodology isn't standardized yet.

Remediation SLA

The maximum time allowed to resolve a finding, typically tied to its severity rating — a Critical finding might carry a 7-day SLA, a Low finding a 90-day SLA — used to track whether findings are actually getting fixed instead of accumulating indefinitely in a backlog. Example: a Critical finding that blows past its 7-day remediation SLA should trigger an escalation, not silently roll into next quarter's backlog.

Governance Terms

Review Gate

A defined checkpoint in the SDLC where a design cannot proceed to the next stage — development, deployment — without the security design review being completed and its findings addressed or formally accepted. Example: a review gate at the end of architecture design means engineering literally cannot open a development sprint for the feature until the gate has been passed.

Security Sign-Off

The formal, documented approval from a named, accountable person or role indicating a design has met the organization's security bar — the specific artifact that answers "who approved this, and on what basis" months later, during an incident or an audit. Example: "the design was generally considered fine" is not a security sign-off; a dated approval from a named security architect, referencing the specific findings that were addressed, is.

Audit Trail / Traceability

The documented chain connecting a specific finding back to the design artifact that produced it, the decision made about it, and the person who made that decision — the thing that lets you answer "why was this risk accepted" for a decision made eighteen months ago by someone who's since left the company. Example: a finding that traces to "line 40 of the payment-service architecture doc, accepted by [name], [date], because the exposure was scoped to internal traffic only" has traceability; a finding that just says "resolved" in a ticket does not.

Continuous Threat Model

A threat model that updates automatically as the underlying architecture changes — through connected code, infrastructure, and documentation sources — rather than one that's accurate only as of the date it was last manually reviewed. The opposite of a static threat model, which starts decaying the moment the system it describes changes. Example: a continuous threat model recalculates the relevant risk the moment a new IAM policy is deployed, instead of waiting for the next scheduled review to notice the change.

‍