Difference between revisions of "The Power of 10"
From Lazarus wiki
Jump to navigationJump to searchJwdietrich (talk | contribs) m (Link to Secure programming article) |
Jwdietrich (talk | contribs) (Adding links) |
||
| Line 1: | Line 1: | ||
[[Secure programming|Software security]] is critical for every project. This applies especially to applications in medicine, military, industry and aerospace. This is why the National Aeronautics and Space Administration (NASA) defined a set of rules called '''The Power of 10''' summarising basic principles on how to improve the security of code. | [[Secure programming|Software security]] is critical for every project. This applies especially to applications in medicine, military, industry and aerospace. This is why the National Aeronautics and Space Administration (NASA) defined a set of rules called '''The Power of 10''' summarising basic principles on how to improve the security of code. | ||
| − | The Pascal language implements some basic measures for improved security from the ground up, including strong typing and the encouragement of safe control structures. It is advisable, however, to have some additional principles in mind, especially at the beginning of a new project. Of course, it is possible to implement these principles in later stages, too. | + | The [[Pascal]] language already implements some basic measures for improved security from the ground up, including strong typing and the encouragement of safe control structures. It is advisable, however, to have some additional principles in mind, especially at the beginning of a new project. Of course, it is possible to implement these principles in later stages, too. |
The Power of 10 Rules was defined in 2006 by Gerard J. Holzmann at the JPL|NASA/JPL Laboratory for Reliable Software. Their main intention is eliminating certain C coding practices which make code difficult to review or statically analyze. These rules have been incorporated into the coding standards of multiple institutions. | The Power of 10 Rules was defined in 2006 by Gerard J. Holzmann at the JPL|NASA/JPL Laboratory for Reliable Software. Their main intention is eliminating certain C coding practices which make code difficult to review or statically analyze. These rules have been incorporated into the coding standards of multiple institutions. | ||
| Line 10: | Line 10: | ||
# All loops must have a fixed upper bound in order to prevent runaway code. | # All loops must have a fixed upper bound in order to prevent runaway code. | ||
# Avoid heap memory allocation after initialisation. | # Avoid heap memory allocation after initialisation. | ||
| − | # Restrict procedures, functions and methods to a single printed page. Typically, this means no more than about 60 lines of code per block. | + | # Restrict [[Procedure|procedures]], [[Function|functions]] and [[Method|methods]] to a single printed page. Typically, this means no more than about 60 lines of code per block. |
# Use a minimum of two runtime assertions per function. | # Use a minimum of two runtime assertions per function. | ||
| − | # Restrict the scope of data to the smallest possible. Therefore, local variables should be preferred over global variables | + | # Restrict the scope of data to the smallest possible. Therefore, local [[Variable|variables]] should be preferred over global variables |
| − | # Check the return value of all functions or return nil or NaN in order to indicate that the return value is useless. Additionally, each called function must check the validity of all parameters provided by the caller | + | # Check the return value of all functions or return [[Nil|nil]] or [[NaN]] in order to indicate that the return value is useless. Additionally, each called function must check the validity of all actual parameters provided by the caller. |
| − | # Use compiler or IDE directives sparingly. If possible, they should be restricted to the | + | # Use [[Compiler directive|compiler directives]] or [[IDE directives]] sparingly. If possible, they should be restricted to the [[Interface|interface]] section of a [[Unit|unit]]. |
| − | # Limit the use of pointers to a single dereference and avoid using function pointers. | + | # Limit the use of [[Pointer|pointers]] to a single dereference and avoid using function pointers. |
# Compile with all possible warnings active; all warnings should then be addressed before release of the software. | # Compile with all possible warnings active; all warnings should then be addressed before release of the software. | ||
Revision as of 16:05, 8 April 2020
Software security is critical for every project. This applies especially to applications in medicine, military, industry and aerospace. This is why the National Aeronautics and Space Administration (NASA) defined a set of rules called The Power of 10 summarising basic principles on how to improve the security of code.
The Pascal language already implements some basic measures for improved security from the ground up, including strong typing and the encouragement of safe control structures. It is advisable, however, to have some additional principles in mind, especially at the beginning of a new project. Of course, it is possible to implement these principles in later stages, too.
The Power of 10 Rules was defined in 2006 by Gerard J. Holzmann at the JPL|NASA/JPL Laboratory for Reliable Software. Their main intention is eliminating certain C coding practices which make code difficult to review or statically analyze. These rules have been incorporated into the coding standards of multiple institutions.
Rules
The ten rules are:
- Avoid complex flow constructs, such as goto, direct or indirect recursion.
- All loops must have a fixed upper bound in order to prevent runaway code.
- Avoid heap memory allocation after initialisation.
- Restrict procedures, functions and methods to a single printed page. Typically, this means no more than about 60 lines of code per block.
- Use a minimum of two runtime assertions per function.
- Restrict the scope of data to the smallest possible. Therefore, local variables should be preferred over global variables
- Check the return value of all functions or return nil or NaN in order to indicate that the return value is useless. Additionally, each called function must check the validity of all actual parameters provided by the caller.
- Use compiler directives or IDE directives sparingly. If possible, they should be restricted to the interface section of a unit.
- Limit the use of pointers to a single dereference and avoid using function pointers.
- Compile with all possible warnings active; all warnings should then be addressed before release of the software.
