🔒 Secure Software Architecture

🛡️ Benefits of Developing Secure Software

🎯 (SE-12-01, SE-12-05)

📌 Describe the benefits of developing secure software, including data protection and minimising cyber attacks and vulnerabilities.

🔒 Data Protection

Secure software design ensures that personal, financial, and proprietary data is protected from unauthorised access, modification, or destruction throughout its entire lifecycle — whether at rest in a database, in transit across a network, or in active use. Data encryption (e.g., AES-256 for stored data, TLS 1.3 for data in transit) makes intercepted data unreadable to attackers. Access controls ensure only authorised users can retrieve sensitive records. In Australia, the Privacy Act 1988 and its Australian Privacy Principles (APPs) impose legal obligations on organisations to protect personal information — failure results in significant financial penalties and mandatory breach notifications under the Notifiable Data Breaches (NDB) scheme. Beyond legal compliance, effective data protection builds user trust, which is increasingly a critical competitive advantage. A single publicised data breach can permanently destroy a brand's reputation and cause lasting customer attrition.

🛡️ Minimising Cyber Attacks and Vulnerabilities

Every software vulnerability — an unintended weakness in code — represents a potential entry point for a cyber attacker. Proactively designing software to minimise vulnerabilities dramatically reduces the attack surface: the total number of possible ways an attacker could interact with or compromise a system. This is achieved through secure coding practices (input validation, parameterised queries, output encoding), regular security testing (SAST, DAST, penetration testing), and timely patching of dependencies. The economic impact of cyber attacks is severe: IBM's 2023 Cost of a Data Breach Report found the average breach cost AU$6.5 million — including incident response, legal fees, regulatory fines, and lost business. Secure software development converts this reactive, crisis-driven cost into a predictable, manageable investment in engineering quality. Additionally, minimising vulnerabilities reduces an organisation's exposure to reputational damage, intellectual property theft, and the operational disruption of ransomware attacks that can halt business operations entirely.

🔄 Applying the SDLC to Develop Secure Code

🎯 (SE-12-01, SE-12-06)

📌 Interpret and apply the fundamental software development steps to engineer secure code. Security must be embedded into every phase of the Software Development Life Cycle (SDLC) — a principle known as DevSecOps — rather than treated as a final checkbox before release.

👤 How End-User Capabilities Influence Secure Design

🎯 (SE-12-01, SE-12-07)

📌 Describe how the capabilities and experience of end users influence the secure design features of software.

A technically perfect security system that users cannot or will not use correctly provides no real protection. Engineers must design security features that are robust and usable — the two goals must be balanced, not traded off against each other.

🔐 Fundamental Software Design Security Concepts

🎯 (SE-12-04)

📌 Explore the six fundamental security concepts that underpin all secure software design decisions.

🏗️ Security by Design: Cryptography and Sandboxing

🎯 (SE-12-03, SE-12-04)

📌 Use and explain the contribution of cryptography and sandboxing to the "security by design" approach, and apply security features including data protection, security, privacy, and regulatory compliance.

🔐 Cryptography in Security by Design

Cryptography is the practice of securing information by transforming it into an unreadable form for anyone who does not hold the decryption key. In security-by-design, cryptography is not an optional add-on — it is specified in the requirements phase and embedded in the architecture from the first line of code.

🧪 Sandboxing in Security by Design

Sandboxing executes potentially untrusted code in a strictly isolated, restricted environment that has no access to the host operating system, filesystem, network, or other running processes unless explicitly permitted. If the sandboxed code is malicious or compromised, it cannot escape the sandbox to cause broader harm. Security-by-design embeds sandboxing as an architectural decision for any component that handles untrusted external input.

STRIDE Threat Modelling Process

STRIDE is a structured framework for systematically identifying threats to a system. Each letter represents a category of threat that an attacker might exploit. The process follows a repeatable cycle that teams apply to every component in a Data Flow Diagram.

STRIDE Threat Modelling Process
================================
[Identify Assets]
       |
       v
[Create Data Flow Diagram]
       |
       v
[Apply STRIDE Categories]
  S - Spoofing Identity
  T - Tampering with Data
  R - Repudiation
  I - Information Disclosure
  D - Denial of Service
  E - Elevation of Privilege
       |
       v
