Build, Coding Standards, Code Review

Writing it right

This article covers the controls that apply during the build phase. Together they answer one question: is what’s running in production exactly what was written, reviewed and approved?

Coding standards

Coding standards set out how code is written: naming, structure, comments, error handling, logging, approved libraries and banned functions. They:

• make code consistent and easier to maintain
• help reviewers spot problems
• reduce the dependency on the original developer (someone else can pick it up)

Comments and documentation are part of maintainability, not optional extras.

Secure coding

Secure coding guidelines (often based on the OWASP Top 10) prevent the most common attacks:

• validate all input and use parameterised queries to prevent SQL injection
• encode output to prevent cross-site scripting
• handle login and sessions securely
• don’t show detailed errors to users
• keep secrets out of code; use a vault
• use vetted libraries and keep them patched

Version control

All source code lives in a version control system that records who changed what, when and why. Protected main branches and tagged releases mean production code can always be traced back to one specific, approved version.

Code review

Review by someone other than the author finds:

• logic errors and bugs
• security vulnerabilities
• departures from standards
• unauthorised or malicious code: back doors, logic bombs, hidden transactions

Automated static analysis helps, but it doesn’t understand business logic, so it doesn’t replace human review. And the author reviewing their own code doesn’t count.

Example. A peer review of a payroll change finds a condition that adds a small bonus to one employee ID whenever a particular flag is set. The author can’t explain which requirement it meets. The review stops a fraud that testing might never have triggered.

Protecting source code

• Restrict who can read and change source code.
• Developers have no write access to production libraries.
• Production executables must match an approved source version (checked by comparing code).
• Changes to source go through change management.

Unit testing

Developers test each module on its own to confirm it works as designed, before it’s combined with others. Automated unit tests in the CI pipeline make this repeatable on every change.

How the exam asks about it

In short

• Coding standards make code consistent, readable and maintainable, and reduce errors.
• Secure coding practices address common vulnerabilities such as injection, broken authentication and insecure data handling.
• Code review by someone other than the author finds defects and malicious or unauthorised code.
• Version control tracks every change to source code: who, what, when and why.
• Access to source code should be restricted; production source and executables must match.
• Unit testing by developers verifies each module before integration.

Exam traps

• Self-review by the author isn't an independent code review.
• Automated scanners help but don't replace human review of logic.
• Developers should not have write access to production libraries.
• Comments and documentation are part of maintainability, not optional extras.
• Hard-coded passwords and back doors are classic code review findings.

Slides

Click the slide and use the arrow keys. F toggles full screen.