VCE Software Development - U4O2 - Cyber Security: secure software development practices Hangman

The 129 key terms

1organisational objective

A measurable target, such as growth, profit, customer trust or compliance, that a medium or large organisation sets to achieve its goals and that its software must support.

2security objective

A goal to protect data and systems, because a security failure can damage an organisation's reputation, finances and ability to keep operating.

3Medium and large organisations

Organisations with more staff, bigger budgets, more systems and users, formal policies and dedicated security teams, so they manage software development and its risks more formally.

4In-house development

Software built by the organisation's own staff, giving it direct control over the code, security practices, data and developers.

5In-house development disadvantages

Building software with your own staff can cost more, take longer to start, and depend on the skills, capacity and availability of staff, who may leave.

6External development advantages

Hiring an outside developer gives specialist skills and extra capacity, often with faster delivery and a fixed contract cost, without hiring permanent staff.

7External development risks

Using an outside developer gives the organisation less control over security, means sharing data with a third party, and can raise IP ownership and vendor dependency risks.

8sourcing decision

Choosing in-house or external developers by weighing cost, skills, control, security and time against the organisation's objectives, sometimes using a hybrid of both.

9asset

Anything of value in a digital system that needs protecting, such as data, accounts, devices or services. Examples: a student database (data) or a school laptop (hardware).

10threat

Anything that could cause harm to an asset, such as an attacker, malware, human error or a power failure. Threats can be deliberate or accidental, and internal or external.

11threat actor

A person or group that carries out an attack on a system, described by their motive (why) and skill (how able). Examples: cybercriminals, hacktivists, insiders and nation-state groups.

12vulnerability

A weakness in software, hardware, a process or a person that a threat could use to harm an asset. A vulnerability is only a weakness, not an attack.

13exploit

A method or piece of code that takes advantage of a vulnerability (a weakness) to attack a system. The weakness is the open door; the exploit is the tool that gets through it.

14attack surface

All the points where an attacker could try to get into a system or take data out, such as open ports, running services and user accounts. A smaller attack surface means fewer ways in.

15Confidentiality

Only authorised people or systems can read data. Everyone else is kept out, like student marks seen only by the student and teacher. A breach is when someone else sees them.

16Integrity

Data stays accurate and unaltered unless an authorised person changes it. Accidental or deliberate changes break it, such as a tampered bank balance.

17Availability

Authorised users can reach data and systems when they need them, such as a school network that stays up. Attacks and hardware failure can reduce it.

18risk = likelihood x impact

Risk is how likely a threat is to succeed combined with how much harm it would cause. Rate each as low, medium or high to decide which risks matter most.

19software vulnerability

A flaw or bug in a program's code or settings, such as a coding mistake or an insecure default, that an attacker could use to get access or cause damage.

20cyber security incident

An event that actually or potentially compromises the confidentiality, integrity or availability of an organisation's systems or data, such as a breach or malware infection.

21data breach

When attackers get into an organisation's stored data, such as usernames and passwords. Find out through alerts, then change your password and turn on MFA.

22development, testing and production

The three environments software moves through: development is where code is written, testing is where it is checked with test data, and production is where real users use live data.

23insecure development environment

A workspace where weak controls over people, tools, code and data let vulnerabilities enter the software or let attackers reach it.

24API

Application programming interface: a set of defined requests that lets one piece of software use the data or functions of another, such as sending a request and getting a response back.

25API security risk

An API is risky when it lacks authentication, input validation or rate limits, so attackers can send requests straight to it and steal data or misuse it.

26hard-coded secret

A key, password or token written directly into source code. Anyone who can read the code or its repository can steal it, and deleting the file later does not remove it from the history.

27Malware

Malicious software designed to damage, disrupt, or gain unauthorised access to a computer system

28Spyware

Malware that secretly monitors a user's activity and collects information without their knowledge or consent

29Ransomware

Malware that encrypts or locks a victim's files and demands payment to restore access

30Outdated software

Software that hasn't been updated with the latest security patches, leaving known vulnerabilities open for attackers to exploit.

31zero-day

A vulnerability that attackers know about before the software maker has released a fix. With no patch available yet, defenders rely on workarounds and monitoring.

32Unpatched software

Software missing security updates, so known flaws stay open. In a dev environment, attackers can use them on developer machines or build servers to reach code and data.

33Poor identity and access management