[Rate Each Threat] --> [Low]    --> [Document & Monitor]
       |
       +-----------> [Medium] --> [Mitigate in Next Sprint]
       |
       +-----------> [High]   --> [Fix Before Release]
       |
       v
[Implement Controls]
       |
       v
[Verify & Retest]
          

🔏 Privacy by Design

🎯 (SE-12-04, SE-12-05)

📌 Use and explain the "privacy by design" approach in the development of software solutions, including a proactive approach, embedding privacy into design, and respect for user privacy.

Privacy by Design (PbD), developed by Dr Ann Cavoukian, is a framework that treats privacy not as a legal compliance afterthought, but as a fundamental design requirement embedded into the architecture of software systems from the outset. It is now codified in major privacy legislation including the GDPR (Article 25) and increasingly referenced in Australian Privacy Act reforms.

🎯 Proactive Not Reactive Approach

A proactive approach means anticipating and preventing privacy violations before they occur, rather than detecting and remedying them after the fact. In practice, this means conducting a Privacy Impact Assessment (PIA) during the requirements phase — before architecture is finalised — to identify every point at which personal data enters, is processed, stored, or exits the system. Each data flow is scrutinised: Is this data actually necessary? Could we achieve the same outcome with anonymised or aggregated data? Could we collect less? By identifying and eliminating unnecessary data collection before code is written, engineers prevent entire categories of privacy risk from ever materialising. For example, a fitness app that collects precise GPS location for route tracking should ask: can we achieve the feature with neighbourhood-level precision rather than exact coordinates? Reducing data granularity proactively reduces the consequences of any future breach.

🏗️ Embedding Privacy into Design

Privacy must be the default setting of the system — requiring no action from the user to be protected. The most privacy-respecting option must be the path of least resistance. This principle directly counters the industry-wide practice of defaulting to maximum data collection and sharing, requiring users to navigate complex settings menus to opt out. Specific design implementations include: new social media profiles default to private; marketing email preferences default to unsubscribed; location sharing defaults to off; analytics tracking requires explicit opt-in consent, not pre-ticked boxes. Privacy-preserving defaults are required by the GDPR and are becoming standard under the Australian Privacy Act. Architecturally, data minimisation (collecting only what is genuinely necessary) and purpose limitation (using data only for the stated collection purpose, not secondary commercial uses) must be enforced at the database schema level — if a field does not exist, it cannot be misused or breached.

👤 Respect for User Privacy

Systems must offer users meaningful, granular, and genuinely exercisable control over their personal data. This is distinguished from performative compliance (lengthy privacy policies that nobody reads) by providing real mechanisms for data agency:

🩹 Testing Security, Resilience, and Business Continuity

🎯 (SE-12-06, SE-12-08)

📌 Test and evaluate the security and resilience of software by determining vulnerabilities, hardening systems, handling breaches, maintaining business continuity, and conducting disaster recovery.

🔍 Determining Vulnerabilities

Vulnerabilities must be identified before attackers find them. Engineers conduct vulnerability assessments — systematic scans of the application and its infrastructure to catalogue all known weaknesses (unpatched software, misconfigured services, exposed admin interfaces, default credentials). Vulnerability scanners (e.g., Nessus, OpenVAS) produce prioritised lists of findings rated by CVSS (Common Vulnerability Scoring System) severity. These findings are then remediated in priority order — critical vulnerabilities (CVSS 9.0–10.0) within 24 hours; high (7.0–8.9) within 7 days; medium within 30 days.

🛡️ Hardening Systems

System hardening reduces the attack surface by eliminating everything that is not strictly necessary for the system's function. A hardened production server has: all unnecessary network ports closed by firewall rules; all unused software packages, services, and user accounts removed; default passwords and credentials changed; logging enabled for all administrative actions; and automatic security updates configured. A hardened web application has: Content Security Policy (CSP) headers preventing unauthorised script execution; HTTP Strict Transport Security (HSTS) preventing protocol downgrade attacks; security headers (X-Frame-Options, X-Content-Type-Options) blocking clickjacking and MIME sniffing attacks.

🩹 Handling Breaches

