The secure development lifecycle explained: HSC Software Engineering Module 1

Requirements and design: threat modelling. The team uses a framework like STRIDE to identify what could go wrong (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege). Each threat is paired with a mitigation that becomes a requirement, for example "all admin endpoints require MFA" responding to spoofing.

Implementation: secure coding standards and code review. Developers follow language-specific guidance (OWASP secure coding cheat sheets) and every change is peer-reviewed before merge. Static Application Security Testing (SAST) tools like SonarQube or Semgrep scan code automatically for common vulnerabilities (SQL injection patterns, hardcoded secrets, weak crypto).

Testing: dynamic security testing. Dynamic Application Security Testing (DAST) tools like OWASP ZAP exercise the running app and probe for vulnerabilities. Penetration testing - hiring an ethical hacker to attempt to break in - covers issues that automated tools cannot find. Dependency scanning runs against the build pipeline to flag vulnerable libraries.

Deployment and monitoring: ongoing observation. Centralised logs capture authentication attempts, errors, and access patterns. Alerting catches anomalies (a thousand failed logins per minute, unusual outbound traffic). Patch management keeps third-party components updated. Periodic re-testing repeats earlier security checks against the live system.

Markers reward all four stages named correctly, a concrete activity at each (not just "do security"), and recognising that security is continuous, not a one-off audit at the end.

(a) Implementation - SAST scans source code as it is written, before the code is merged.

(b) Testing - penetration testing is a dynamic, hands-on test of a built system, typically run before release.

Marking criteria: 1 mark for correctly stating "implementation" for (a), 1 mark for correctly stating "testing" for (b).

Static Application Security Testing (SAST) analyses an application's source code without executing it, looking for known vulnerable patterns such as string-concatenated SQL queries or hardcoded secrets. An example is SonarQube or Semgrep.

Dynamic Application Security Testing (DAST) tests the application while it is actually running, sending it crafted requests and observing the responses to find exploitable vulnerabilities such as injection or broken authentication. An example is OWASP ZAP or Burp Suite.

Marking criteria: 1 mark for a correct SAST description, 1 mark for a correct DAST description, 1 mark for one correct named tool for each (2 tools total).

Activity

This data comes from ongoing monitoring/logging in the operation stage of the SDLC - specifically, authentication event logging feeding a SIEM-style dashboard.

What it suggests

The spike to 812 failed attempts in a single 15-minute window, sitting far above the baseline of 3 to 5, indicates an automated attack such as credential stuffing or a brute-force attempt against the login endpoint, not normal user error.

Next step

The SIEM should trigger an alert so the security/on-call team is notified immediately. The incident response playbook is invoked: rate-limit or temporarily block the offending IP addresses, force a password reset for any accounts that were successfully accessed during the spike, and review whether multi-factor authentication or CAPTCHA should be added to the login flow. This finding also feeds back into design, strengthening the security requirements for future releases.

Marking criteria: 1 mark for identifying monitoring/logging as the source activity, 1 mark for correctly interpreting the spike as a credential-stuffing/brute-force attack rather than normal traffic, 2 marks for describing appropriate, specific next steps (alerting plus at least one concrete remediation).

Threat 1: Spoofing. An attacker could impersonate a legitimate user by guessing or stealing their password. Mitigation: require strong password policies and multi-factor authentication (MFA), so a stolen password alone is not enough to log in.

Threat 2: Elevation of privilege. A logged-in standard user could try to access admin-only functions by directly calling an admin API endpoint. Mitigation: enforce role-based access control (RBAC) on the server for every request, never trusting a client-side check alone.

A third acceptable threat: Repudiation - a user denies they changed their own password. Mitigation: log all authentication and account-change events with a timestamp and user ID in a tamper-evident audit log.

Marking criteria: 1 mark for each correctly identified and named STRIDE threat (2 marks), 1 mark for each threat correctly explained in the context of a login feature (2 marks), 1 mark for a correctly matched, specific mitigation for at least one threat.

SAST only analyses source code without executing it, so it can only detect patterns it has been programmed to recognise, such as an obviously unsanitised SQL string. It cannot detect vulnerabilities that only appear when the application is actually running, for example a broken authentication flow across multiple requests, a misconfigured server header, or a logic flaw in how session state is managed.

