Revision notes for Edexcel GCSE Computer Science Robust software and identifying vulnerabilities. Open the guide for explanations and worked examples. Written against the Edexcel GCSE Computer Science (1CP2) specification, so the content matches what's examinable rather than general Computer Science background.
Robust software and identifying vulnerabilities
What you'll learn
- What robust software means and why it matters.
- What a vulnerability is, and how it can affect users and organisations.
- How audit trails help identify suspicious behaviour or faults.
- How code reviews help developers find weaknesses before software is released.
The big picture
Good software should not just work when everything goes perfectly. It should cope sensibly with mistakes, unexpected inputs, faults and attempted misuse.
Developing robust software is an ongoing process: design carefully, write code, review it, test it, release it, monitor what happens, then fix weaknesses that are found.
What is robust software?
Definition
Robust software
Robust software is software that continues to work correctly and securely under expected conditions and can handle some unexpected situations without crashing, corrupting data or behaving dangerously.
Robust software is usually:
- Reliable — it works consistently.
- Secure — it helps prevent unauthorised access or misuse.
- Maintainable — it is easier to understand, fix and improve.
- Error-tolerant — it handles invalid input or unusual situations sensibly.
- Protective of data integrity — it helps keep data accurate and consistent.
For example, an online banking app should not crash if a user enters an invalid amount. It should reject the input, show a helpful message and keep the account data unchanged.
Key Idea
Why robustness matters
Robust software reduces the chance of serious failures, security incidents, data loss, financial cost and loss of user trust.
Why developing robust software is important
Developing robust software matters because software is often used for important tasks: payments, school records, medical appointments, transport, communication and security.
If software is not robust, the consequences can be serious:
- Users may lose data if the program crashes or stores values incorrectly.
- Attackers may gain access if security weaknesses are left in the system.
- Organisations may lose money through downtime, fraud or support costs.
- People may stop trusting the system if it behaves unpredictably.
- Fixing faults later can be more expensive than finding them during development.
Example
Explaining the importance of robustness
A school uses software to store student attendance. The program sometimes accepts impossible dates and occasionally crashes when staff search for a student.
- The attendance system stores important records, so incorrect or missing data could affect registers, safeguarding and reports to parents.
- Accepting impossible dates is a data integrity problem because the stored data may no longer be accurate or believable.
- Crashing during searches affects reliability because staff cannot depend on the system when they need it.
- Robust software would validate data, handle errors and avoid corrupting records, so the school can trust the information it stores.
What is a vulnerability?
Definition
Vulnerability
A vulnerability is a weakness in software, system design or configuration that could cause the software to fail or could be exploited by someone.
A vulnerability is not always caused by a “hacker”. It might be a simple weakness such as:
- a login system that allows unlimited password attempts;
- a form that accepts invalid or dangerous input;
- a file that can be accessed by users who should not see it;
- unclear code that causes a programmer to introduce faults later;
- an error message that reveals too much information about the system.
A vulnerability can lead to a security issue, but it can also lead to ordinary software failure, such as crashes or incorrect calculations.
Common Mistake
Vulnerability does not mean attack
A vulnerability is the weakness. An attack is an attempt to take advantage of the weakness. An audit trail or code review may reveal the vulnerability before or after anyone exploits it.
Identifying vulnerabilities
The specification names two key methods you need to understand:
- Audit trails
- Code reviews
They are useful at different points. A code review usually happens while software is being developed. An audit trail is used once software is running, because it records what actually happened.
Method 1: Audit trails
Definition
Audit trail
An audit trail is a record of events and actions in a system, often including who did something, what they did, when they did it and whether it succeeded.
A single recorded event is often called a log entry. A collection of log entries is often called a log.
An audit trail might record:
- user logins and failed login attempts;
- changes to important data;
- files opened, changed or deleted;
- payments or transactions;
- permission changes;
- error messages;
- the date and time of each event;
- the user account or device involved.
How audit trails help identify vulnerabilities
Audit trails help because they show the sequence of events leading up to a problem. This can help developers and security staff spot patterns.
For example, an audit trail may show:
- repeated failed login attempts, suggesting weak protection against guessing passwords;
- a normal user accessing administrator-only data, suggesting a permissions vulnerability;
- crashes after a certain type of input, suggesting missing validation or error handling;
- many password reset requests, suggesting the reset process may be insecure.
Example
Investigating an audit trail
A shop’s customer system records the following events.
| Time | User | Event | Outcome | Source |
|---|---|---|---|---|
| 09:02 | alex | Login | Failed | Laptop A |
| 09:03 | alex | Login | Failed | Laptop A |
| 09:04 | alex | Password reset requested | Email sent | Laptop A |
| 09:06 | alex | Login | Success | Laptop A |
| 09:07 | alex | Changed delivery address | Success | Laptop A |
| 09:08 | alex | Exported customer list | Success | Laptop A |
- The first pattern is that the same account has failed logins followed very quickly by a password reset and successful login.
- The next important event is the export of a customer list, because that is sensitive data and happens soon after the reset.
- This could indicate a vulnerability in the password reset process or account permissions, because access to sensitive data was gained after suspicious activity.
- The organisation should investigate the account, check whether the reset was genuine, and review whether users should be allowed to export customer lists so easily.
Limits of audit trails
Audit trails are very useful, but they do not automatically fix the problem. They provide evidence that humans or monitoring software can investigate.
They also need to be protected. If attackers can edit or delete logs, the audit trail becomes much less useful.
Common Mistake
Do not log sensitive secrets
Audit trails should not store passwords, full card details or other unnecessary sensitive data. Logs should help investigation without creating a new security risk.
Method 2: Code reviews
Definition
Code review
A code review is a systematic inspection of source code by one or more people to find faults, weaknesses or improvements before the software is released or updated.
A code review is usually done by another developer, a team member or sometimes a specialist security reviewer. The key idea is that someone checks the code carefully rather than relying only on the original programmer.
A reviewer might look for:
- logic errors;
- missing checks on input;
- poor error handling;
- hard-coded passwords or secret values;
- unclear variable names or repeated code;
- parts of the program where permissions are not checked;
- code that could crash if data is missing or in the wrong format.
How code reviews help identify vulnerabilities
Code reviews can find vulnerabilities before users are affected. This is important because fixing a weakness during development is usually cheaper and safer than fixing it after release.
Code reviews also improve maintainability. If the code is clear, structured and understandable, future developers are less likely to accidentally introduce new faults.
Example
Reviewing a withdrawal check
A reviewer sees this logic in a cash withdrawal program:
amount = int(input("Withdrawal amount: "))if amount <= account_balance:account_balance = account_balance - amount
- The required rule is that the withdrawal amount should be positive and should not be more than the account balance.
- The code only checks whether
amount <= account_balance, so a negative value such as-50would pass the check. - Subtracting a negative value would increase the account balance, so this is a serious logic vulnerability.
- A better condition would check both parts of the rule: the amount must be greater than 0 AND less than or equal to the account balance.
Common Mistake
Code review is not the same as testing
Testing runs the program with test data. A code review inspects the source code. Both are useful, but the named method in this topic is code review.
Comparing audit trails and code reviews
| Method | When it is used | What it helps find | Main strength |
|---|---|---|---|
| Audit trail | While software is running or after an incident | Suspicious actions, unusual patterns, faults in real use | Shows what actually happened |
| Code review | During development or before release | Faulty logic, insecure design, poor error handling | Finds weaknesses before users are affected |
Tip
Choosing the right method
If the question mentions records of user actions, timestamps or investigating what happened, think audit trail. If it mentions inspecting source code, peer checking or finding faults before release, think code review.
Putting it into exam answers
For this topic, you usually need to explain, not just name. A strong answer links the method to the benefit.
Weak answer:
- “Use an audit trail.”
Stronger answer:
- “Use an audit trail to record user actions such as logins, data changes and failed attempts. This helps identify suspicious patterns and trace what happened before a fault or security incident.”
Weak answer:
- “Do a code review.”
Stronger answer:
- “A code review allows another developer to inspect the source code for logic errors, missing input checks or insecure handling of permissions before the software is released.”
Exam technique
In the exam
- When asked why robust software is important, link your answer to a consequence such as preventing crashes, protecting data, reducing costs or maintaining user trust.
- When asked for methods of identifying vulnerabilities, use the named methods from the specification: audit trails and code reviews.
- Do not just name the method; explain how it helps identify the weakness, such as recording suspicious actions or inspecting source code for faults.
Self review
Check yourself
- What is the difference between a vulnerability and an attack?
- How can an audit trail help investigate a suspicious login?
- Why might a code review find a vulnerability before testing does?
You've reached the end
Test yourself on this topic, or move on to the next guide.
How was this guide?