Conclusion¶

Even in secure software development, there is no need to reinvent the wheel; an essential skill is the ability to make use of solutions that have already been proven secure. One important resource is the open community OWASP [https://owasp.org/], which provides, among other things, a TOP 10 list of the most critical vulnerabilities, easily understandable information about vulnerabilities, guidance on secure programming practices, and detailed instructions for different development environments.

Here is a somewhat broader summary of good practices related to software development, adapted from `the book by Pfleeger <https://www.pearson.com/us/higher-education/program/Pfleeger-Security-in-Computing-5th-Edition/PGM25284.html>`__ and FIPS guidelines.

Good software design and structure are formed by, among other things, the following principles:

consistent error handling: for example, one of the following after first restoring the previous state: retry using a different method — apply some correction and retry in the same way — report the issue and abandon the attempt.
limiting the impact of failures (fault tolerance). This is implemented both within the program (e.g. runtime handling of error situations) and externally (restrictions on what the program is allowed to do).
applying proven practices (ranging from general principles such as modularity to small practices such as specifying the intended range of a variable at declaration or avoiding floating-point equality comparisons)
- modularity, characteristics of program components:
  - a single task, also documented in the code
  - small size, understandable by humans
  - simplicity, for example using only these as programming constructs: sequence, if-then-else, case, and structured loops
  - independence, separation from most other tasks: loose coupling between modules
  - encapsulation, in particular a single entry point and at most two exit points (normal and error case)
  - local variables and communication via parameters and return values, whose validity is checked by the receiver where possible
hierarchy: larger modules are built from several smaller modules, which likewise implement the properties listed above. This is also reflected in the layered structure of communication and service provision, which is typical in operating systems and communication protocols. It does not mean deep nesting of control structures.