Good Security Practices for Programming

This is the one of a series of posts on "Good Data Processing Security Practices."  The context for the series can be found here.  The following practices and controls are for programming, the processes, including management, by which programs are produced. 


Procedures should exist for enforcing adherence to rules. standards and
conventions (see Good Practice for Programs). Such procedures should be
sufficiently rigorous to make variances and anomalies obvious to management.

Procedures should exist for enforcing separation of duties and involvement
of multiple people (see Good Practice for Programmers).

Procedures should exist for requiring and recording the approval and
authorization of user and development management. These may be forms
or other procedures external to the system. or transactions or procedures
internal to it which can be invoked only by the designated managers.

Procedures should exist for maintaining the integrity of module and version
names. (see good practice for program libraries).

Procedures should exist for maintaining a record of the creation and
modification of all programs, The record should contain the content of the
change and references to the programmers. the date and time and the
process used.

Procedures should exist for reconciling the program to the specification.
These should include tests. independent review,s and structured walk-throughs.

Procedures should exist for maintaining a record of the results of all test.
review, and walk-through results.

Procedures should exist for requiring and recording the acceptance of user
management.

Procedures should exist for reconciling resource consumed (e.g., programmer
time. computer time) with expectation.


These procedures can effectively be built into the forms. editors. compilers.
library managers. and test drivers and other tools used by programmers, librarians. and
management.