An Incident Response Plan (IRP) defines the pre-agreed, structured process for managing a detected security breach: (1) Containment — immediately isolate affected systems to prevent lateral movement (e.g., take the compromised server offline, revoke compromised credentials). (2) Eradication — identify and remove the root cause (malware, backdoor, compromised account). (3) Recovery — restore systems from known-good backups and verify integrity before bringing them back online. (4) Post-Incident Review — document what happened, how it was detected, how long it took to contain, and what changes will prevent recurrence. Under Australia's NDB scheme, organisations must notify affected individuals and the Office of the Australian Information Commissioner (OAIC) within 30 days of becoming aware of an eligible breach.

🏢 Business Continuity and Disaster Recovery

Business Continuity Planning (BCP) ensures that critical business functions can continue during and after a major incident — whether a cyber attack, natural disaster, or infrastructure failure. Key metrics: RTO (Recovery Time Objective) — the maximum acceptable downtime (e.g., 4 hours); RPO (Recovery Point Objective) — the maximum acceptable data loss (e.g., 1 hour of transactions). Achieving these targets requires: geographically redundant server infrastructure; automated failover to standby systems; regular off-site encrypted backups with verified restoration procedures; and documented, regularly practised disaster recovery drills so that the response under pressure is familiar, not improvised.

🧪 Security Testing and Management Strategies

🎯 (SE-12-06, SE-12-08)

📌 Apply and evaluate strategies used by software developers to manage the security of programming code, including code review, SAST, DAST, vulnerability assessment, and penetration testing.

Practical Security Testing Checklist

The following table provides a practical checklist of security tests that developers should run at each stage of development. Many can be automated and integrated into CI/CD pipelines.

pip install bandit safety && bandit -r . && safety check

⌨️ Defensive Coding and Safe API Design

🎯 (SE-12-02, SE-12-07)

📌 Design, develop and implement code using defensive data input handling practices, including input validation, sanitisation, and error handling; and design, develop and implement a safe API to minimise software vulnerabilities.

✅ Input Validation

Input validation checks that all data received from external sources conforms to the expected format, type, length, and range before it is processed or stored. Validation must happen server-side — client-side validation is a UX convenience only; it can be bypassed by an attacker sending direct HTTP requests. Validation rules should be strict: if a field expects a 4-digit integer, reject anything that is not a 4-digit integer — including any string longer than 4 characters, any non-numeric character, and any value outside the permitted range.

🧹 Sanitisation and Error Handling

Sanitisation transforms potentially malicious input into a safe form for use in the specific context where it will appear — HTML encoding for output in web pages, parameterised queries for database operations, path normalisation for file system operations. Error handling must never expose internal system details to the user — stack traces, database connection strings, server paths, or version information all provide attackers with a map of the system architecture.

import sqlite3

# VULNERABLE - Never do this! (SQL Injection risk)
def get_user_unsafe(username):
    conn = sqlite3.connect('users.db')
    cursor = conn.cursor()
    # Attacker could input: admin' OR '1'='1
    query = f"SELECT * FROM users WHERE username = '{username}'"
    cursor.execute(query)  # DANGEROUS!
    return cursor.fetchone()

# SECURE - Parameterised query
def get_user_safe(username):
    conn = sqlite3.connect('users.db')
    cursor = conn.cursor()
    # Parameters are safely escaped by the database driver
    query = "SELECT * FROM users WHERE username = ?"
    cursor.execute(query, (username,))  # Safe!
    return cursor.fetchone()

# SECURE - Using an ORM (Django example)
def get_user_orm(username):
    # Django ORM automatically uses parameterised queries
    return User.objects.filter(username=username).first()

import html
import re
import logging

# Configure logging — errors go to a log file, not to the user
logging.basicConfig(filename='app.log', level=logging.ERROR)

