This document discusses rolling out an enterprise source code review program. It begins by providing background on the author and his company, Denim Group. It then discusses common mistakes organizations make in implementing source code reviews. The rest of the document addresses technology concerns, such as what languages and architectures are supported by review tools, as well as people and process concerns like who will run the tools, when scans will be run, how results will be interpreted and prioritized, and how findings will be addressed. It emphasizes that source code review programs require both technical and human elements to be effective at improving software security.

1. Rolling Out an Enterprise
Source Code Review Program
Dan Cornell

2. Agenda
• Background
• How Not To Do It
• Technology Concerns
• People and Process Concerns
• Questions
1

3. Background
• Denim Group
– Develop Secure Software
• Ground Up Development
• Software Security Remediation
– Help Organizations Deal with Software Risk
• Code Review and Application Assessments
• Application Penetration Testing
• Training – Instructor-Led and ThreadStrong eLearning
• Security in the SDLC
• Dan Cornell
– Principal at Denim Group
– Developer by background: Java 2 Certified Programmer, MCSD
– OWASP: Chapter Lead, Global Membership Committee, Open Review Project
2

4. How Not To Do It
• Q: What are you all doing to address application security concerns in
your organization?
• A: We b
A W bought “XYZ Scanner”
ht S ”
• Q: Okay… Are you actually using it?
• A: We ran some scans
• Q: And how did that go?
• A: Oh we found some stuff…
• Q: How did you address those issues?
• A: I think we sent the report to the developers. Not sure what they did
with them. I guess I ought to check in on that…
3

5. What Are Your Goals?
• Common Answers
– Meet compliance or regulatory requirements
– Address software risk
• Keep in Mind
– Compliance != Security
– “Checkbox” mentality
Checkbox
– Look for opportunities to leverage compliance budget to increase actual security
4

6. Initial Considerations
• Every organization is different
– Development practices: Agile, waterfall, cowboy-code
– Control environment: Security IT audit compliance
Security, audit,
– Most important: Organizational values. What is important and how do things get
done?
– Not necessarily “Core Values” but certainly related
• You must overcome resistance
5

7. Static Analysis: Advantages and Disadvantages
• Advantages:
– Have access to the actual instructions the software will be executing
• No need to guess or interpret behavior
• Full access to all of the software’s possible behaviors
– Speeds remediation – You know exactly where the vulnerabilities are in the code
• Disadvantages:
g
– Require access to source code or at least binary code
• Typically need access to enough software artifacts to execute a build
– Typically require proficiency running software builds
– Will not fi d i
t find issues related t operational d l
l t d to ti l deployment environments
t i t

8. Dynamic, Static and Manual Testing

9. Components
8

10. Technology
• Majority of the focus tends to be here
– For better or for worse
• What l
Wh t languages require support?
i t?
– Java, .NET, C/C++, PHP, Python, Ruby, Perl, Smalltalk, COBOL, etc
• What application architectures are supported?
– W b web services, thi k li t system software
Web, b i thick-client, t ft
9

11. Where Is All the Code, Anyway?
• Must Know In Order to Define Scope
• How Is Software Developed In Your Organization?
– Centralized development team under IT
– Separate development groups under different lines of business
• Don’t Forget
– ERP d l
deployments often contain custom code th t can h
t ft t i t d that have vulnerabilities
l biliti
– Portal deployments (SharePoint) also often have custom code
10

12. Before You Select Technologies?
• Questions
– Who will run the tool?
– When will it be run?
– What will be done with the results?
• If you haven’t answered these – you aren’t ready to deploy
– It won t be used
won’t
– Nothing will be done with the results
– You may fool your auditors…
– … but you won’t fool attackers
11

13. Who Runs the Scans?
• Common Options
– Security Team
– Development Team
– Quality Assurance Team
– Combination
– Outsourced
• Keep in Mind
– Source code scanning tools are not “fire and forget” so effective users need training
– Need to know how each scan will be used
12

14. When Are Scans Run?
• Common Options
– Developers at their workstations
– Continuous integration
– Integrated into nightly build
– Prior to the end of an iteration or release
• Keep in Mind
– Scans of large applications can take a long time to complete
– Developers may only have a portion of the code on their workstations
– Waiting until late in the process make timely remediation impossible
13

15. Interpreting Results
• Scanning Tools All Return False Positives
– Except during sales engineer demos
• Scans Must Be Manually R i
S M tB M ll Reviewed
d
– Culling false positives can be time-consuming
– Trained analysts can work through this process pretty quickly
14

16. Tuning Scans
• What Rules Are Used?
– Standard rule set
– Subset of the standard rule set (often based on compliance requirements)
• Are Custom Rules Used?
– Organization-wide
– Per-application
15

17. What Gets Fixed?
• Common Options
– Everything (yeah, right)
– Tool based standard (“All HOT and MEDIUM level issues )
Tool-based ( All issues”)
– Negotiated between development and security teams: “Risk Poker”
• Keep in Mind
– Finding the vulnerabilities is only the first step
– Often have to provide guidance to developers on fixing vulnerabilities
16

18. Incremental Progress
• Scanning Programs Evolve Over Time
– Start with proof-of-concept or limited deployment
– Expand from there
• Strategies
– Riskiest applications first
– Compliance mandates first (or only)
– Require for all new applications, incorporate legacy portfolio over time
– Development group by development group
17

19. Other Topics
• Manual Code Reviews
– Critical to catch business logic issues
– Often done by team leads – but do they have specific security guidance
• Integrating Source Code Review With Dynamic Assessments
18

20. Questions / Contact Information
Dan Cornell
dan@denimgroup.com
Twitter: @d i l
T itt @danielcornell
ll
(210) 572-4400
Web:
W b www.denimgroup.com
d i
Blog: denimgroup.typepad.com
19