Stage 2 summary. Applied practice

Threat modelling asks a simple question early: what can go wrong here, and what are we going to do about it. The reliable way to answer is to draw the system as a data-flow diagram, mark the trust boundaries where data crosses from one level of control to another, and then walk each element with STRIDE, the six-category prompt for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Privacy threats get their own lens, LINDDUN, because a system can be secure and still leak by design.

The value is in the timing. A threat found on a whiteboard costs a conversation, while the same threat found in production costs an incident, so the four-step process of decompose, identify threats, mitigate and validate belongs at design time and then repeats whenever the design changes materially. Trust boundaries do most of the analytical work, because they mark exactly the places where an assumption about who is trustworthy stops holding, which is where an attacker aims.

This module is deliberately the foundation for the rest of the stage. The data-flow-first habit reappears in web and API security, where the boundary between the browser and the server, or between one service and another, is precisely where broken access control lives. Getting the habit here means the later categories land as instances of a pattern rather than as a list to memorise.

Enterprise identity runs on a small set of protocols whose jobs are often confused. OAuth 2.0 is an authorisation protocol: it lets a user delegate limited access to a resource without handing over their password, issuing an access token that says what the bearer may do. OpenID Connect is a thin identity layer on top of OAuth that adds an ID token proving who the user is. SAML does a similar identity job in the older enterprise single sign-on world. Mixing them up, treating an access token as proof of identity, is a classic and dangerous error.

A JSON Web Token is only as trustworthy as its validation. A JWT carries claims that anyone can read, so the security comes entirely from checking the signature, the issuer, the audience and the expiry before believing a word of it. A token whose signature is never validated is just a request parameter the client can forge. This is where the adversary-in-the-middle chain from Foundations reconnects: the session token an attacker steals is exactly the artefact these protocols issue, which is why lifetime and binding matter as much as the strength of the original login.

Verifying that an identity implementation is actually correct is a standards question, and ASVS 5.0.0, released in May 2025 at Global AppSec EU Barcelona, gives OAuth, OpenID Connect and token handling their own standalone chapters. Conditional access policies are how the multi-factor tier model from Foundations becomes enforceable inside a real identity provider, tying the requirement to the sensitivity of what is being reached.

The OWASP Top 10 is a periodically refreshed awareness document, and the November 2025 edition kept Broken Access Control at A01, added Supply Chain Failures at A03, and folded server-side request forgery into the access-control story rather than leaving it as a standalone entry. The point of the list is to direct attention, not to certify a product, so a section that maps a described defect to its 2025 category has to account for the fact that a weakness which was 2021-era SSRF is now part of A01.

The anchoring case is MOVEit in 2023, where the Cl0p group exploited CVE-2023-34362 in a widely used file-transfer product and reached the data of organisations far beyond the direct customer, including through the Zellis payroll route that touched the BBC and British Airways in the UK. Capital One's earlier SSRF breach, which drew an 80 million dollar penalty from the Office of the Comptroller of the Currency, shows the same access-control failure from the cloud-metadata angle.

The design-versus-verify distinction lands hardest here. You design against the Top 10 and you verify against the OWASP Application Security Verification Standard, and the two are not interchangeable. ASVS gives you testable requirements at a chosen assurance level, whereas the Top 10 gives you the ten things most likely to hurt. Because ASVS renumbered its requirement identifiers between the 4.x and 5.0 lines, any quoted control text has to be re-checked against the current standard rather than relabelled.

APIs fail differently from web pages, and the OWASP API Security Top 10, whose 2023 edition remains current, makes clear that the dominant problem is authorisation rather than authentication. Broken Object Level Authorisation, listed as API1, is the defining case: an authenticated user asks for an object that is not theirs, by changing an identifier in the request, and the server hands it over because it checked who the caller was but never checked whether they were allowed this particular record.

The fix is unglamorous and consistent: every request for an object must verify that the authenticated principal owns or is permitted that specific object, on the server, on every call, with no reliance on the client to hide the identifier. This is broken object-level authorisation, and it is distinct from broken function-level authorisation, where a user reaches an operation meant for a higher privilege such as an admin-only endpoint. Naming the two apart matters, because they need different checks.

Around the individual checks sits the operational layer. Rate limiting and an API gateway defend availability and contain abuse, giving a single place to enforce authentication, throttle callers and observe traffic. But a gateway that authenticates well and authorises poorly still leaks every record, which is why the object-level check cannot be delegated to the perimeter and has to live with the business logic that knows what ownership means.

Shift-left security moves testing earlier so that defects are caught while they are cheap, and it does so through a set of automated gates in the delivery pipeline. Three techniques cover most of the ground and each sees something the others cannot. Static application security testing reads the source without running it and finds insecure patterns. Dynamic testing exercises the running application and finds what only appears at runtime. Software composition analysis inventories third-party dependencies and flags known-vulnerable versions.

A software bill of materials records exactly which components and versions a build contains, which is what makes composition analysis and later incident response possible: when the next Log4Shell lands, the first question is which of our systems even contains the component, and an SBOM answers it in minutes rather than weeks. The forward pointer is to Stage 3, where SLSA and code signing add provenance so that the bill of materials can be trusted rather than merely produced.

The trap the whole module guards against is treating a green scan as an assurance. A scanner reports what it recognised, not that the system is secure, so its output is evidence to weigh rather than a verdict to accept. A gate that passes because nobody read the findings is theatre, and the discipline is to make the pipeline fail on the findings that matter and to keep the signal high enough that the failures are believed.

Detection cannot see what was never recorded, so logging is the precondition for everything in security operations. The discipline starts with a security event taxonomy, deciding what is worth logging in the first place: authentication successes and failures, privilege changes, access to sensitive data, configuration changes and network flows. Structured logging, where each event is a consistent set of fields rather than free text, is what lets a machine reason over the record instead of a human grepping through it.

A security information and event management system collects those logs centrally and runs detection rules across them, and Sigma is the vendor-neutral format for writing those rules so that a detection can move between platforms. The reason to care about structure and standards is that a rule is only as good as the fields it can rely on being present and consistently named.

The central operational failure is alert fatigue, and it is why more rules is not more detection. A SIEM tuned to alert on everything drowns the analyst who has to triage it, so the real signals are missed inside the noise. Good detection is therefore an exercise in restraint and tuning, not volume, and it feeds a distinction the reader must hold: an event is anything logged, an alert is an event a rule thought worth surfacing, and an incident is an alert a human confirmed as real. Stage 3 turns single rules into a detection-as-code lifecycle.