def process_comment(user_input: str) -> str:
    """
    Validates, sanitises and safely stores a user comment.
    Returns a user-facing message (never internal error details).
    """
    try:
        # Validation: Enforce type and length constraints
        if not isinstance(user_input, str):
            raise ValueError("Input must be a string.")
        if len(user_input) > 500:
            raise ValueError("Comment exceeds 500 character limit.")
        if len(user_input.strip()) == 0:
            raise ValueError("Comment cannot be empty.")

        # Sanitisation: Escape HTML special characters to prevent XSS
        # e.g., <script>alert('xss')</script> → &lt;script&gt;...
        safe_input = html.escape(user_input)

        # Further sanitisation: strip any remaining script-like patterns
        safe_input = re.sub(r'on\w+\s*=', '', safe_input, flags=re.IGNORECASE)

        # Parameterised query prevents SQL injection — never use string formatting
        # cursor.execute("INSERT INTO comments (body) VALUES (?)", (safe_input,))
        return "Comment saved successfully."

    except ValueError as ve:
        # Known validation error — safe to show a generic user message
        logging.warning(f"Validation error: {ve}")
        return f"Error: {str(ve)}"
    except Exception as e:
        # Unexpected system error — log internally, show nothing revealing to user
        logging.error(f"System fault in process_comment: {e}", exc_info=True)
        return "An unexpected error occurred. Please try again later."

🔒 Input Validation and Output Encoding

Input validation rejects data that does not conform to a strict specification before it enters the system. Output encoding transforms data before it is rendered in a context (HTML, SQL, shell) so that special characters cannot be interpreted as instructions. Together they are the two-layer defence against injection and XSS attacks.

import re
import html

def validate_email(email: str) -> bool:
    """Validate email format using regex."""
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return bool(re.match(pattern, email)) and len(email) <= 254

def sanitise_username(username: str) -> str:
    """Allow only alphanumeric characters and underscores."""
    if not username or len(username) < 3 or len(username) > 20:
        raise ValueError("Username must be 3-20 characters")
    if not re.match(r'^[a-zA-Z0-9_]+$', username):
        raise ValueError("Username can only contain letters, numbers, underscores")
    return username

def encode_output(user_input: str) -> str:
    """Encode HTML special characters to prevent XSS."""
    return html.escape(user_input)

# Usage examples
print(validate_email("student@school.edu.au"))  # True
print(sanitise_username("john_doe123"))          # john_doe123
print(encode_output("<script>alert('xss')</script>"))
# &lt;script&gt;alert(&#x27;xss&#x27;)&lt;/script&gt;

🛡️ Safe API Design

An API (Application Programming Interface) that is insecurely designed is one of the most common and dangerous attack surfaces in modern software. A safe API enforces multiple protective layers:

⚡ Efficient Execution: Memory, Session and Exception Management

🎯 (SE-12-02, SE-12-07)

📌 Design, develop and implement code considering efficient execution for the user, including memory management, session management, and exception management.

💾 Memory Management

Memory management ensures that the application allocates, uses, and releases memory resources efficiently — preventing memory leaks that degrade performance over time, and preventing memory-based vulnerabilities such as buffer overflows. A memory leak occurs when allocated memory is never released after use, gradually consuming all available RAM until the application crashes or the server grinds to a halt. In Python, the garbage collector handles most memory management automatically, but engineers must still explicitly close file handles, database connections, and network sockets after use. The with statement (context manager) ensures resources are released even if an exception occurs mid-block:

# Correct: context manager guarantees file is closed even if an exception occurs
with open('data.txt', 'r') as f:
    data = f.read()
# File is automatically closed here — no memory leak possible

# Database connection — also use context manager
import sqlite3
with sqlite3.connect('app.db') as conn:
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
    result = cursor.fetchone()
# Connection automatically closed — resources freed

Session Management

Session management controls how the server tracks authenticated users across multiple HTTP requests — since HTTP is stateless, each request must carry proof of identity. Insecure session management is consistently listed in the OWASP Top 10 most critical web vulnerabilities. Secure session management practices:

Exception Management

Exception management ensures that when unexpected errors occur, the application handles them gracefully — maintaining availability for other users while preventing the exposure of sensitive system information. Unhandled exceptions that crash a web server process take the entire application offline for all users (an availability failure). Unhandled exceptions that display a stack trace to the user reveal the server technology stack, file paths, and code structure to attackers. Best practices: catch specific exception types rather than broad bare except clauses; log the full technical detail internally with a correlation ID; return a user-facing generic error message with the same correlation ID so support staff can look up the internal log; and implement a global exception handler as a last-resort safety net that catches any unhandled exception before it can crash the server process.

⚠️ Minimising Vulnerabilities in User Action Controls

🎯 (SE-12-07, SE-12-08)

📌 Design, develop and implement secure code to minimise vulnerabilities in user action controls, including broken authentication, XSS, CSRF, invalid forwarding and redirecting, and race conditions.

