3.2.3 - Robust software and vulnerability detection
A program can appear reliable until an unexpected value or a hidden weakness puts it under pressure. In this lesson, you will judge what makes software robust, connect vulnerabilities to their exploitation, and use audit trails and code reviews to find evidence of weaknesses.
Robust by design
Suppose a school uses software to record loans of laptops. The program must store the borrower, the device and a loan duration from 1 to 14 days. It needs to work for an ordinary loan, but its real quality becomes clearer when someone enters a value such as 0, -3 or three.
Robust software
Software that behaves correctly and predictably within its stated operating conditions, including handling invalid or unexpected input safely instead of crashing or corrupting data.
Robust software has several connected characteristics:
- It meets its stated requirements and gives accurate, suitable output for valid input.
- It validates unsuitable data and responds predictably, for example by rejecting it and giving a useful message.
- It avoids a crash or unwanted data change when it receives anticipated invalid input.
- Its security weaknesses are identified and addressed so that data and functions are not needlessly exposed.
Robustness is always considered against the program's requirements and constraints. It does not mean that the software has every possible feature, or that nobody could ever make it fail under any imaginable condition.
Developing robust software matters because incorrect or unpredictable behaviour can create wrong records, disrupt access and expose confidential data. Finding and addressing weaknesses before release reduces harm to users and the time and cost of correcting failures later.
Worked example: judging responses
Requirement: loanDays must be a whole number from 1 to 14 inclusive.
| Input | Robust response | Why it is robust |
|---|---|---|
7 | Accept the value and calculate the due date correctly. | The valid input meets the requirement and produces the expected result. |
0 | Reject the value, explain that 1 to 14 is required, and leave the loan record unchanged. | The response is predictable and does not store invalid data. |
three | Reject the value safely and request a whole number. | Unexpected data does not make the program crash or corrupt the record. |
A program that silently stores 0 has not met the requirement. A program that crashes on three is also not robust, even if it works perfectly for 7.
Robustness is shown by correct behaviour for valid input and safe, predictable behaviour for anticipated invalid input.
The important link in an explanation is not just "the program validates data"; it is what that validation prevents.
From weakness to consequence
Robust software must also resist weaknesses that could put its data or functions at risk.
Vulnerability
A weakness in software or its design that could be exploited to compromise data, access or the system's operation.
A vulnerability is the weakness. Exploitation is the act of taking advantage of it. The result is a consequence. Keeping these three stages separate makes an explanation precise.
| Vulnerability | How it could be exploited | Possible consequence |
|---|---|---|
| Weak authentication, such as one shared, easily guessed staff PIN | An unauthorised person learns or guesses the PIN and signs in as staff. | Loan records can be viewed or changed without permission. |
| Sensitive data stored without encryption | A criminal obtains a copied or stolen data file and reads it directly. | Confidential personal data is disclosed. |
| Inadequate input validation | Deliberately crafted or invalid input is accepted by the software. | The software may perform an unintended action, store incorrect data or stop working. |
| A programming or design error | A criminal discovers the faulty route through the program and uses it to bypass an intended restriction. | Protected data or functions become accessible. |
Worked example: build the chain
The loan system gives every technician the same four-digit PIN.
- Weakness: authentication is weak because the credential is shared and easy to pass on.
- Exploitation: an unauthorised student obtains the PIN and uses it to sign in as a technician.
- Consequence: the student can transfer a laptop loan to a different borrower.
Saying only "a hacker gets in" misses the defining weakness and the action that uses it. Also, the existence of a vulnerability does not prove that it has already been exploited; it means exploitation is possible.
Evidence from audit trails
Once software is being developed or used, actions and changes can leave a record that helps people identify suspicious behaviour or investigate a weakness.
Audit trail
A chronological record of events or changes that allows an action to be traced to a time and an account, user or process.
A useful audit-trail entry commonly records:
- a date and time;
- the account or process used;
- the action and the item affected;
- old and new values when a change is made;
- whether the action succeeded or was denied.
Consider this original extract from the equipment-loan system:
| Event | Time | Account | Action | Outcome |
|---|---|---|---|---|
| A17 | 09:12:08 | tech_04 | Signed in | Successful |
| A18 | 09:14:31 | tech_04 | Changed device L-842 borrower from student_118 to student_105 | Successful |
| A19 | 09:15:02 | student_105 | Viewed device L-842 | Successful |
| A20 | 09:16:44 | tech_04 | Tried to export all 312 loan records | Denied |
Worked example: turn entries into evidence
The trail shows that account tech_04 changed a borrower and then attempted a large export just over two minutes after that change. That sequence is worth investigating. It could expose unexpected use of an account or point investigators towards an authorisation weakness.
The wording must stay precise: the trail proves that the account tech_04 was used. It does not by itself prove which person was at the keyboard, because credentials might have been shared or stolen.
Audit trails are useful because they can:
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account