Weak control of accounts, permissions and logins, such as shared accounts or no MFA, so the wrong people or systems can reach code and data.

34Weak password

A password that is short, common, or predictable, making it easy for attackers to guess or crack.

35Improper credential management

When passwords, keys or tokens are stored, shared or reused insecurely, letting attackers steal them and gain unauthorised access.

36man-in-the-middle attack

An attack where someone secretly sits between two parties and can read or change the data passing between them, such as logins, session tokens or code sent over an unsecured network.

37Unsecured Wi-Fi

A network with no encryption, letting attackers intercept the data sent across it.

38insider threat

Harm to data or systems caused by someone with legitimate access, either on purpose (malicious insider) or by mistake, like emailing the wrong person or setting a file to public.

39software supply chain

Everything used to make and deliver software: code libraries, tools, build systems, suppliers and updates. Most of an app is other people's code, so you trust every link in the chain.

40dependency

A library or package written by someone else that your program imports and relies on. If it has a flaw, every app that uses it is affected, including via dependencies of dependencies.

41Supply chain attack

An attack where criminals hide malicious code in a trusted supplier's software update, so users install it believing it is safe.

42typosquatting

Publishing a malicious package or site with a name almost the same as a trusted one (like reqeusts for requests), hoping people install or visit it by mistake.

43third-party software risk

Risk from software bought, outsourced or downloaded, as you cannot fully see or control how it was built and maintained (poor code, backdoors, no support, licence issues).

44ineffective code review

Code review that is skipped, rushed, done only by the author or lacks a security checklist, so flaws get merged and reach production.

45input validation

Checking that data a user enters is the expected type, length and format before the program uses it, so bad or harmful input is rejected.

46SQL injection

An attack where database commands are typed into an input field and run because the program joins the input straight into a query. Parameterised queries stop it.

47combined environment

One shared environment used for development, testing and production, so untested code and live data mix and mistakes or attacks can reach real users and data.

48version control

A system that records every change to project files, so developers can see who changed what, work in parallel on branches, and roll back to an earlier version.

49code repository

A central store for a project's source code and its version history, shared by a team through commits, branches, pull requests and access settings (private or public).

50repository security

Controlling who can read and change a code repository and protecting what is stored in it, e.g. private repos, roles, a protected main branch, no secrets in commits, audit logs.

51Authentication vs authorisation

Authentication checks who you are, like logging in. Authorisation decides what you can do once you are known, like which files you can open. Authentication always comes first.

52principle of least privilege

Give every user, program and device only the minimum access it needs to do its job. This limits the damage if an account is stolen, and unneeded access should be removed.

53Role-based access control (RBAC)

A way to manage access by giving permissions to roles, like student, teacher or admin, then assigning each user a role. Changing a user's role changes what they can access.

54MFA methods

Ways to prove it's you: an SMS code, an authenticator app, a biometric like a fingerprint, or a physical security key. They differ in how easy they are to use and how strong they are.

55second factor

An extra proof of identity, like a code from your phone, needed after the password. A thief with only your stolen password can't log in without it.

56access log

An automatic record of who accessed a system or file, what they did and when. It helps spot failed logins and misuse, and holds users accountable for their actions.

57Encryption

Turning a readable message into a scrambled, unreadable message using a key, so it can only be read again with decryption.

58Symmetric encryption

Using the exact same secret key to both lock and unlock a message.

59Asymmetric encryption

Encryption that uses a linked pair of keys: a public key to encrypt data and a private key to decrypt it, with no shared secret key needed.

60Encryption at rest and in transit

Encrypting data both while stored (databases, backups) and while moving over a network (TLS), so intercepted or stolen data stays unreadable without the key.

61HTTPS

A secure way for your browser to talk to a website. It encrypts the data you send and receive, and shows https:// and a padlock in the address bar. A padlock does not prove a site is trustworthy.

62peer code review

Another developer checks a change before it is merged, using a checklist that includes security checks, and approves it. The decision is recorded on the pull request.

63automated code analysis

Tools that scan source code or dependencies for known insecure patterns and vulnerable components. They support, but do not replace, human code review.

64patch management

The regular, planned process of finding, testing and installing updates that fix known vulnerabilities in software, including libraries and frameworks.

65Operating system update

Installing the latest patches for the OS, fixing known security vulnerabilities and bugs.

66Environment separation

