Build application security requirements

Protection need

Choose one application, one valuable operation, and one deployment boundary. Name the users, service identities, data, business state, external effects, control plane, and recovery authority. State the harm that the security work must prevent or contain.

Example: only the owner of a payroll account can change its payment destination; a stolen employee session must not be enough; each accepted and rejected change must support investigation; and the service must recover from a failed identity dependency without applying a partial change.

Map the complete system before selecting controls. Include browser or API clients, Pomerium, identity provider, application, object store, database, queues, workers, notification services, administrative paths, logs, and deployment system. Mark every input, trust boundary, credential, parser, state transition, and direct path.

Use three evidence sources for scope:

1. Protection needs from product and data owners.
2. Threat and abuse models for the deployed architecture.
3. A verification standard such as OWASP ASVS to expose missing control areas.

ASVS is a structured source of technical requirements. It does not know the application's business invariants or deployment-specific bypass paths.

Security objectives and requirements

Write objectives before mechanisms. An objective states the required result under a named condition. A requirement states a verifiable property of the system.

For the payroll example:

• The application must require a current authenticated subject and an object-level permission for the named payroll account.
• A payment-destination change must require fresh phishing-resistant authentication and confirmation that displays the exact new destination.
• The application must bind the confirmation, account, destination, actor, and expiry to one atomic state transition.
• A request that reaches the application around the intended route must not obtain trusted identity or complete the change.
• Failed validation, dependency timeout, concurrent update, or notification failure must not produce an unreviewed partial state.
• Route and application events must share an identifier that permits reconstruction without recording a reusable credential.

Select ASVS requirements that support these objectives. Record the ASVS version and full requirement identifier. Do not copy every requirement into every product. Select an assurance level and additional requirements from risk, data sensitivity, attacker access, deployment, and consequence. Explain exclusions.

Keep these categories separate:

• Authentication establishes the subject and session properties.
• Route authorization permits access to an application boundary.
• Object and action authorization permits the payroll change.
• Transaction authorization binds user intent to the exact change.
• Input and output controls protect parsers and interpreters.
• Evidence supports investigation and assurance.
• Recovery restores a known-good state.

Security invariants and evidence

Turn each critical requirement into an invariant that must hold across normal, concurrent, degraded, and recovery states.

Example invariants:

• Every committed destination change has one current owner decision and one fresh confirmation bound to the same account and destination.
• No caller can supply or overwrite the trusted subject, account owner, approval result, or policy decision.
• A failed or retried request commits at most one change.
• Every application request came through an effective enforcement path or was rejected by a separately authenticated upstream control.
• Emergency access cannot change a destination without separate approval and review.

For each invariant, record:

1. The mechanism and code or configuration owner.
2. The positive and negative test.
3. The exact release or environment where the test ran.
4. The runtime signal and expected evidence.
5. The failure response and recovery action.
6. The residual risk and review trigger.

Use several kinds of evidence. Static review can show that a safe API is used. An integration test can show that the object check rejects another account. A deployed reachability test can show that the origin is not directly accessible. A concurrent test can show that two confirmations cannot both commit. A log trace can connect the route decision to the final business event.

Failure cases

Challenge the requirements with system-specific failures:

• Use a valid session for another payroll account.
• Change the object identifier, action, destination, or tenant after confirmation.
• Replay the confirmation before and after expiry.
• race two changes against the same account version.
• Submit the same request after a client timeout.
• Remove the user or weaken device posture during the operation.
• Reach each known origin, worker, administrative route, and recovery path directly.
• Inject identity-looking headers without a valid signed assertion.
• Make the identity provider, policy service, database, and notification service unavailable in turn.
• Force validation, transaction, audit, and notification failures at each stage.

Observe the final state and external effects. A safe error response does not prove that the database or downstream payment system did not change.

Design tradeoffs and residual risk

Higher assurance requires more independent evidence and narrower assumptions. It also adds development, test, operation, and user cost. Apply depth where consequence and attacker opportunity justify it.

Fresh authentication reduces session-abuse risk and adds user friction and identity-provider dependency. Atomic confirmation improves integrity and can complicate a multi-service workflow. Detailed audit evidence helps response and increases sensitive-data exposure. Fail-closed dependency behavior protects the operation and can stop urgent work. Record the choice and bounded residual risk.

Do not hide a missing control behind an accepted checklist item. Record the exact system gap, temporary mitigation, owner, expiry, and condition that requires escalation.

Pomerium boundary

Pomerium can authenticate access, evaluate route policy, protect the application entry point, and provide signed identity context and route evidence. These capabilities can support authentication, route authorization, upstream identity, and bypass-prevention requirements.

The application owns payroll-object authorization, transaction confirmation, state invariants, parsing, database authority, retries, business evidence, and recovery. The deployment owns direct-origin isolation, identity-provider quality, credentials, telemetry retention, and administrative access. State these boundaries in the requirements instead of treating Pomerium as a general application-security claim.

Exercise

Select one sensitive application action. Build a requirement table with these columns:

1. Protection need and harm.
2. Actor, resource, action, context, and state.
3. Security objective.
4. ASVS or other source requirement and version.
5. Application-specific requirement.
6. Invariant.
7. Mechanism and owner.
8. Negative test.
9. Release evidence.
10. Runtime signal.
11. Failure and recovery behavior.
12. Residual risk and review trigger.

Complete at least twelve rows across architecture, authentication, session, authorization, input, browser, data, logging, safe failure, and recovery. Run three negative tests against a deployed environment. Revise any requirement that does not produce a clear pass or fail result.

Evaluation checklist

• Does every requirement trace to a protection need, credible abuse, and named security property?
• Are checklist requirements adapted to the actual architecture and business state?
• Are route, object, action, and transaction decisions kept separate?
• Does each critical requirement have an invariant, owner, negative test, release evidence, and runtime signal?
• Do tests cover alternate paths, concurrency, stale state, dependency failure, and recovery?
• Are the selected assurance depth and exclusions supported by risk and consequence?
• Does each residual risk name its path, bound, owner, expiry, and review trigger?