Inquiry Question 2: How can the security of a developed solution be evaluated?
Describe the secure development lifecycle, including threat modelling, secure coding practices, security testing and ongoing monitoring
A focused answer to the HSC Software Engineering Module 1 dot point on the SDLC. Threat modelling, secure coding standards, code review, SAST and DAST tools, penetration testing, ongoing monitoring, and the traps markers look for.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to describe security as an integrated part of the whole software development lifecycle, not a checkbox at the end. You need to name the stages, the activities at each stage, and the tools or techniques used, and be able to explain WHY security has to be continuous rather than a single event.
The answer
The secure development lifecycle (SDLC) integrates security into every phase of software development. Industry frameworks (Microsoft SDL, OWASP SAMM, NIST SSDF) describe slightly different stages, but the structure is broadly the same five phases shown below.
1. Requirements and design
- Threat modelling: identify what could go wrong using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).
- Security requirements: write each threat-mitigation pairing as a testable requirement.
- Reference architectures: use patterns known to be secure (HTTPS everywhere, parameterised queries, MFA, RBAC) rather than reinventing.
The diagram below shows threat modelling applied to a simple client-server-database architecture: each STRIDE threat is attached to the part of the data flow where it is most likely to occur.
2. Implementation
- Secure coding standards: OWASP cheat sheets, CERT guides, language-specific guidance.
- Code review: every change peer-reviewed before merge. Reviewers look for security issues alongside correctness and style.
- Static Application Security Testing (SAST): automated code scanners (Semgrep, SonarQube, GitHub Advanced Security) catch common vulnerabilities and bad patterns.
- Secret scanning: detect API keys or passwords committed to source control.
- Dependency management: lock files, dependency scanners (Dependabot, Snyk), pin versions.
3. Testing
- Unit and integration tests for security-relevant logic (authentication, authorisation, validation).
- Dynamic Application Security Testing (DAST): OWASP ZAP, Burp Suite probe the running app.
- Penetration testing: ethical hackers attempt real attacks. Done by external firms before major releases.
- Fuzz testing: feed random or malformed inputs to find crashes and edge cases.
4. Deployment
- Hardened configuration: minimal services, secure defaults, secret management (AWS Secrets Manager, HashiCorp Vault).
- Infrastructure as code (IaC): reproducible builds, scanned for misconfigurations.
- Signed artefacts: verify integrity of binaries and container images at deploy time.
5. Operation and monitoring
- Centralised logging: capture authentication events, errors, anomalous access.
- Security monitoring: a Security Information and Event Management (SIEM) system aggregates logs and runs detection rules.
- Alerting and incident response: defined playbooks for common incidents (credential leak, suspected breach).
- Patch management: automate dependency updates, apply OS and runtime patches promptly.
- Periodic retesting: rerun the design and test stages against the live system.
Continuous, not linear
In modern practice security activities run continuously, not as a one-off audit at the end. Each pull request triggers SAST scans, dependency scans and code review. Each deploy triggers configuration checks. Each production day generates security logs that feed monitoring, which in turn informs the next round of threat modelling, closing the loop shown in the diagram above.
# Example: a GitHub Actions security stage
# .github/workflows/security.yml
"""
name: Security
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: SAST
uses: github/codeql-action/analyze@v3
- name: Dependency scan
run: pip install pip-audit && pip-audit
- name: Secret scan
uses: gitleaks/gitleaks-action@v2
"""
Exam-style practice questions
Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
2025 HSC6 marksDescribe four stages of the secure development lifecycle and explain a specific activity that occurs at each stage.Show worked answer →
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.
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation2 marksState which SDLC stage each of these activities belongs to: (a) a SAST scan run automatically on every pull request, (b) an external firm's penetration test before a major release.Show worked solution →
(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).
foundation3 marksDistinguish between SAST and DAST, giving one example tool for each.Show worked solution →
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).
core4 marksThe table below is extracted from a web application's monitoring dashboard, showing failed login attempts recorded in 15-minute windows. Time 09:00, 3 attempts. Time 09:15, 4 attempts. Time 09:30, 812 attempts. Time 09:45, 5 attempts. Identify which SDLC activity produced this data, explain what the data suggests is happening, and describe the appropriate next step.Show worked solution →
- 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).
core5 marksA team is designing a login feature. Using STRIDE, describe two distinct threats to this feature and a matching mitigation for each.Show worked solution →
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.
core5 marksExplain why relying on SAST alone is insufficient to verify a web application is secure before release, referring to both DAST and penetration testing in your answer.Show worked solution →
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.
exam6 marksEvaluate the claim that ongoing monitoring is more important than upfront threat modelling for the overall security of a software product.Show worked solution →
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".
exam6 marksA company skipped security testing before a deadline and later suffered a breach in which an SQL injection vulnerability exposed 50 000 customer records. Analyse how activities at each stage of the secure development lifecycle could have prevented this breach.Show worked solution →
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.