Advanced Security #design-review #ASVS #risk-treatment #CVSS

Security Design Review Language

5 exercises — master security design review vocabulary: the review process and its SDLC placement, OWASP ASVS verification levels, shall vs should in security requirements, the four risk treatment options (accept/mitigate/transfer/avoid), and how to raise a precise security finding with description, impact, severity, and recommendation.

0 / 5 completed

Security design review quick reference

Security design review — pre-code structured examination of a proposed design; catches architectural security issues before they are expensive to fix.
Shift left — address security concerns in design phase; defects fixed in design are ~100x cheaper than post-deployment.
OWASP ASVS levels — L1 (Opportunistic): all apps; L2 (Standard): apps with sensitive data; L3 (Advanced): high-assurance/banking/healthcare.
SHALL vs SHOULD (RFC 2119) — SHALL = mandatory, blocks release; SHOULD = recommended, deviation needs documented rationale.
Risk treatment — Accept (within appetite + documented); Mitigate (control reduces risk to acceptable); Transfer (insurance/SLA); Avoid (remove feature/component).
Security finding structure — Description + Impact (CIA triad) + Severity (CVSS) + Recommendation (specific, actionable, addresses root cause).
Risk appetite — the level of risk leadership accepts; defines the boundary between "accept" and "mitigate" decisions.

1 / 5

A security lead explains their team's practice: "We run a security design review on every significant feature before it hits code review. It's not a checkbox — it's a structured conversation between the security team and the feature team."

What is a security design review, what does it cover, and when in the SDLC should it happen?

Security design reviews catch architectural problems before code is written. A bug fixed in design costs ~10x less than after deployment (NIST/IBM research). The goal is a structured conversation, not a gatekeeping checkpoint.

Security design review agenda:

Area	Questions asked
Data flow	Where does data enter/leave the system? Is sensitive data identified and classified?
Trust boundaries	Where do trust levels change? Is input validated at each boundary crossing?
Authentication/Authz	How are users identified? What authorisation model is used? Are service-to-service calls authenticated?
Cryptography	What data needs encryption at rest and in transit? Which algorithms/libraries are used?
Threat model	Who are the threat actors? What are the most likely attack vectors for this feature?
Logging/audit	Are security-relevant events logged? Can we reconstruct an incident from logs?

When to trigger a security design review:
• New external-facing feature or API endpoint
• Changes to authentication, authorisation, or session management
• New data collection involving PII or sensitive data
• Significant architectural change (new service, new external dependency, new data store)
• Integration with a third-party system

Key vocabulary:
• Security design review — structured pre-code examination of a proposed design; identifies architectural security issues before code is written
• Security champion — an engineer embedded in a development team who has security training and acts as the first line of security review; liaisons with central security team
• Shift left — the practice of addressing security concerns earlier in the development lifecycle, closer to design/development rather than testing/deployment
• Design-phase cost of fix — architectural flaws found in design are ~100x cheaper to fix than post-deployment; the economic argument for early security review

2 / 5

A security engineer says: "This new API should be verified against OWASP ASVS Level 2. That's the baseline for any application handling user data."

What is OWASP ASVS, what do the levels mean, and how is it used in a security review?

ASVS gives security reviewers a shared vocabulary and checklist for design reviews. Referencing "ASVS 4.3.2" is more precise and defensible than saying "your authorisation looks weak".

OWASP ASVS overview:

Level	Name	Target	Verification method
L1	Opportunistic	All web applications; minimum baseline	Penetration testing; automated DAST
L2	Standard	Apps handling PII, financial data, sensitive business logic	Pen testing + code review + SAST
L3	Advanced	Banking, healthcare, safety-critical, high-assurance systems	Pen testing + deep code review + architecture analysis + threat modelling

Selected ASVS chapters and example requirements:
• V2 — Authentication: V2.1.1 — user passwords must be at least 12 characters; V2.2.1 — anti-automation (rate limiting) on authentication endpoints
• V3 — Session Management: V3.2.3 — session tokens invalidated on logout; V3.3.1 — idle session timeout
• V4 — Access Control: V4.1.1 — access control enforced server-side; V4.2.1 — sensitive data and APIs protected from IDOR
• V9 — Communications: V9.1.1 — TLS required for all connections; V9.1.2 — TLS version ≥ 1.2
• V13 — API and Web Services: V13.2.5 — REST services reject non-JSON content types; V13.3.1 — GraphQL query rate limiting

Key vocabulary:
• OWASP ASVS — Application Security Verification Standard; structured list of security requirements for web applications; three levels of rigour
• ASVS L2 — the standard verification level for applications handling sensitive data; covers authentication, session management, access control, input validation, cryptography, error handling, logging
• Verification method — how compliance with an ASVS requirement is confirmed: black-box pen test, code review, or architecture analysis

3 / 5

In a design review template, the security requirements section uses specific language: "The system shall enforce MFA for all admin operations. Logging of all access to PII fields shall be enabled. Password reset tokens should expire within 15 minutes."

Why does it matter whether a security requirement uses "shall" or "should"?

Consistent "shall/should/may" language in security requirements transforms security reviews from vague opinion-sharing into auditable, triage-able conversations. Every senior engineer or security lead should know this convention.

RFC 2119 requirement keywords in security context:

Keyword	Meaning	Review action
SHALL / MUST	Mandatory. Non-compliance is a defect.	Blocks sign-off. Must be implemented before feature ships.
SHALL NOT / MUST NOT	Absolutely prohibited. Violation is a critical defect.	Blocks ship. Examples: plaintext passwords, unencrypted PII in logs.
SHOULD / RECOMMENDED	Strong recommendation; valid reasons may exist to deviate.	Deviation requires documented rationale + risk acceptance. Tracked in risk register.
SHOULD NOT	Not recommended; valid reasons may exist to permit.	Requires documented justification if present.
MAY / OPTIONAL	Permitted. Teams may implement or omit based on their judgement.	No review action required; informational only.

