The application is where most security decisions actually happen. The patterns that matter are the ones that hold up against the threats in the threat model, not the ones on a generic checklist.
§ 01 ·
Application security is the discipline of designing, building, and operating software such that the threats in the threat model are addressed in the implementation, not in a security review after the fact. The discipline covers the patterns (input handling, output encoding, authentication, authorisation, session management, cryptography, dependency management), the process (threat model, secure design, secure implementation, verification, response), and the operating model: who owns the security posture of an application over time.
The most important property of an application security practice is that it integrates with delivery. A separate team, on a separate schedule, with a separate backlog, produces a security review that is current to last quarter and out of date with this sprint. The patterns have to be in the paved roads: the default framework, the default tooling, the default review process, or they will be skipped when the deadline moves.
§ 02 ·
The patterns that matter for application security are the ones that come up in the threat model, not the ones on a generic checklist. The OWASP ASVS (Application Security Verification Standard) is the most useful checklist because it is organised by threat, not by vulnerability type, but the value of ASVS is the conversation about which requirements apply, not the requirements themselves.
The patterns that recur most often in threat models for our clients.
Every input is untrusted. Every input is validated, normalised, and then either accepted or rejected. Validation is explicit (type, format, range, charset) and rejection is safe (no information leakage, no exception path that bypasses other controls).
Every output is encoded for the context in which it will be interpreted. HTML in HTML, JavaScript in JavaScript, SQL parameters as parameters. Encoding is the default; concatenation is the exception.
Every request is evaluated. Evaluation is per-request, with current evidence, against a documented model. The model is the application security analogue of the trust algorithm.
Sessions are first-class state. They have a lifetime, a renewal policy, an invalidation policy, and a logging policy. Defaults are documented and deviations are reviewed.
Cryptography handles confidentiality, integrity, and authentication. The choice of primitive, the choice of mode, the choice of key management, the choice of library: every one is a design decision. Decisions are made by someone who understands them, not by the default library.
The dependency surface is the largest attack surface. Every direct dependency is reviewed at adoption and at every major version bump. Every transitive dependency is tracked. The supply chain is the threat model.
§ 03 ·
§ 04 ·
All three, in the right places, but not as a primary control.
None replaces a threat model, a secure design, or a code review. The tools are evidence; the practices are the architecture.
Three controls.
The patterns have to be in the paved roads.
A separate security review, on a separate schedule, with a separate backlog, will be skipped.
On three properties, in order.
The metric that matters is the time to detect and correct a security issue, which is the audit loop closing.
§ 05 ·
A security review at the end of the SDLC produces a finding list, not a secure design. By the time the review runs, the architecture is set, the patterns are baked in, and the changes the review recommends are expensive. Security is a design activity, not an audit activity.
SAST findings are a signal, not a backlog. A finding that has been in the backlog for six months is a finding that has been accepted. Either fix it, suppress it with documented justification, or change the threshold so it stops firing. The point of the tool is the conversation, not the list.
A security champion is a person with two jobs and half the time for each. The model that works is an embedded security engineer: a person on the team, full-time, with security skills and delivery context. The champion model produces a person consulted on the worst problems and absent from the daily decisions. The embedded model produces a person in every standup and every PR review.
A threat model that is not consulted when the design changes is documentation, not architecture. The model has to be in the same review process as the design. When the design changes, the threat model is part of the change.
Scanning for secrets in git history is a useful last line of defence. It is not a substitute for the secret management practice that prevents secrets from being committed in the first place. The right answer is a secret management system the team uses by default. The right answer is not "we'll catch it in the scan."
§ 06 ·
Public frameworks and writing that inform our practice.
The verification standard. The most useful of the OWASP projects because it is organised by threat, not by vulnerability, and because it is verification-standard-shaped (you can test against it), not a checklist (you cannot just check the boxes).
The most-cited list. Useful for awareness, not as a security program. The Top 10 is a snapshot of the most common vulnerability categories; the ASVS is the verification standard; the threat model is the input. The three are complementary.
The book that made application security a discipline. The treatment of the attack patterns is still the most rigorous available. The book's contribution is the framing of the application as a system to be attacked, not a checklist of vulnerabilities to be fixed.
The pattern language for token-based authorisation, key rotation, and the testability of authorisation decisions. The API security subset of application security is the part that has the most overlap with the broader application security discipline, and the part that has the most distinct patterns.
The taxonomy of software weakness types. Useful as a vocabulary for the security conversation, not as a verification standard.
Weighing an application security initiative, evaluating tooling, or trying to make an existing practice more than a checklist exercise? Useful at the boundary between the threat model and the implementation. A short conversation is the right next step.
Learn more