NSW HSC Software Engineering

Why security is built in

Software that handles other people's data becomes a target the moment it is deployed. Secure software is written so that the data it holds and the actions it allows are protected from people who should not have them, and it is treated as a requirement from the first day of a project rather than a patch added before release. The reason is cost and reach: a flaw found in design is a change to a diagram, while the same flaw found after installation means changing code, retesting, redeploying and, if data has already leaked, telling the people affected.

The benefits fall into two groups.

Data protection

Most applications store something a person would not want exposed: names, addresses, payment details, health records, passwords, messages. Secure development protects this data while it is stored, while it moves between a user and a server, and while it is being processed. Protecting it keeps a business inside privacy law, keeps customers willing to hand the data over, and avoids the direct costs of a breach such as fines, compensation and the work of investigating what was taken.

Minimising cyber attacks and vulnerabilities

A vulnerability is a weakness that an attacker could use, such as a form field that accepts anything typed into it, and a cyber attack is an attempt to use one. Secure practices shrink the number of vulnerabilities that ship and make the ones that remain harder to use. An attacker looks for the easiest target, so software that validates its input, limits what each user can reach and keeps its components up to date is passed over in favour of software that does not. Fewer successful attacks means fewer outages, less data loss and less time spent on emergency repairs.

The development steps and where security fits

There are eight fundamental steps. They run in this order, and each has a security job as well as its ordinary one.

The steps are not always a straight line. A test may send the team back to design, and maintenance often restarts the whole cycle for a new feature. What stays constant is that a requirement missed at the start, such as the need to keep a log of who changed a record, is expensive to add later because design, code and tests all have to change.

A worked illustration

A clinic commissions an appointment booking system. At requirements definition the team records that patient names and phone numbers are personal information and that only reception staff and the patient may see a booking. In specifications this becomes two testable statements: a patient account can read only its own bookings, and reception accounts can read all bookings for their clinic. At design the team decides that every request is checked against the signed-in user's role before any data is returned. At testing, one test signs in as patient A and tries to open patient B's booking and expects a refusal. At installation the default administrator password supplied with the database is replaced. At maintenance a library used for sending reminders is updated when a security fix is published. Each step has a concrete outcome, and none of them is possible unless the requirement was written in the first step.

How end users shape secure design

Security features are only effective when people can use them correctly, so the capabilities and experience of end users affect what is designed. Two principles follow.

The first is that the design must suit what users can actually do. A feature that asks for a long random password and a change every month will lead users who are not technically confident to write passwords down or reuse them, which is less secure than a simpler rule backed by something the user does not have to remember. For such users, a design might use a password manager prompt, a one-time code sent to a phone or sign-in through an existing trusted account. For a team of system administrators, the same software can reasonably expect key-based logins and command-line configuration.

The second is that the interface must make the safe action the easy one. Warnings that appear on every screen are dismissed without being read, so a design that reserves a prominent warning for genuinely risky actions, such as deleting an account or sharing a file publicly, is more effective. Clear wording matters as much as the control: "Anyone with the link can view this file" tells the user something that "Sharing enabled" does not.

Experience also determines how much the software must defend against mistakes. Novice users are more likely to enter data in the wrong format, click a phishing link or share an account, so the software validates more, confirms destructive actions and limits what a single account can do. Users with accessibility needs, including those who rely on screen readers or have low vision or limited motor control, must be able to use the security features too: a CAPTCHA with no audio alternative locks some people out, and a time limit on a one-time code can be impossible for someone who types slowly. A security measure that some legitimate users cannot pass is a defect in the design.