...
Collect the requirements that pertain to your change. Are they formal or informal? Do you have security requirements? (protip: you do have security requirements)
Identify the appropriate stakeholders and SMEs before starting development. Look at who created the Jira issue, who has commented on it and who is watching it. These are likely the stakeholders. As you familiarize yourself with the task, see what part of the code base you will be touching, and identify who originally wrote the code, who frequently changes it, and who touched it the most. Also, if applicable, identify the component team lead. These players are likely your Subject Matter Experts (SMEs).
- Involve the relevant players early in design. Avoid surprising SMEs and stakeholders when you submit your code. Make sure you are doing what the stakeholders want, and the make sure the SMEs buy into your implementation. Whenever relevant, have whiteboard sessions with architects. Make mockups of UIs (myBalsamiq) before development. Having buy-in early avoids major rewrites when going into a code review.
- Analyze the security and privacy risks associated with your requirements.
- Generate a threat model and analyze the attack surface. This step is easiest to do in a group. If you're remote, consider Consider using something like Google Groups to share things remotelysince we have a distributed project team. This is a great place to start involving the SMEs that you noted in step 2.
- Make sure the tasks are appropriately broken down into user stories. Ensuring a successful and low-pain peer review starts in grooming sessions. In some cases, it could be worthwhile to recommend breaking a ticket up to extract the design from the implementation. For example, for a UI ticket, the mock-up be its own ticket and would get its own peer review.
- Capture Artifacts and post them to your Jira Issue. Create an audit trail for any design decisions. Photos of whiteboards, a summary of in-person discussions, and links to relevant research, mock-ups, etc, should be added to the Jira Issue. Having this available is a resource to explain why you did what you did, and helps hold people accountable for how they influenced your decision. This makes it a lot easier to go back and understand the reasoning behind how things were done when reviewing.
- Expose your development and get early feedback. In cases where you desire direction while in development, commit your work-in-progress and push it to your remote fork. Add the link that commit to your Jira ticket and get your target audience to check it out by tagging them or contacting them directly. They should be able to add comments to your commit within your fork, effectively treating it like a “pre-review” (view).
- Verify that your code follows the security best practices:
- Are you validating all of your input?
- Are you adhering to the principle of least privilege?
- Are you sanitizing any data sent to other systems or sub-systems?
- Are any security policies that you're using set to deny by default? (whitelist as opposed to blacklist)
- Are you the only person that will be able to maintain this code? If so, consider refactoring or simplifying things.
- Glance at git history and include people who made the last commit in areas you are now changing. This allows you to get more context and history as to why the existing implementation was done a particular way. It also gives the previous author a chance to point out any concerns.
- Develop in the correct environment. Set up your development environment with the recommended for the current project. For example, develop against the recommended java version. Also, use the correct formatter. Often committed code has many changes that are non-functional, and show up because different developers are using different formatters. All development should be done using the formatter specified for that project. Ideally, the file already conforms to that format. Reviewing code with formatting changes mixed in amongst functional changes is a challenge, as it takes additional time to identify what modifications are relevant.
- Verify that your threat models are correct and that you correctly identified the attack surface associated with the change. Try to tell a story using your implementation and verify that the model is correct.
- If this is a new web application or endpoint, fuzz testing should be performed to verify that there are no new vulnerabilities. Consider using testing frameworks such as: https://github.com/zaproxy/zaproxy/wiki/Downloads or http://w3af.org/download
...