Image
(Sales employee): “Developers are not thinking about secure software development.” (Engineer): “Secure software development is hard and lots of us think about it. Software engineers need to think about, plan around, and advocate putting it into software, but are usually limited by the time and money the company is willing to invest.”As I watched the conversation from the sideline, I decided both perspectives deserved to be addressed. There never is enough time or money available to get everything we desire into products. Most engineers feel the pressure to complete the next sprint with product enhancements, often pushing secure software development “below the line.” However, I believe that, while developers are planning for secure software development, they aren’t putting it in front of senior leadership clearly enough to say, “we shouldn’t do this without addressing these security measures," and get their attention. Conversely, senior leadership needs to be asking the question, “what security gaps exist in our product and how do we proactively address them, so we don’t have to deal with redress after the fact?” I think there are three things we can do to alleviate this disconnect.
1. The conversation with executives has to be comprehensive.
There is a myriad of conversation around protecting internal assets and data; however, if a company is a product manufacturer, the conversation with your executives needs to include a plan for secure product development and what the implications of vulnerability in your product will mean for mitigation, brand and revenue. Development teams are responsible for raising the visibility of threats in product development. With revenue impacts being impacted anywhere from 22-38 percent (Ponemon Institute, Reputation Impact of a Data Breach [PDF]), it is a highly motivating business case to spend the extra time in securing the product.2. Implement or enhance your organization’s use of the Secure Software Development LifeCycle (SSDLC).
This framework can help incorporate security into each step of your development cycles, ensuring that requirements, design, coding, testing and deployment have security considerations represented and actioned. Further, it can improve communication by providing a standardized language and terms for all of your business stakeholders.3. Increase security posture with employees and vendors.
Through training and communication (bi-directionally across the organization) with employees, from tacticians to leadership, any company can begin to change the culture to be inclusive of security. It is imperative that everyone be security minded each day. Enacting or enforcing governance with third party vendors, especially if they do development work on your product, will help show your company commitment to being accountable to your data. An external consideration is that the industry needs to decrease its acceptance of “first to market” to the detriment of security mentality. Until consumers commit to requiring a minimal amount of security in new products, this will be a perpetual cycle of vulnerability due to minimized investment in secure development. As consumers, security professionals, and developers, we will continue to struggle with the perpetual tension between security and cost. I posit the market needs to define and leverage a “grading system” for product security. Communication is paramount and the whole of a company is responsible for it; leadership and individual contributors need to drive and influence the context for your specific business needs. Having a conversation from top to bottom about a company’s willingness to invest in secure development principles will guide every employee to the security minded framework. While the upfront cost may seem large, research shows that the cost of fixing security flaws and bugs once a product has shipped is a magnitude higher than if done early in development.Image