Keeping development, testing and production apart so untested code and live data never mix, and access to each is controlled separately. It also helps contain a breach.

67secrets management

Keeping passwords, API keys and tokens in a protected vault or environment variable, not in source code, and rotating keys and scanning commits for leaks.

68Code signing

Code signing adds a digital signature to software so a computer can check it came from the named publisher and has not been changed since it was signed.

69SBOM

A software bill of materials: a list of every component and library inside a piece of software, with version numbers, so owners can check each one for known vulnerabilities.

70reduce supply chain risk

Use fewer, trusted dependencies, pin versions, verify integrity and scan for known vulnerabilities so a weak link in code you rely on cannot harm your system.

71threat modelling

A structured way to work out what could go wrong with a system, before and during development, so risks are found, fixed and confirmed early and then reviewed again.

72security requirement

A statement of the protection a system must provide for its data and functions, based on its assets, users and laws, written so it can be tested.

73measurable non-functional requirement

A quality of a solution, such as speed, security or usability, written with a testable target, like a page loads in under 2 seconds, so you can check whether it is met.

74data flow diagram

A diagram that shows how data moves between users, processes, data stores and external services in a system, using labelled arrows for each flow.

75trust boundary

A line on a diagram where data passes between parts of a system with different levels of trust, such as from a user's device to a server. Threats often cluster here.

76STRIDE

A memory aid for six threat types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Use it to ask what could go wrong in a system.

77attack tree

A diagram with the attacker's goal at the top, branching into the different ways to reach it. OR branches are alternatives, AND branches are all needed.

78risk matrix

A grid that plots how likely a threat is against how bad its impact would be, giving each risk a priority rating (such as low, medium or high) so you know which to fix first.

79threat model table

A table with one row per threat. Columns record the asset, threat, vulnerability, risk rating and chosen control, e.g. a school app storing student data.

80security control

A measure that reduces risk by preventing an attack, detecting it or helping recovery. Controls can be technical, physical or procedural, and layering several works best.

81Risk treatment

Matching each threat to a response chosen by its risk rating: eliminate it, reduce it, transfer it (e.g. insure) or accept it. High risks are treated first.

82Verification testing

Retesting a control after it is applied, using code review and security tests, to prove the threat is reduced, check no new weakness exists, note residual risk and record the evidence.

83Ethical hacking

Authorised testing of a system to find security vulnerabilities before malicious attackers can exploit them.

84threat model review

Checking and updating a threat model whenever the system, its users or the known threats change, for example after a new feature, a new dependency or a new control.

85evaluation criteria

Measurable standards, such as access control, code review, patching and training, used to judge how effective and compliant an organisation's development practices are.

86rate and justify

Judge a practice as met, partly met or not met against one criterion, then justify the rating by quoting evidence from the case study and explaining the consequence.

87Analysing a case study

Describe how the organisation builds software: who is involved, which environments and tools it uses, and which security controls it has, then spot gaps.

88gap analysis

Comparing a case study's current practices with secure practice to find vulnerabilities, then rating the risk each gap creates by its likelihood and impact.

89Regulatory compliance

Meeting the legal and industry rules that govern how an organisation must secure its data and systems.

90Copyright Act 1968 (Cwlth)

Australian legislation that automatically protects original creative works, like software and images, from being copied or used without permission

91The Essential Eight

A set of eight baseline security strategies created by the Australian government to help reduce the risk of cyber security incidents.

92patch applications and operating systems

Two Essential Eight strategies: apply security updates to apps and operating systems promptly, with critical patches done fast, so known vulnerabilities are closed before attackers exploit them.

93restrict administrative privileges

An Essential Eight strategy: give admin accounts only to people who need them, only for tasks that need them, using separate admin accounts and limited production access.

94Application control and MFA

Essential Eight controls: application control lets only approved software run, and MFA needs extra proof of identity, so both block unauthorised access and malware.

95regular backups

An Essential Eight strategy: keep tested, protected copies of data and code, made often, so work can be restored after loss, tampering or ransomware.

96Information Security Manual

A document created by the Australian government that provides detailed guidance organisations can follow to protect their systems and data.

97ISM Guidelines for Software Development

ISM guidelines that set security expectations for how software is designed, coded, tested and released, such as secure coding, separate environments, code review and testing.

98ISM encryption guideline

A rule that tells organisations to encrypt sensitive data, both when stored and when sent, so it stays protected.