📁 Protecting Against File and Hardware Vulnerabilities

🎯 (SE-12-07, SE-12-08)

📌 Design, develop and implement secure code to protect user file and hardware vulnerabilities from file attacks and side channel attacks.

Protection Against File Attacks

Protection Against Side Channel Attacks

Side channel attacks exploit information inadvertently leaked through the physical implementation of a system — such as power consumption, electromagnetic emissions, execution timing, or cache access patterns — rather than flaws in the algorithm itself. The attacker does not break the cryptographic algorithm; they observe the system's physical behaviour while it executes to infer secret values.

🤝 Benefits of Collaboration in Secure Development

🎯 (SE-12-01, SE-12-05, SE-12-09)

📌 Apply and describe the benefits of collaboration to develop safe and secure software, including considering various points of view, delegating tasks based on expertise, and improving the quality of the solution.

Considering Various Points of View

Security vulnerabilities often arise from blind spots — assumptions that every developer on a team unconsciously shares. Diverse, collaborative teams with members of different backgrounds, experience levels, and technical specialisations surface these blind spots before attackers do. A junior developer may question why a legacy authentication flow uses MD5 hashing (now cryptographically broken), sparking a critical security review that a senior team that has always used it might never initiate. UX designers identify where security mechanisms create friction that users will bypass. Quality assurance engineers approach the system adversarially — trying to break it — revealing edge cases that developers, focused on making features work, did not consider. Security engineers trained in offensive techniques think like attackers, anticipating exploitation paths that application developers are not trained to see. Collaboration across these different perspectives produces a more comprehensively reviewed, higher-confidence security posture than any single expert could achieve alone.

Delegating Tasks Based on Expertise

Secure software development encompasses highly specialised domains that no single developer can master completely. Effective teams delegate responsibilities to members with the specific expertise required. Cryptography implementations (key management, protocol selection, algorithm configuration) are assigned to engineers with dedicated security training — an incorrectly implemented cryptographic protocol may appear to work correctly while providing no actual security. Front-end developers focus on output encoding, Content Security Policy configuration, and XSS prevention in the client-side code they know deeply. Database administrators design the access control and auditing configuration of database servers according to their specialised knowledge of the database engine. Network engineers configure firewalls, TLS termination, and intrusion detection systems. This deliberate delegation ensures each security domain receives the depth of expertise it requires, rather than being shallowly addressed by generalists stretched across every area simultaneously.

Quality of the Solution

Collaborative security practices — particularly peer code review and pair programming — produce measurably higher quality, more secure code than individual development. Peer code review is the single most cost-effective defect removal technique in software engineering: catching a vulnerability during code review costs a fraction of fixing it after deployment. When two developers review each other's security-critical code, logical errors, missing edge case handling, and subtle vulnerability patterns that the original author's familiarity blinds them to are caught before they ship. Collaboration also produces better documentation of security decisions — why a particular implementation was chosen over alternatives — reducing the risk that future maintainers unknowingly introduce vulnerabilities by changing security controls they do not understand the purpose of. Teams that practice collaborative security review consistently produce software with fewer critical vulnerabilities reaching production.

🏢 Benefits to an Enterprise of Secure Development

🎯 (SE-12-01, SE-12-05)

📌 Investigate and explain the benefits to an enterprise of the implementation of safe and secure development practices, including improved products, influence on future development, work practices, productivity, and business interactivity.

Improved Products or Services

Software built with security embedded from the design phase is fundamentally more reliable and trustworthy than software that has security patched on reactively. Secure products experience fewer incidents — zero outages from ransomware, no emergency patches that break existing functionality, no data breach disclosures that destroy user trust. This reliability becomes a genuine product differentiator: enterprise customers conducting vendor due diligence explicitly assess security posture (often requiring SOC 2 Type II certification or ISO 27001 compliance) before signing contracts. A demonstrably secure product wins those procurement decisions. For consumer products, trust built over years of responsible data stewardship creates brand loyalty that is enormously difficult for competitors to erode — while a single major breach can permanently destroy it.

Influence on Future Software Development

