Security and Development: Building A Better Relationship

Let's build a better relationship between security assessors and software developers.  Instead, of having security teams act like an external, neutral audit group that simply finds problems and reports them, let's make security assessors problem solvers, advocates, and advisors!

Typically, assessors identify security defects, and then reports issues to the application development team.  Defects may be accompanied by a best practice approach or description for remediating each vulnerability, but that advice often isn't customized for the relevant framework, language, or libraries being used in the software package.  Assessments typically occur after specific milestones like a release or after an elapsed time period.  I want to shake up these patterns!

First, let's assign a relationship, development team, and set of applications to each assessor within the security group.  This assessor will partner with software developers and really get to know the application over time through repeated interaction and review.  Next, let's give the assessors read only access to the source code repositories for each application they are assessing.  Now, instead of providing security services (assessments, code reviews, architecture reviews, design reviews, etc.) once an application reaches a specific milestone, let's make the assessor responsible for guiding the team on a continuous basis.  The assessor attends important meetings, gets to know the project goals, identifies and executes on security needs continuously, provides training, advice, and gets out in front of potential privacy, compliance, and security concerns while the application is still being designed and architected.

The organization as a whole should have specific security tools and activities that are required for all applications (may be a tiered approach based on an application's risk profile and valuation) identified in advance and the security assessor is responsible for setting up, configuring and running these tools and activities (often with cooperation of the development team).  Let's assume that the organization uses a static code analysis tool to identify security defects in a software package.  The tool is installed on a continuous integration server (automatically monitors code repositories, checks out, builds, and then assesses code for quality and security) and as new defects are found, the security assessor is notified.  The security assessor is then responsible for reviewing and validating the findings (alternatively, a filter could be set up to notify developers of security issues already mastered and the assessor could receive only new issues).  Once a finding is validated, the assessor develops an example code patch that would remediate the vulnerability.  He or she then brings that solution to the software team, and provides a mini training session with the whole team covering: information about the vulnerability, the specific best practice used to remediate it, and then the code proposed to fix the issue.  The team (security and development) discusses the cause, effect, and fix, and then the team as a whole agrees upon an appropriate secure coding standard for that vulnerability class (based on the code example above).  Finally, the development team applies that standard for all instances of the issue in the application and uses it for developing similar code in the future.

This approach allows teams to identify and fix security defects quickly, it allows developers to focus on developing code rather than understanding security tools, and creates a relationship in which the security team brings solutions to the table rather than problems.

Taking it further: If the organization has a formalized secure software development process and a central repository for application security requirements, then the knowledge should be captured within this repository in the form of application security requirements and secure coding standards.  These added requirements and secure coding standards should be evangelized to other software development teams to help them avoid similar vulnerabilities.

Related:
Turn Application Assessment Reports into Training Classes
Security Testing Roles - Expanding on Integrating Security Testing into the QA Process