Security requirement categories using shall/should:
• Authentication requirements: "The system shall require MFA for all privileged operations. Session tokens shall expire after 24 hours of inactivity. Refresh tokens should be rotated on use."
• Authorisation requirements: "The API shall enforce object-level authorisation on every read and write endpoint. Role assignments shall be server-side only. Wildcard roles should not be granted to service accounts."
• Data handling requirements: "PII shall be encrypted at rest using AES-256. Encryption keys shall be stored separately from encrypted data. Database backups should be encrypted with a separate key."

Key vocabulary:
• SHALL / MUST (RFC 2119) — mandatory requirement; non-compliance is a defect that blocks acceptance; used for non-negotiable security controls
• SHOULD / RECOMMENDED — strong guidance where deviations may be accepted with explicit risk acceptance and documentation
• Risk acceptance — a formal acknowledgment that a team understands a security gap, has assessed its risk, and chooses to accept rather than remediate, with an owner and review date

4 / 5

At the end of a security design review, the team faces three identified risks. The security lead says: "We have four options for each risk: accept, mitigate, transfer, or avoid it. Let's go through each one."

What does each risk treatment option mean in a security context?

Risk treatment options are a precise professional vocabulary for security conversations. Using them correctly signals experience — and makes design review outcomes auditable and defensible.

Risk treatment in practice:

Treatment	When to use it	What to document	Example
Accept	Residual risk is within appetite; mitigation cost exceeds risk impact	Risk description, likelihood × impact, rationale, owner, review date	Rate limiting not applied to admin-only internal endpoint; accepted due to network-level restrictions already in place
Mitigate	Risk is outside appetite; a practical control exists	Control implemented, residual risk after mitigation, verification method	IDOR risk mitigated by adding object-level authorisation check in every endpoint handler
Transfer	Residual financial risk remains after mitigation; third party better placed	Transfer mechanism, third party, contractual terms, coverage amount	Cyber insurance policy covers breach notification costs and regulatory fines up to £5m
Avoid	Risk cannot be reduced to acceptable level; feature/component is dropped	Decision rationale, alternative design chosen, business impact	Free-text user profile fields removed from public pages; replaced with structured dropdown to avoid stored XSS

How to phrase risk treatment decisions in a review:
• Accept: "We're accepting this risk. The likelihood is low, the blast radius is limited, and the mitigation cost is disproportionate. [Name] owns this and we review it next quarter."
• Mitigate: "We'll mitigate this with server-side input validation. The control reduces likelihood from high to low. After mitigation, residual risk is within appetite."
• Transfer: "We've mitigated the technical risk, but residual financial liability transfers to our cyber insurance policy."
• Avoid: "We're removing this feature entirely. The risk profile doesn't justify the business value."

Key vocabulary:
• Risk appetite — the amount and type of risk an organisation is prepared to accept in pursuit of its objectives; defined by leadership; used to calibrate "accept vs. mitigate" decisions
• Residual risk — the risk remaining after mitigation controls have been applied; residual risk must still fall within risk appetite for the treatment to be acceptable
• Risk register — a tracked document listing identified risks, their treatment decision, owner, and review date; the audit trail for risk acceptance decisions

5 / 5

A junior security engineer raises a finding in a design review: "I think there's a potential authorisation issue here." The senior engineer says: "You need to communicate that more precisely. How do you raise a security finding in a review?"

What are the components of a well-formed security finding, and how should it be communicated?

Precise finding language — description, impact, severity, recommendation — is what separates a security professional from someone raising noise. It also makes the triage decision (accept/mitigate/avoid) obvious.

Security finding template:

Component	What to include	Example
Description	Precise, factual, no opinion words. What is the issue?	"The /api/report/{id} endpoint does not validate that the requesting user owns the report identified by {id}."
Impact	What an attacker gains. Link to CIA triad (confidentiality, integrity, availability).	"An authenticated attacker can read financial reports belonging to other organisations — confidentiality violation affecting all tenants."
Severity	CVSS score or Critical/High/Medium/Low with rationale.	"High — CVSS Base Score ~7.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Low effort; high data exposure impact."
Recommendation	Specific, actionable, addresses root cause.	"Add object-level authorisation: before returning report data, verify reports.org_id == current_user.org_id. Add test: request report owned by another org; expect 403."

Language for communicating severity:
• Critical: "This is a critical finding — unauthenticated remote code execution. This blocks shipping."
• High: "High severity. An authenticated attacker can access other users' data. We need a fix before this feature goes live."
• Medium: "Medium severity. The risk exists but requires a specific precondition to exploit. We'd like a fix but can discuss timing."
• Low / Informational: "Low severity — a defence-in-depth improvement. Worth tracking but doesn't block this release."

Key vocabulary:
• CVSS (Common Vulnerability Scoring System) — an industry-standard scoring system for vulnerability severity; base score 0–10; components: Attack Vector, Complexity, Privileges Required, User Interaction, Scope, Confidentiality/Integrity/Availability impact
• CIA triad — the three core security properties: Confidentiality (data accessible only to authorised parties), Integrity (data accurate and unmodified), Availability (system accessible when needed)
• Object-level authorisation — verifying that the authenticated user has permission to access the specific resource instance (by ID), not just the resource type; prevents IDOR vulnerabilities