Enterprises that develop a culture of secure software engineering accumulate codified security knowledge — documented threat models, established security patterns, reusable security libraries, and tested compliance frameworks — that directly accelerates and improves the security of every subsequent product. The first product built with security by design takes significant investment to establish the patterns; the second product is built on top of proven, battle-tested security infrastructure. Over time, the enterprise develops internal expertise and reputation that attracts security-conscious talent and positions the organisation to participate in industry standards development (e.g., contributing to OWASP, Australian Cyber Security Centre guidance, or NIST frameworks), further enhancing reputation and influence. Security-mature organisations are also better positioned to respond to and shape evolving regulatory requirements — rather than scrambling to comply at the last moment.

Improved Work Practices

The implementation of DevSecOps — integrating security into every stage of the development pipeline — transforms security from a gating checkpoint at the end of the development cycle into a continuous quality feedback mechanism throughout it. Automated SAST scanning in CI/CD pipelines means developers receive security feedback within minutes of committing code, while the context of what they wrote is still fresh in mind — making remediation fast and educational. Security champions programs embed security expertise within development teams rather than siloing it in a separate security department, improving security knowledge across the entire engineering organisation. These practices systematically reduce the volume of security debt accumulated over time, resulting in a healthier, more maintainable codebase that is faster and cheaper to extend.

Productivity

Counter-intuitively, building security in from the start dramatically improves long-term development productivity. The cost of fixing a security vulnerability increases by an order of magnitude at each stage of development: a vulnerability identified by a developer during coding takes minutes to fix; the same vulnerability caught in code review takes hours; caught in testing takes days (including regression testing); caught in production requires an emergency patch, incident response, possible customer notification, regulatory reporting, and forensic investigation — potentially weeks of disrupted work. Teams that invest in shift-left security (catching vulnerabilities earlier in the development cycle) spend a fraction of the total time on security compared to teams that rely on reactive patching. Additionally, a stable, low-incident production environment means developers spend time building new features rather than responding to security emergencies.

Business Interactivity

Modern enterprises operate through an ecosystem of interconnected systems — sharing data with partners, customers, suppliers, and regulators through APIs and integrations. Secure API design (with authentication, authorisation scopes, input validation, rate limiting, and encryption) enables this business interactivity without exposing corporate systems to the security risks inherent in external connections. An enterprise with a strong security posture can participate in data-sharing partnerships that competitors with weaker security practices are excluded from — particularly in regulated industries such as healthcare (requiring compliance with Australian Digital Health Agency standards), financial services (PCI-DSS, APRA CPS 234), and government contracting (IRAP assessments). Conversely, a publicised breach or regulatory sanction can immediately disqualify an organisation from business-critical partnerships, with devastating commercial consequences.

⚖️ Social, Ethical and Legal Issues

🎯 (SE-12-05)

📌 Evaluate the social, ethical, and legal issues and ramifications that affect people and enterprises resulting from the development and implementation of safe and secure software, including employment, data security, privacy, copyright, intellectual property, and digital disruption.

Employment

The growing emphasis on software security is creating significant structural shifts in the technology labour market. Demand for cybersecurity professionals is growing rapidly — Australia faces a shortfall of tens of thousands of cybersecurity workers, with the Australian Cyber Security Centre (ACSC) reporting the sector needs to grow by 7,000 workers annually to meet demand. This creates strong employment opportunities for software engineers with security specialisations. However, automation of routine security testing (SAST, DAST, vulnerability scanning) is reducing demand for lower-skilled security roles focused on running tools and interpreting standard outputs. The remaining and growing roles require higher-order skills: penetration testers who think creatively like attackers, security architects who design systemic defences, and incident responders who manage complex breaches under pressure. Developers who do not develop security competency risk being disadvantaged as "secure by default" coding practices become a baseline expectation of all engineering roles, not a specialist add-on.

Data Security

Enterprises that handle personal data have both a legal obligation and an ethical duty to protect it. The legal framework in Australia includes the Privacy Act 1988 (Australian Privacy Principles), the Notifiable Data Breaches (NDB) scheme (requiring notification of eligible breaches to the OAIC and affected individuals within 30 days), and sector-specific requirements such as the My Health Records Act for healthcare data. The ethical dimension extends beyond legal compliance: collecting more data than necessary, retaining it longer than required, or using it for purposes beyond those disclosed to users at collection represents a breach of user trust even if it is technically legal. Engineers bear professional responsibility for the security of systems they design — a negligently designed system that suffers an avoidable breach causes real harm to real individuals whose financial, medical, or personal information is exposed. The ethical obligation is to apply due diligence in security design proportionate to the sensitivity of the data handled.

