How to bootstrap your SDLC with verification activities

If you are planning on adding an application security verification activity to your SDLC using the OWASP Application Security Verification Standard (ASVS), you will need to do some planning. You will need to work closely with both project managers and developers. It is not enough, although it is a necessary prerequisite, to have buy-in from application owners.

The first step is to clearly set expectations with both project managers and with developers. It is strongly advised to meet for a full day or two with project managers and developers after the decision has been made by application owners that application security verification activities will be added to your SDLC. You should:

• Present an overview of the process (generic information about dynamic and code reviews, generic info about architecture review, generic information about adding verification activities into SDLC),
• Collect inputs (code and available documentation), perform an initial high-level design review, determine a verification strategy, and
• Produce an “initial application review” document.

This initial application review document will contain collected information, information about techniques that you will use, and information about how verifications can be inserted into their SDLC. This document will also contain warnings about revised cost estimates based on unexpected complexity and additional caveats.

The next step is to create a “verification target” document (or a comparable document) and project schedule. Take comments received on initial application review document and turn that document into a verification target document, and create a project schedule at this point as well. An addendum should also be generated for the proposal if the initial cost estimates change based on information collected up to this point.

The next step is to perform the initial verification. Perform dynamic and static analysis using tools, and go a little deeper in reviewing the design information. Although, perhaps punt on further design review for this go-round if available hours are short. Write up your results as you perform the different reviews. Make sure not just to write up problems, but also at least identify parts of code that were reviewed that were not found to have problems. Note, keep verification reports separate than the verification target document.

The next step is to communicate your findings and proposed ways to fix or otherwise mitigate your findings. It is strongly advised to meet for a full day or two with project managers and developers to:

• Present all findings,
• Answer any questions, and to
• Identify findings which they do not plan to remediate.

Make sure to write down rationale for why they are going to assume the risk for those they do not plan to remediate. Update the verification target document with this information. Update verification report with any corrections based on presentation of findings.

Also as part of this findings meeting, work with project managers and developers to identify frequency and depth of future verifications as part of their SDLC. Update the verification report with this information. Create a proposal for future work based on proposed SDLC that has been bootstrapped with verification activities.

Helpful hints:

• Keep project managers and developers in the loop over the entire course of the above activities by providing weekly status reports to them. A simple email that lists accomplishments, plans for next week, issues, and any updates to project schedules will help project managers and developers manage their time and resources, and will help build trust.