SP. Secure Programming

What “secure” means here

When people hear security, they think of hackers. That is part of it. But most security problems start with ordinary mistakes: a program trusts a value it should have checked, hides an error it should have reported, or forgets a case it should have handled. Those mistakes corrupt data, crash programs, and expose private information whether or not anyone is attacking.

A secure program keeps doing the right thing when conditions are bad. The input is mistyped. The file is missing. The number is negative. Someone is deliberately feeding it garbage. In every case, the program either handles the situation or fails clearly and safely.

The habits in this lab come from the NSA’s secure programming principles. They apply to any program, including the small command-line application your team is building.

The principles

1. Validate your input. Check every value that enters your program before you use it.
2. Handle exceptions at the lowest sensible level. Catch errors where you can fix them; let the rest propagate.
3. Avoid information leakage through error messages. Tell the user what went wrong without revealing how your program works inside.
4. Cover all cases. Every if chain and match statement needs a path for input you did not expect.
5. Heed static analysis warnings. Your tools can find many of these problems before you run the code.

Each page uses the same small example: a command-line inventory tracker that lets a user add items, remove items, list what is in stock, and save to a file. It is close to what your team project does, so the fixes should look familiar.

How this lab connects to the course

The Information Literacy assignment asks you to research one of these principles and decide whether it applies to your team’s project. These pages are the starting point for that research.