Privacy

Privacy is a fundamental human right recognised in Australian law through the Privacy Act 1988 and its APPs. Insecure software that exposes personal information — whether through a breach caused by negligent security design or through deliberately excessive data collection — violates this right with lasting consequences for affected individuals. Exposed personal information enables identity theft, financial fraud, targeted phishing, and in extreme cases stalking and physical harm. The social harm of large-scale breaches (such as the 2022 Optus breach affecting 9.8 million Australians, or the Medibank breach exposing sensitive health records) extends far beyond the immediate financial impact — creating lasting anxiety, distrust of digital services, and disproportionate harm to vulnerable individuals (domestic violence survivors, people with stigmatised health conditions) whose disclosed information can be weaponised against them. Engineers have an ethical obligation to treat privacy as a genuine design priority, not merely a compliance exercise.

Copyright

Software is protected by copyright from the moment it is created, without requiring registration. Copyright protects the specific expression of code (the actual written source code) — not the underlying idea or functionality. Enterprises must ensure they do not incorporate third-party code without the appropriate licence. Using open-source libraries requires understanding and complying with their respective licences: MIT and Apache 2.0 allow use in proprietary software with attribution; GPL-licensed code requires any derivative work to also be open source — a requirement that can force an enterprise to open-source its proprietary codebase if GPL code is incorporated without understanding this obligation. AI-generated code introduces novel copyright questions that are not yet fully resolved in Australian law — the source of training data and the originality of generated output are active areas of legal debate with significant implications for enterprise software development.

Intellectual Property

Proprietary software algorithms, architectures, and business logic represent significant intellectual property (IP) assets that secure software design must protect from theft and unauthorised disclosure. Trade secrets (unpatented technical approaches that derive value from their secrecy) are protected under common law and the Corporations Act 2001, but only if the enterprise takes reasonable steps to maintain their secrecy — which requires technical security measures (code obfuscation, server-side execution of sensitive logic, access controls, NDAs with employees and contractors) and legal protections. A security breach that exposes proprietary source code, training data for ML models, or unique business algorithms can destroy the commercial value of years of R&D investment. Additionally, engineers must ensure the software they develop does not unintentionally incorporate competitors' IP through reverse engineering — a legally and ethically fraught practice with significant liability exposure.

Digital Disruption

Highly secure, scalable digital platforms are a primary vehicle of digital disruption — displacing established industries by offering superior trust, convenience, and cost efficiency built on robust technical infrastructure. The disruption is bidirectional: secure fintech platforms (such as Afterpay, Revolut, and digital-only banks) disrupt traditional banking by offering comparable or superior financial services without physical branch infrastructure; conversely, a high-profile security failure by a disruptive digital entrant (such as a cryptocurrency exchange breach) can instantly restore consumer confidence in the incumbent institution it was displacing. For established enterprises, failing to invest in secure digital infrastructure creates vulnerability to disruption by more security-mature competitors — customers increasingly make choices based on perceived trustworthiness of digital platforms. The social dimension of digital disruption includes: geographic communities losing economic activity as digital services replace local businesses; skill displacement as digital processes automate roles that provided employment pathways; and concentration of market power in digital platform operators whose security and privacy practices affect vast user populations with limited alternatives.

🔑 Cryptography

🎯 (SE-12-04, SE-12-05)

📌 Describe symmetric and asymmetric encryption and hashing, and apply cryptographic techniques to protect data at rest and in transit.

Symmetric Encryption

The same key is used to both encrypt and decrypt data. Fast and efficient — used for encrypting files, database columns, and bulk data transfer.

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Generate a random 256-bit key (store this securely!)
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)

# Encrypt
nonce = os.urandom(12)   # 12-byte random nonce (never reuse!)
plaintext = b"Sensitive student data"
ciphertext = aesgcm.encrypt(nonce, plaintext, None)

print(f"Encrypted: {ciphertext.hex()}")

# Decrypt
recovered = aesgcm.decrypt(nonce, ciphertext, None)
print(f"Decrypted: {recovered.decode()}")