99Privacy Act 1988

Commonwealth legislation that sets rules for how organisations must collect, use, and store people's personal information.

100Australian Privacy Principle 1

Requires organisations to be open and transparent about managing personal information, with a clear, available, up-to-date policy.

101Australian Privacy Principle 6

Requires organisations to only use or disclose personal information for the purpose it was originally collected for, unless consent or an exception applies.

102APP 8

Before sending personal information overseas, such as to a cloud server, an organisation must take reasonable steps to make sure the overseas recipient will also protect it.

103APP 9

An organisation must not adopt a government identifier (e.g. Medicare or tax file number) as its own ID for a person. It should use its own customer ID, with limited exceptions.

104Australian Privacy Principle 11

Requires organisations to protect personal information from misuse, loss, and unauthorised access, and to destroy it when no longer needed.

105Privacy and Data Protection Act 2014

Victorian legislation that sets rules for how the Victorian public sector must collect and securely protect personal information.

106IPP 1

Information Privacy Principle 1 (Vic): only collect personal information that is necessary for your functions, collect it lawfully and fairly, and tell people why you are collecting it.

107Information Privacy Principle 2

Requires personal information to be used or shared only for the purpose it was originally collected for, unless consent or an exception applies.

108Information Privacy Principle 4

Requires organisations to take reasonable steps to protect personal information from misuse, loss, unauthorised access, and unwanted modification.

109Information Privacy Principle 5

Requires organisations to be open and transparent about managing personal information, with a clear, available, up-to-date policy.

110IPP 9 transborder data flows

IPP 9 lets an organisation send personal information outside Victoria only if the recipient is bound by similar privacy protection, or the person consents.

111Apply a privacy principle

Identify the personal information involved, state what the principle requires, then judge whether the organisation's development practice meets it.

112Ineffective security practices

An ethical issue: people whose data is held can be harmed by a breach the organisation could have prevented, so it has a duty of care to protect them and be open if it fails.

113AI code generation

Using AI tools, like editor assistants and chatbots, to turn plain-English prompts into program code. It saves time, but the code must still be checked and tested by the programmer.

114Verify AI-generated code

Read and trace AI code, then test it with your own boundary and invalid data, and check it meets the requirements. It can look right but be wrong or use made-up functions.

115confidential data

Private information like personal data, passwords or secret code. Never paste it into an AI tool, as it may be stored or used to train the model. Use fake sample data and check the data policy.

116AI over-reliance

Trusting AI-generated code without checking it. The code may be biased, outdated or insecure, and you lose your own skills and judgement. Always review it and stay in control.

117AI Ethics Principles

A voluntary Australian framework of guidelines intended to help ensure AI systems are designed and used safely, fairly, and responsibly

118copyright

The legal right of the person who writes original code to control who can copy, share or sell it. Others need the owner's permission, even for a classmate's code.

119software licence

A legal agreement stating how you may use, change and share code. Open-source licences allow reuse if you follow their terms, such as giving credit to the author.

121copyright infringement

Using someone else's code, including AI output that copies licensed work, without checking its source or licence. It can breach copyright and is an ethical issue for developers.

122legal and ethical consequences

Penalties, lost customer trust and harm caused by weak security in development, such as privacy breaches or copyright infringement, resolved through compliance, openness and better practices.

123mitigation measure

An action that reduces or eliminates a specific threat, vulnerability or risk, such as a technical, process or people control matched to the risk it addresses.

124Staff procedure

A documented rule employees must follow, such as reporting incidents or locking devices, to reduce cyber security risk.

125incident response plan

A plan written in advance that sets out who does what to detect, contain, recover from and learn from a cyber security incident, including roles, contacts, reporting and review.

126Onboarding and induction

Introducing new developers to an organisation's security policies, tools and expected practices from their first day, so they work securely from the start.

127Developer training

Ongoing training that gives developers the skills and awareness to write secure code and spot threats such as phishing, which reduces human error.

128risk management plan

A document that identifies risks to software development, rates them, assigns responses and owners, and sets a schedule for regular review. It links to the threat model.

129risk register

A table listing each project risk with its likelihood, impact and planned response (like backups), so the team can tackle the biggest risks first and review them often.

130recommendation

A specific improvement linked to an identified weakness and justified by its benefits, its costs and the criteria it improves, such as laws, frameworks or measurable security.