HSC Software Engineering Module 1 Secure Software Architecture deep dive

How Module 1 fits into HSC Software Engineering

Secure Software Architecture is Module 1 of Year 12 Software Engineering, and it sets up ideas that recur throughout the course. The Programming for the Web module reuses these security concepts when it covers web vulnerabilities, and the Software Engineering Project module reuses the secure development lifecycle. NESA examines this module heavily, and the OWASP Top 10 is the single most reliably tested list in the course.

The module asks you to design software with security built in from the start, reason about threats, and pair each risk with a concrete mitigation a developer can implement. This guide walks through the CIA triad, authentication and authorisation, encryption and hashing, the OWASP Top 10, input validation, and the secure development lifecycle, with worked examples in the style NESA uses.

The CIA triad

Three objectives sit at the centre of software security.

Every control maps to one or more of these. Encryption protects confidentiality. Hashes and digital signatures protect integrity. Backups, redundancy and protection against denial-of-service attacks support availability. When you answer a design question, name which leg of the triad a control supports; markers reward that linkage.

Authentication and authorisation

These two are constantly confused, so be precise.

Authentication mechanisms include passwords (hashed and salted), multi-factor authentication (something you know, have, and are), and token-based or session-based login. Authorisation mechanisms include role-based access control (assigning permissions to roles such as user and admin) and object-level checks (confirming the current user owns the specific record they request). A common exam trap is hiding an admin button in the user interface but forgetting the server-side check, which leaves the endpoint exposed.

Encryption: symmetric and asymmetric

In practice the two combine. HTTPS uses asymmetric cryptography during the TLS handshake to agree on a shared symmetric session key, then uses fast symmetric encryption for the actual traffic. Digital signatures use the private key to sign and the public key to verify, which provides integrity and non-repudiation.

Hashing and password storage

Hashing is one-way. A hash function maps any input to a fixed-length digest that cannot be reversed. You never decrypt a password; you hash the submitted password and compare digests.

Correct practice uses a slow, purpose-built password hashing function (bcrypt, scrypt or Argon2) with a unique random salt per user. The slowness frustrates brute-force attacks; the salt ensures identical passwords produce different hashes and defeats precomputed rainbow tables. The following Python uses bcrypt correctly.

import bcrypt

def hash_password(plain: str) -> bytes:
    # bcrypt generates and embeds a random salt automatically
    return bcrypt.hashpw(plain.encode("utf-8"), bcrypt.gensalt(rounds=12))

def verify_password(plain: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(plain.encode("utf-8"), stored_hash)

The salt is generated by gensalt and stored inside the resulting hash string, so each user's hash is unique even if two users pick the same password.

The OWASP Top 10

The Open Worldwide Application Security Project publishes the Top 10 most critical web application security risks. The 2021 list is the current reference. You should be able to name a risk, give a concrete example, and state a mitigation.

You will not be expected to recite all ten verbatim under pressure, but you should know the most-examined ones cold: broken access control, injection (especially SQL injection and cross-site scripting), and cryptographic failures. For each, practise the example-plus-mitigation pattern.

Risk	Example	Mitigation
Broken access control	Changing /api/orders/123 to /124 to read another user's order	Object-level authorisation on every endpoint; deny by default
Injection	SQL injection through string-concatenated queries	Parameterised queries; allow-list input validation
Cryptographic failures	Passwords stored in plain text; traffic over HTTP	Hash with bcrypt or Argon2; enforce HTTPS everywhere

Input validation and sanitisation

The server is the trust boundary. All input from the client must be validated (does it meet the expected format and range) and sanitised or safely handled (so it cannot be interpreted as code).

Validation defends against many OWASP risks at once. Parameterised queries stop SQL injection. Context-aware output encoding stops cross-site scripting. Length and type checks stop buffer and logic errors. Note that the legitimate way to defend against script injection is to encode output for its context, not to write <script> tags yourself; the literal script examples you see in the web vulnerabilities dot points are lesson content showing what an attack looks like.

The secure development lifecycle

Security is built in across every phase, not bolted on at the end.

The economic argument is central: fixing a vulnerability found during design costs a fraction of fixing it after a breach in production. Threat modelling early, reviewing code, and scanning dependencies catch issues before they ship.

Common Module 1 examiner traps

• Confusing authentication with authorisation.
• Saying "encrypt passwords" instead of "hash and salt passwords".
• Naming an OWASP risk without a concrete example or a specific mitigation.
• Relying only on client-side validation.
• Treating security as a final testing step rather than a lifecycle concern.

Check your knowledge

Answer all questions under exam conditions, then mark against the solutions block.

1. (3 marks) Define each component of the CIA triad and give one security control that supports each.
2. (4 marks) A developer says "we encrypt our users' passwords with AES so they are safe". Explain what is wrong with this approach and describe the correct way to store passwords.
3. (5 marks) For three risks from the OWASP Top 10, give a concrete attack example and a specific developer-side mitigation. Tie each mitigation to a phase of the secure development lifecycle.
4. (4 marks) Explain why input validation performed only in the browser is insufficient, and describe where and how validation should be performed instead. Include the difference between an allow-list and a deny-list.
5. (4 marks) Compare symmetric and asymmetric encryption, and explain how HTTPS uses both during and after the TLS handshake.

Where to go next

Practise these ideas in exam format with our HSC Software Engineering practice questions, and see how security applies to real web applications in the Programming for the Web deep dive. For dot-point answers, browse the full syllabus index.

For the official syllabus, refer to NESA at educationstandards.nsw.edu.au.