🔐 Asymmetric Encryption

Uses a mathematically linked key pair: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the private key.

🔑 Password Hashing

Hashing is a one-way transformation — you cannot reverse a hash to get the original data. Never store passwords in plaintext or with simple hashing (MD5/SHA-1 are broken for passwords). Always use a purpose-built password hashing algorithm that includes salting and is deliberately slow.

import bcrypt

# Hashing a password (at registration)
password = "MySecretP@ss"
hashed = bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt())
print(hashed)   # b'$2b$12$...' — includes the salt

# Verifying (at login) — never compare hashes directly
def check_login(entered_password, stored_hash):
    return bcrypt.checkpw(entered_password.encode('utf-8'), stored_hash)

print(check_login("MySecretP@ss", hashed))   # True
print(check_login("WrongPassword", hashed))  # False

🔐 API Security & JWT

🎯 (SE-12-04, SE-12-05)

📌 Apply authentication and authorisation mechanisms to secure web APIs — distinguishing between verifying identity and controlling access.

🛂 Authentication vs Authorisation

🎟️ JWT (JSON Web Tokens)

A JWT is a compact, URL-safe token consisting of three Base64-encoded parts separated by dots: Header.Payload.Signature. The server signs the token with a secret key — any tampering with the payload invalidates the signature.

JWT Authentication Flow
────────────────────────────────────────────────────
1. User sends POST /login with {username, password}
2. Server verifies credentials → generates JWT
   JWT = {header}.{payload}.{HMAC_signature}
   Payload contains: {user_id, role, exp: timestamp}
3. Server returns JWT to client
4. Client stores JWT (localStorage or secure cookie)
5. Client sends JWT in every request:
   Authorization: Bearer eyJhbGciOiJIUzI1...
6. Server verifies signature + checks expiry → grants access
────────────────────────────────────────────────────

import jwt
from datetime import datetime, timedelta, timezone

SECRET_KEY = "your-secret-key-keep-private"   # In production: use env variable

# Generate a token (at login)
def create_token(user_id, role):
    payload = {
        "user_id": user_id,
        "role": role,
        "exp": datetime.now(timezone.utc) + timedelta(hours=24)
    }
    return jwt.encode(payload, SECRET_KEY, algorithm="HS256")

# Verify and decode a token (on each protected request)
def verify_token(token):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return payload
    except jwt.ExpiredSignatureError:
        return None   # Token has expired
    except jwt.InvalidTokenError:
        return None   # Token is tampered or invalid

token = create_token(user_id=42, role="student")
print(verify_token(token))
# {'user_id': 42, 'role': 'student', 'exp': ...}

🔍 Security Testing Tools

🎯 (SE-12-04, SE-12-05)

📌 Describe tools used for security testing and apply static analysis tools to identify vulnerabilities in Python code.

# Install both tools
pip install bandit safety

# Run bandit on your Python project
bandit -r ./myproject/
# Reports severity (HIGH/MEDIUM/LOW) and CWE identifiers

# Check dependencies for known CVEs
safety check
# Scans requirements.txt against the safety vulnerability database

🛡️ Systematic Debugging Process

When a security vulnerability is identified, engineers use a systematic process to resolve it:

1. 🔍 Observe: Identify the unintended behaviour (e.g., "The application allows login without a password if a specific header is sent").
2. 🧪 Isolate: Create a minimal, reproducible test case that triggers the vulnerability.
3. 🧠 Hypothesise: Determine the root cause (e.g., "The authentication middleware is skipped for certain header combinations").
4. 🛠️ Test: Apply a fix and verify it closed the vulnerability without breaking other features.
5. ✅ Verify: Run the complete regression test suite and security scans.

🚨 Incident Response — What To Do When Breached

1. Detect & Contain: Isolate affected systems. Revoke compromised credentials. Stop the breach from spreading.
2. Assess Impact: What data was accessed? How many users affected? What systems were compromised?
3. Notify Stakeholders: Management, legal, and (where required by law) regulators and affected individuals.
4. Eradicate Threat: Remove malware, close the vulnerability, patch all affected systems.
5. Recover Systems: Restore from clean backups. Reset all potentially compromised credentials.
6. Post-Incident Review: Root cause analysis, update security policies, implement additional controls.