This Security Checklist from the team at SafeStack.io was created to improve security culture in dev teams and help them consistently check their code for common security risks.
The earlier that vulnerabilities are discovered, the cheaper and easier they are to fix. The tool is intended for use as part of a software team’s code review process to improve security posture, and the quality of the code they release.
The security checklist has three phases
Have all secrets been removed from the committed code?
Have unresolved risks been raised and documented?
Have the right people been engaged to review the code?
Is the purpose of the change stated and understood by the reviewers?
Is there debug functionality in the code?
Is user-supplied data:
Do log entries:
For frameworks, libraries, tools and other dependencies:
Do response messages:
See the Code Review Security Checklist Implementation Manual for details.
Improve code review culture by consistently applying secure coding practices.
It is a good starting point for building better security practices in to the software development process. Additions and modifications to fit local practice are encouraged.
It is not comprehensive. It is not intended as a standalone teaching tool, an accountability mechanism, or as a complete guide to secure development.
The security checklist itself can be included as a template in a code review request and the review tools configured to require its completion. It may still be helpful to have physical copies visible around teams’ workstations.
The first phase takes place before the original author shares their code with the team and consists of the author verifying they haven’t included any real passwords, keys, tokens, or other secrets in their code.
The next phase happens during review and each item may be completed by any of the reviewers besides the original author. The reviewers confirm the right people have been tagged in and that they all understand the intended change.
They then check for the presence of debug code, the handling of untrusted data and response information, the correct use of tools, and that there is sufficient log and test coverage.
Finally, if the code review has raised risks beyond the scope of the review to fix, the reviewers raise the risk to their team and ensure it is logged somewhere it will be reviewed. This can also be completed by any of the reviewers.
Teams should modify the checklist to suit their needs. They shouldn’t remove safety steps because they are unable or unwilling to perform them. The entire team should be involved in decisions to modify the checklist, and the modified checklist tested on a single system to ensure it works as intended. Changes should result in a checklist that is focused, brief, actionable, collaborative, tested, and integrated.
Check out these great links which can help you dive a little deeper into running the Security checklist practice with your team, customers or stakeholders.