Salient Points for Consideration and Inclusion in a Software Security Checklist (SSC)
1. Introduce a walkthrough, security audit review or a formal security review in every phase of the software life cycle development.
2. Establish security metrics during the software life cycle and a trace matrix for security requirements.
3. Determine stakeholders, and elicit and specify associated security requirements for each stakeholder
4. Determine context and potential usage of software product along with the operating environment and specify requisite security requirements.
5. Make available to programmers, developers, reviewers and test teams the vulnerabilities and potential exposures associated with programming languages and operating systems before the architectural design phase.
6. Set up security parameters for access to services such as ftp service where anonymous ftp is allowed but with write-only and no read or list to the incoming directory and read-only for outgoing directory
7. Check for sources of software security risks such as inconsistencies in requirements and in design, reusable programs, and other shrink-wrap software. Use of requirements tools, modeling tools, etc. can aid in this area.
8. For security in software development, avoid the use of unsafe routines such as sprintf(), strcpy/cat(), gets and fgets in coding.
9. Check the security of any middleware in the program.
10. Check for architectural-specific vulnerabilities and how data flows through the code.
11. Check for implementation-specific vulnerabilities such as Race Conditions, randomness problems and buffer overflows.
12. DO NOT allow programmer backdoors or unauthorized access paths that bypass security mechanisms. This needs to be enforced for security in software development.
13. Avoid storing secrets like passwords in the code or use weak encryption schemes
14. Identify all points in the source code where the program takes input from users.
15. For application security, identify all points in the source code where the program takes input from another program or untrusted source.
16. Investigate all sources from which input can enter the program such as GUI, network reads, etc. Check API (Application Program Interfaces) calls to security modules or interfaces.
17. Investigate secure connections. Verify that they actually are secure and connect as indicated to the systems to which they are intended to connect.
18. Investigate software built-in extensibility features to enhance application security as per application security checklist.
19. Review software complexity and look for alternatives to reduce complexity.
20. Investigate the security of the data when passed from application servers to databases.
21. Avoid default or other improper configurations that may open the door to attackers.
22. Default to “highest security” needed, and require validation and approval for deviations.
23. Establish tools to be used for various stages of the life cycle that will be used for assessing security.
24. Perform security testing for unit and system integration.
25. Potentially, establish a security risk rating criteria and document the rating of the software product within the organization. Using a risk assessment tool can benefit this area.
Please note that physical and environment security (Admin) , Human resource Security and IT Security is not part of Software security Audit, since these dedicated departments have as such a huge set of controls to address.