DAST addresses this gap by sending real requests to the running application and observing its actual behaviour, so it can find vulnerabilities that only exist in the live system's configuration and runtime interactions, not just its source code.

However, DAST is itself automated and only tests for known vulnerability classes it is scripted to probe. Penetration testing adds human judgement: an ethical hacker can chain together several minor weaknesses (for example a low-severity information leak plus a predictable session token) into a serious exploit that no automated SAST or DAST tool would recognise as a combined threat.

Marking criteria: 1 mark for explaining a limitation of SAST, 2 marks for explaining what DAST adds and why, 2 marks for explaining what penetration testing adds beyond both automated approaches.

This is a 6-mark EVALUATE: markers reward a supported judgement that weighs both activities against each other, not a description of each in isolation.

Plan.

• Thesis: neither activity is "more important" in isolation; they address different failure modes, and a product without upfront threat modelling will generate far more incidents for monitoring to catch, while a product without monitoring cannot detect the threats that were missed or that emerge after release.
• Threat modelling's role: cheaply eliminates entire classes of vulnerability before a line of code is written, because fixing a design flaw during requirements costs far less than fixing it after release ("shift left"). It shapes secure requirements (e.g. mandatory MFA responding to a spoofing threat) that then flow through implementation and testing.
• Its limit: threat modelling cannot anticipate every future threat, especially new attack techniques, newly disclosed vulnerabilities in third-party libraries, or attacker behaviour that only appears once the system is live and under real load.
• Monitoring's role: catches what threat modelling missed and what changes after release, for example a spike in failed logins indicating credential stuffing, or unusual outbound traffic indicating data exfiltration. It is the only activity that operates continuously across the system's entire lifetime, not just before or during a single release.
• Its limit: monitoring is reactive. By the time an alert fires, some exposure may already have occurred; monitoring reduces the damage and time-to-detect but does not prevent the underlying design flaw from existing.
• Judgement: the two are complementary rather than competing, and treating either as sufficient on its own is the real risk; a mature secure development lifecycle needs threat modelling to minimise the number of incidents monitoring will ever need to catch, and monitoring to catch everything threat modelling could not foresee.

Marker's note: top-band answers (1) explicitly compare the two activities rather than describing them side by side, (2) use a concrete example for each (a mitigated threat from modelling; a detected anomaly from monitoring), (3) identify a genuine limitation of each activity, and (4) close with an explicit judgement rather than "both are important".

This is a 6-mark ANALYSE: markers reward tracing the same failure through multiple SDLC stages and explaining how a specific activity at each would have broken the chain, not a generic list of "be more secure" statements.

Requirements and design

Threat modelling using STRIDE would have flagged tampering and information disclosure risks around any endpoint accepting user input that reaches the database, producing an explicit requirement such as "all database queries must use parameterised statements, never string concatenation". Without this step, the vulnerable pattern was never treated as a risk to design against.

Implementation

Secure coding standards (e.g. the OWASP SQL Injection Prevention Cheat Sheet) would have directed developers to use parameterised queries or an ORM by default. A SAST tool such as Semgrep run in CI would very likely have flagged the string-concatenated SQL query automatically, before the change was even merged, since this is one of the most common patterns SAST tools are built to detect.

Testing

Because testing was skipped under deadline pressure, neither a DAST scan (which sends crafted injection payloads to running endpoints) nor a penetration test (where a human tester actively tries to break authentication and data access) had the chance to catch the flaw before release. Either would plausibly have found this specific, well-known vulnerability class.

Deployment and monitoring

Even after release, ongoing monitoring of database query patterns and error logs could have detected unusual queries or a spike in error responses consistent with injection attempts, triggering an alert before 50 000 records were exposed, or at minimum shortening the time between the breach starting and being detected.

Judgement

The breach was not caused by one missing control but by skipping an entire lifecycle stage (testing) that exists precisely to catch what earlier stages miss; the case shows why security cannot be treated as a single checkpoint, since any one of at least three independent activities (SAST, DAST/penetration testing, or monitoring) would likely have prevented or curtailed the same underlying flaw.

Marker's note: top-band answers name a specific activity per stage, explain the causal link between that activity and preventing this exact vulnerability class, and finish with a judgement about why a single missed stage (not a single missed tool) was the real cause.