Code Review - Building Secure Software - Lecture Slides, Slides of Software Engineering

Download Code Review - Building Secure Software - Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Code Review

Application of Touchpoints

Requirement and Use cases

Architecture and Design Test Plans^ Code^

Tests and Test Results

Feedback from the Field

5. Abuse cases 6. Security Requirements 2. Risk Analysis

External Review

4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

Software Bugs

• Programming bugs:
  • Compiler catches error, developer corrects bug, continue development
• Security relevant bug:
  • May be dormant for years
  • Potentially higher cost than programming error
• Who should be responsible for security bug?
  • Software developer?
  • Security expert?

Manual vs. Automated Code Review

• Manual Code Review
  • Tedious, error prone, exhausting
  • Need expert with the mindset of an attacker!
• Static analysis tools
  • Identify many common coding problems
  • Faster than manual
  • Need developer with basic understanding of

security problems and how to fix detected ones

Best Practices Recommendations 1.

1. Review fewer that 200-400 lines

 Optimizes number of detected vulnerabilities (70-90 %)

2. Aim for an inspection rate of less than 300-500 line of

code/hour  Faster is not better!  Based on number of detected vulnerabilities

3. Do not spend more than 60-90 mins on review at a time

 Efficiency drops after about an hour of intense work

4. Make developers annotate their code

 Encourage developers to “double-check” their work  Reduce the number of vulnerabilities in the code

Best Practices Recommendations 2.

5. Establish quantifiable goals for code review

 External metrics: e.g., reduced # of support calls  Internal metrics: e.g., defect rate

6. Maintain checklist

 Prevent omissions of important security components

7. Verify that defects are actually fixed

 Need good collaborative review of software

8. Managers must support code review

 Support team building and acceptance of process

Source Code vs. Binary Code Check

• What to check? Source Code or Binary Code?
• Source Code:
  • See the logic, control, and data flow
  • See explicit code lines
  • Fixes can be carried out on the source code
• Compiled Code:
  • May need reverse engineering (disassemble, decompile)
  • Finding a few vulnerabilities is easy. Finding all is difficult
  • Fixes may be incorporated as binary modules or external filters

How Static Analysis Works?

• Look for fixed set of patterns or rules
  • Syntactic matches
  • Lexical analysis
  • Flow analysis (control flow, call chains, data flow)
• False negatives
• False positives
• Sound tool: given a set of assumptions, the static

analysis tool does not produce false negatives

• Commercial tools: unsound

Rule Coverage

• Taxonomy of coding errors:

• Language specific (e.g., C/C++, Java, etc.)
• Functions or APIs

• Academia vs. industry

Commercial Tools

• Easy to use – still need expert knowledge

• Can process large code (millions of lines)

efficiently

• Need competence of reviewer of results

• Encapsulates knowledge (known

vulnerabilities) and efficient flow analysis

• Encourages efficient and secure coding

Next Class

• Architectural Risk Analysis – Chapter 5