Home  /  Empower and Protect  /  Software Assurance Begins with Secure Development

Software Assurance Begins with Secure Development

By Bill Barnes •  October 12, 2012

I’d like to talk about software assurance (SwA) and its importance to application development.  Which means I’d also like to talk about its importance to application developers.

SwA isn’t a new concept; applications have been evaluated for their security posture through manual and automated methods for quite some time.  Unfortunately, the bad guys have been more efficient at finding and exploiting vulnerabilities than the good guys have been at finding and fixing them.
Worse still is that when the good guys find vulnerabilities, this doesn’t always translate into effective remediation or prevent the propagation of similar vulnerabilities in future releases of the same or different applications.
And these concerns apply to all applications.  While Web applications have received most of the recent attention where vulnerabilities are concerned, SwA plays a critical role in mature development processes regardless of an application’s operating environment.

Software assurance starts with two fundamentals.

There are two fundamental concepts of software assurance that must be embraced before you have a chance in the wild against determined attackers: (1) thorough and effective analysis and testing of the application and (2) SwA-savvy developers who either avoid introducing the vulnerabilities to begin with or effectively remediate them once found.  I don’t mean to oversimplify SwA, but this really is the bare minimum to get you started.
Notice that I mentioned analysis before testing?  SwA analysis doesn’t begin and end with scan results.  In fact, it’s estimated that more than 50% of application vulnerabilities are not even detectable with the automated scanning tools currently on the market.  Design and architecture are big culprits here.  Another significant portion of SwA vulnerabilities can be attributed to the development environments and data handling practices, which also aren’t testable.

Now we’re getting to the crux of the SwA problems facing the world today.  This cannot and will not, in the foreseeable future, be solved purely with tools.  I wish it were that easy.  It would be so nice to be able to run static and/or dynamic scans that provide a definitive assessment of the application’s security posture.  But many applications are far too complex for fully automating security assessments.

Software security as a software quality issue.

To think about this in a simpler context, consider it a code quality issue.  Bug tracking, bug fixing, regression testing, and user acceptance testing are all critical aspects of mature development processes, and are all significant components of the software development lifecycle (SDLC).  So why do SwA practices rarely appear in the SDLC, and when they do, are given much less focus than other areas?
It is significantly less costly to fix or prevent security defects as early in the SDLC as possible rather than waiting until the application is nearly complete to discover and address these problems. In fact, if you begin SwA with the design and architectural phases, the cost is relatively small.  Once you look at the QA, testing, and operational phases, the repair costs can become crippling.
Makes sense, right?  If you spend a year developing an application that relies on insecure code or an architecture that is inherently insecure, you’re likely to have a very big problem on your hands once you or a third party performs a thorough security assessment.
Here’s another way of thinking about this: Vulnerabilities are essentially defects in the application, but can have much more dire consequences.  Vulnerabilities are defects that can sink a company, compromise missions, or endanger a warfighter.

Software assurance starts with software developers.

There are a lot of talented developers out there that translate concepts into applications within very strict constraints of cost, performance, and user experience.  They can do this because that’s what they’ve been trained to do.
What they haven’t necessarily been trained to do is to accomplish these same goals in a more secure manner.  That needs to change.  Developers need to be fully versed in software assurance.  The people that write the code should fully understand the security implications that come with their code.
It really is that simple.  We can either train developers to write secure code and provide them with the necessary tools and processes to do so, or we can scan their applications and hand them a report that might as well be written in Hackistanese and walk away.  If the latter, I can assure you that we’ve wasted their time and ours.
I’m not pointing a finger at the development community for the world’s IT security issues.  However, software vulnerabilities are a huge problem and the only people that can address their root cause just happen to be the same people that spend their day developing the applications that connect and automate the world.  The vast majority of them have never been introduced to, let alone trained in, SwA.  It’s time to start introducing and training them.
(Some detractors still believe that coders should just write code while security folk worry about security.  This approach is what has led us to where we are today.  If the developers aren’t trained to write secure applications, we’ll never have applications that have security built in.)
Developers are a smart lot.  If we present them with a fair challenge, they will prevail.  If we’re to ever get ahead of the game in securing applications, we must educate and challenge the development community to only write secure applications.
Software assurance is and will be mandated, but compliance can only ever be achieved by the people who write the code – by building their applications secure to begin with.  As it happens, that’s also the most cost-effective approach to securing applications.



The Empower and Protect Blog brings you cybersecurity and information technology insights from top industry experts at Telos.


  • Avatar Jeff Bush says:

    “Developers are a smart lot. If we present them with a fair challenge, they will prevail.” – Very well said!
    Most organizations don’t do a good job motivating and encouraging writing secure code (and better yet, discourage insecure code). If that changed, most coders I know would rise to the occasion.

  • Avatar Bill Barnes says:

    Thanks for the comment – that’s exactly the point!

  • Avatar Joshua Tannehill says:

    I think it was Jeremiah Grossman who said one way to get secure code written from the beginning is with peer pressure. What he meant by that was have a game where each insecure line of code is tracked and the developers name is published internally weekly. Then the bottom dwellers will talk to the winners and produce better results. When you make it a contest or a game (especially in the developer community) it seems to get better results. Coders are gamers usually ;-)

  • Avatar Anonymous says:

    Thankfully, some (of whom I hope to be myself) will develop secure code while writing it. It chiefly depends on the person; the individual. Two kinds of people exist in this world, in a manner of speaking: those who drive, and those who ride.

  • Avatar Bill Barnes says:

    Thanks for the comment, Josh. That certainly sounds like an interesting approach!

  • Avatar Bill Barnes says:

    Thanks for the comment, Steve. We’re certainly the driving type!

  • Avatar Jack Kearney says:


    Very good piece you’ve written here, and the video by Charisse Stokes sums things up best, in probably the most succinct statements about SwA, and more importantly, why it is key.

    I would like to respectfully provide a comment on the title of the article “Software Assurance Begins with Secure Development,” and suggest that SwA can begin ever earlier in the SDLC, for example in the requirements and design phases. Then again, maybe the title does cover things, in that some software engineering experts include these concepts as part of “development,” implying more than software coding itself.

    Your thoughts here?

Leave a Reply

Your email address will not be published.

18 − fourteen =