By Eric Baize, Chairman, SAFECode


Recently, I had the honor of delivering the opening keynote address for the OWASP AppSec California 2018 in Santa Monica.   The audience (600+ attendees) was made up of security practitioners very knowledgeable about secure development. We engaged in very spirited conversations about driving better security by changing the software development culture.


My keynote, Flipping the Script: Fighting Advanced Threats at their Software Roots, challenged the entire software ecosystem to play their part in building more secure software and deliver software security at scale. Scaling software security will require expanding the security conversation beyond developers if we are to “flip the script”.  Learning from the collected real-world experience of SAFECode’s members, I reviewed short term strategies for development organizations and technology users to raise the software security bar. For the longer term, in the second part of this blog, I discuss the drastic changes required in how we educate and equip software developers to permanently change the software culture and deliver software security at scale.


You can see my presentation slides here:

In collaboration with my SAFECode colleagues here are our suggested steps organizations can take to make the culture changes to “flip the script”:


Key Theme: Development Organizations Need to Build Security in their Software Engineering Fabric


Changing the culture of development organizations starts with considering that security is one attribute of the software engineering discipline.


Govern Software Security like Quality

  • We often think of security testing as an expert activity performed by third parties. We under-estimate the appetite and abilities of Quality Assurance (QA) engineers to engage in security testing. Quality assurance organizations need to treat vulnerabilities like a bug to make security part of the quality conversation.  It’s important that we teach security testing to QA engineers and make security testing part of the software testing plan.  The goal is to have critical security vulnerabilities recorded as Severity 1 bugs in the defect tracking system and escalated accordingly.  This simple step to expand the definition of bug severity in your organization will force all to make security part of the quality conversation.


Make All Organizations Employees Security-Savvy

  • For better security proficiency, development organizations should establish a multi-year plan to drive expertise and empowerment across all engineering functions and focus software security teams on enabling developers while minimizing impact.


Key Theme: Technology Users Need to Raise Market Security Expectations


Make Security a Buying Criteria

  • Functionality and cost seem to trump security in purchasing decisions. Including security in the buying discussion is good risk management practice for organizations. It also greatly influences the market and helps suppliers prioritize security.  Suppliers should be able to discuss and document their secure development process and software security governance, standards such as ISO 277034 are emerging to facilitate this conversation.


Key Theme: Make Security More Pervasive for Developers


Teach Security to Software Engineers

  • You cannot get a building engineering degree without understanding fire safety, you cannot graduate from culinary school without understanding food safety, yet we can earn a software engineering degree without taking a single secure development course. Universities and boot camps must make software security a mandatory component of any software engineering curriculum. It can’t be all “on the job” training.  A basic level of knowledge needs to be taught.  How about making security a mandatory requirement to graduate for developers and project and program managers?


Design Software Security in Application Lifecycle Management Tools and in Programming Environments


  • Developers love tools and use tools extensively. Not security tools, but application lifecycle management tools such as IDEs which manage code throughout the development lifecycle. Tool vendors have an opportunity to make a significant contribution to better security by designing software security directly into application lifecycle management tools. This would help make security a feature of integrated development environments.  Down the road, vendors also have the opportunity to create innovative, smarter security tools by leveraging artificial intelligence and machine learning.


  • Research labs have a role to play by leading the way toward more innovation in computer science. A good first step would be to invent developer-friendly programming languages and run-time environments optimized for security.  We need a broad set of secure languages and framework to cover the majority of use cases.


The goal of these recommendations is not to dictate the final truth.  Instead, they are to be used as a starting point to create discussion and, hopefully, a change in how the industry builds more secure software and delivers it at scale.  I welcome your thoughts and ideas