Assessing Software Security: Join the V.2.0 Conversation

Posted on

Today’s post is authored by Prof.  Howard A. Schmidt, SAFECode Executive Director

Consensus is not easily reached within the information security community. Sure, after spending some time on Twitter it may appear that we all just enjoy a good debate. But it is just as likely a reflection of the complexity of issues we face and the diversity of our community’s participants – from government officials and critical infrastructure operators to innovative start-ups companies and established commercial software developers to banking professionals, healthcare companies and consumer retailers.

But there are a few things we can all agree upon. First, software security is vitally important to our collective efforts to secure the technology we all rely upon. Second, there is a growing frustration over the lack of a widely accepted method for assessing the security of acquired software. This is not just a customer problem — though their desire and need to better understand the security of the software they purchase and use is clear — but it also presents an ongoing challenge for those who provide software and must effectively communicate and demonstrate an often complex process to a wide variety of stakeholders.

Recently, SAFECode Board members suggested that we should look at this problem a bit differently. Essentially, they proposed that there may not be a “one size fits all” solution for software security assessment. I would go a step further and say that our search for such a solution has led to a state of inertia that we simply can’t afford.

It is time to look at this problem from a new angle, one that embraces all that we have learned in software security, but also recognizes the reality that the software development community is extremely diverse and there is currently a wide spectrum of security maturity among software providers. Though we all look forward to a day where a more consistent solution is available, and will continue the important work toward that future state, it is time we also take stock of the best of what is available to us right now. How can we better apply what we know today about how to “do software security right” to help customers more effectively understand and manage the risk from acquired software? What is the best mix of technology, process and practices we can use to address this problem today, even as we work toward a better vision tomorrow?

SAFECode’s own evolution reflects our desire to reach across a more diverse segment of our community to better analyze, apply and promote the best mix of software assurance technology, process and practices. We want to work not only to improve software security practices, but also to better communicate and demonstrate to customers what these practices mean for their risk management efforts. To help us achieve our goals, we recently opened SAFECode membership to now include any organization with a demonstrated commitment to software assurance, thus expanding our membership beyond our original audience of commercial technology providers for the first time.

SAFECode’s mission hasn’t changed, nor has our focus or belief that software security comes from the developer’s adoption of a secure development process. Our guidance has always reflected our efforts to identify, advance and promote software assurance methods that have proven both practical and effective based on the real-world experiences of our members. Now that we have seen the benefits of this type of focused sharing, we want to expand the diversity of organizations from which these experiences are drawn so that we may support a wider range of software security needs, including better supporting those that seek to learn more about how to evaluate the security of acquired software.

I encourage you to read our recent blog post from Steve and Eric and check back here often as we plan to continue this important conversation. And if you have something to add to the mix, consider joining our efforts. We may never reach consensus on every aspect of software security assessment, but I feel confident that we can find some practical solutions that move us closer to our goal.

Software Assurance Forum for Excellence in Code (SAFECode) - All Rights Reserved