6 Key Considerations You Need To Know About Secure Development Processes

Many organizations are revisiting their Secure Development Process.  This review is being driven by a number of factors including annual review cycles, new concerns over updated compliance requirements, and the advent of new technologies.  Because there is a great deal of latitude in how an organization chooses to implement their secure software development process, it can be challenging to know if all of the critical components are in place.  At a high-level, the following are some of the key components that I look for when evaluating a secure software development process.


  1. Define Development Requirements: Requirements documents define in positive terms what security requirements software products must be able to meet.  They also provide high-level pseudo-code that a developer can use as a guide to implement the requirement in a given programming language.  In this way, the requirements can remain relatively stable over time.  Associating each of these with key compliance requirements not only educates the reader as to why the Development Requirement is important to the enterprise, but also helps demonstrate compliance to external auditors.
  2. Define, Refine, and Reuse: Once your code requirements are in place, begin working with your developers to define known-good code modules which address the Secure Development Requirements.  Implement each of the requirements in the major languages your organization uses for application development.  Integrate validation checking to ensure these known-good methods are used during peer-review and QA activities.  Over time, refine these elements and reuse them as new projects arise or new platforms or languages are introduced.  If a project cannot leverage one of these standard approaches, it must be documented as an exception and closely evaluated.
  3. Self Service Tools: Many organizations do not have dedicated, knowledgeable, internal application security experts.  For those organizations which do have such people on staff, it is safe to say that these individuals are far outnumbered by the number of applications, developers, and projects they are being asked to support.  To keep pace with business, the developers and QA teams must be provided the capability to run automated security tools and resolve findings prior to seeking deployment approval.  Consider providing developers with one tool (or set of tools) to look for problems at the code level, and a different tool(s) to the QA folks who are performing testing in pre-production environments.  That way, each team can become proficient with tools targeted at the layer of the application they are most closely working with and the organization benefits from a multi-faceted internal security approach.  It is important to note, however, that these tools are intended to work in conjunction with security staff, which performs final pre-deployment and on-going security assessments.
  4. Experts On Demand: Questions and challenges are bound to arise.  Make sure that there are experts available so the developers and QA teams can escalate technical questions.  Whether these regard use of assessment tools or the nature and significance of specific findings or recommendations, application security experts should be available to help resolve issues, provide guidance, and educate through question and answer sessions.
  5. Cross-Functional Risk Review: Most projects will find that they have at least one feature, function or requirement that comes into conflict with the secure development requirements.  They can’t leverage established development solutions, or otherwise fail to demonstrate adherence to best practices.  This can occur for a number of legitimate reasons.  However, it should not be the development team who determines if a risk is acceptable to the line-of-business or the enterprise.  For that reason, a review panel consisting of representatives from the lines-of-business, information security, and executive ranks should review the exceptions and make a final determination.  Depending on your organization, other groups may require representation as well such as back-office functions like HR, Legal, Finance or Risk Management.
  6. Bringing It Together: While each of these are critical components in the secure development process, they are intended to work in conjunction with, and compliment, each other.  That can only happen if the technical parts of the process are linked to the procedural and governance aspects of the program to create a clear operational picture.  By leveraging collaboration and social media type technologies internally, the organization can create an interactive and tangible infrastructure to support and re-enforce the operational vision.  Even more, it encourages the creation of developer communities and brings the topic of secure software to the forefront of the teams’ awareness.

Implementing a secure software development process is not a one-size-fits-all kind of scenario and there are many ways to implement the concepts above.   See if your development process includes these concepts and if it doesn’t, start the conversation.  A little tailoring can go a long way to improving the way your secure development process fits your organization.

What are your thoughts.  Which of these steps do you find the most important?  Are there any steps you’d add to this list?  Are there any you would omit?  We look forward to your thoughts on this important topic of implementing a secure software development.
Mike Klepper Consulting Application Security Practice Director AT&T About Mike