Application security

Security as a property of the code

Application security is the work of keeping flaws out of the software an organisation writes or buys, and of catching the ones that slip through before an attacker does. It happens within the delivery pipeline, not next to it: a threat review when a feature is first sketched, security requirements recorded next to the functional ones, automated checks on every merge, and targeted testing before release. The people doing it range from developers with a security bent to dedicated AppSec engineers who build the guard rails everyone else works within.

OWASP's maturity model makes one point simply by its shape: testing fills a single row out of five. Organisations that buy a scanner and call the job done have covered a fraction of the field, and usually the dearest fraction to act on, because a flaw found in verification must travel back through design and build before it is fixed. The OWASP Top 10, now in its 2025 edition, is where most teams start. OWASP presents it as an awareness document on the most serious web application risks, a lever for changing developer habits rather than a complete standard.

• **Threat modelling**: asking, while a design is still cheap to change, what could go wrong, who would want it to, and which control answers each case.
• **Authentication and sessions**: how an application recognises a returning user, a recurring source of serious flaws because every framework handles it a little differently.
• **Password storage with hashing**: a slow, salted one-way function, never reversible encryption and never a home-grown scheme. The cryptography topic covers the choice in depth.
• Static and dynamic testing: reading source code for dangerous patterns versus probing the running application from outside. Platforms such as GitLab wire both into the merge request, and Burp Suite is the intercepting proxy manual web testers reach for.
• Dependencies: the third-party libraries that make up much of any modern codebase, each carrying its own record of disclosed weaknesses.

Exams, a common misstep and where it leads

The CISSP gives Software Development Security a domain of its own, weighted at 10 per cent, and examines it from the manager's chair: development methodologies and maturity models, controls around the build environment, secure coding and API guidelines, and how to judge software you acquire rather than write. PenTest+ comes at that ground from the attacker's end, with web application attacks and the tools that find them. Neither makes anyone a secure developer; they prove different vocabularies. Newcomers most often go wrong by treating findings as the product. A scanner report with hundreds of entries, handed to developers without context or priority, teaches them to ignore the next one. One well-explained issue, fixed together with the team that owns the code and then turned into an automated check so it cannot return, changes far more. Readers can go on to penetration testing, for the offensive view, and vulnerability management, for how defects found anywhere are tracked to closure.