Software Integrity

 

Squash more bugs with this code review checklist

“All software projects are guaranteed to have one artifact in common—source code. Because of this guarantee, it makes sense to center a software assurance activity around code itself.”

-Gary McGraw, Software Security: Building Security In

Conducting secure code reviews during the software development life cycle (SDLC) helps reduce security bugs in code. The following six steps identify where reviews can and should occur to reduce the cost and time to remediate bugs later in the life cycle.

1. Get proactive about security during the design process.

  • Establish security standards early. Define coding standards around security. Include elements like data validation, database queries, and output encoding.
  • Identify a security lead for all projects. Make sure your development teams have a security expert available to answer questions. They might be somebody from the software security group or a developer on the team who has taken a special interest in security. This lead should participate in all security code reviews and should help with change management.
  • Include security at the whiteboard. Discuss feature design during whiteboard sessions with your team and others involved in the design process. Focus on security early so you don’t have to fix things later.

 2. Review code as you create it.

  • Maintain secure coding standards. Review the code to ensure it follows established standards.
  • SAST as you type using a lightweight tool to check code while developers work. Simple tools with tailored, reliable rule-sets help developers as they write code. These tools often prevent a variety of problems up front.
  • Conduct peer reviews. Review code for security problems with your team and security lead.

3. Include change management in the SDLC.

  • Review change requests. Proposed changes may have security impacts. Evaluate the security impacts of all change requests as they’re reviewed and approved.
  • Communicate security impacts to developers. Communicate security concerns and proposed changes to developers so they can address them. Help them address the concerns if necessary.

4. Check-in code after remediating security bugs.

  • Review code before check-in. Conduct formal reviews or peer reviews and include security before committing the code.
  • Perform a SAST scan of the code before check-in and resolve outstanding issues. Use a tool other than the SAST as you type tool. It should include reliable rule-sets that won’t waste developers’ time with false positives.
  • Integrate SAST into the check-in process to aid the security expert evaluating the changes. While SAST as you type helps developers immediately, the need to reduce false positives means that many things may be missed. Build detailed SAST scans into the check-in process and have security experts triage the results.

5. Audit the entire integrated code base.

  • Review entire code base periodically for security issues. Small changes over time can combine to impact the software’s security stance.
  • Run SAST against the entire code base. Ensure that accumulated changes don’t have a security impact.
  • Set a release gateway that includes secure code reviews. Don’t release code that hasn’t been reviewed.

6. Utilize the lessons learned.

  • Adjust coding standards based on review findings. Use code review findings to improve the established secure coding standards.
  • Share code review results with all developers. Code review exposes a variety of code mistakes which can be shared to help others avoid similar mistakes in the future.
  • Plan training. Evaluate the trends over time and conduct training sessions around these recurring issues.

Secure code review is an important part of injecting security into the SDLC. It helps identify security bugs before they’re ever released into the wild. The more often the code is reviewed for security issues, the better the chance of finding bugs before they become real problems for you, your organization, and customer base.