Creating a Secure Development Culture:
The How (Part II)

By Dale Bingham and Dave Gould

Last week, we talked about the critical need for a secure development culture.  With the rise in cyber security attacks and the dollar amounts attached to them, we have to change how we view software development and incorporate security from Day 0 (pun intended).  So how can we specifically do this as software developers, as program managers, as testers, and as support staff? There are a few things we can start right now-today-to quickly get moving in the right direction.

First, we recognize the problem (read Part I again, if you need to). Done. Next, we start implementing a few key steps to get all of us on the path to a more secure software development process. This is important:  we must allow time for security to become a part of everything we do. We must build into our scope/time/cost the impact of securely developing our software and/or systems. That time adjustment must go into schedules, into proposals, into costing, into return on investment, and not just in tangible ways. We must sell the idea that secure software development is the ONLY way to do software development. Period!

Here are a few things you can implement today to get started:

  • Have all developers read the OWASP Top Ten, understand them, and share ideas across all levels of development to guard against them. We need to develop with security against these top 10 items so we can better protect those who use the software we develop.
  • Have quality assurance/quality control test against these OWASP Top Ten issues before allowing software to pass on to the next gate and get into production. These top 10 have not changed much in 7+ years, because we have not gotten them right yet!
  • Perform active and passive scanning of code and applications to automate finding problems and fix them. Active means while it is running, and passive means scanning your software development code itself (*.js, *.cs, *.java, *.pl, etc.).
  • For those in the Agile realm: Have user stories in your sprint such as “as a hacker I want to …. In order to …” and have that tested by developers.
  • Include HTTP Headers for added security. If you do not know what those are please follow the link to OWASP and read the information.
  • Ensure your quality assurance/testing groups are testing for correct functionality as well as “negative testing” to ensure bad things will not happen if the software is used incorrectly. This includes the OWASP items mentioned above, however, it also goes toward fuzz testing, input validation, maximum length in input fields, etc.
  • Ensure security, privacy, safety, and functionality are discussed and designed in from the get go on any new project, any update, any rewrite, and any bug fix for applications.
  • Involve your Configuration Management Board (CCB) and the Configuration Management (CM) process in the secure development process so everyone is involved in securing your application correctly and that those decisions are communicated to all of your team members.

sdlcFigure 1 SDLC with Security Mindset

This is just a start, however, it will put you and your team on the path to think about security in all you do. You should now know what you didn’t know before, as far as a secure development process goes. Next, we need you to get to the point where security is just a matter of habit. It should be instinctual. That is our nirvana! Figure 1 shows security involved all around the software development life cycle, whether you are using Agile or Waterfall or something in between. Security needs to always be there in the right capacity as it pertains to your users, safety, privacy, regulations, legality, and functionality.

Creating a secure culture at your organization or business involves more than just secure software development. We get that. This is not meant to be a catch-all for creating a secure company mindset. That is a much larger conversation involving processes and procedures, training, and showing the cost benefit to senior management.  However, this IS a start to creating a secure development culture. And we are pushing hard to get there.

Once again, we invite you to join us!


The authors, Dale Bingham and Dave Gould, are co-owners of Satismo, a Global Cyber Alliance partner. You can follow them on Twitter @Dale_Bingham, @degthat, and @SatismoSecure.

Editor’s Note: The views expressed by the authors are not necessarily those of the Global Cyber Alliance.