Home > Security

Computerworld - We have a major problem, which explains why I'm sitting in an airport right now. I'm heading off to visit some third parties that develop portions of our software for us.

The problem is that some software we recently developed in-house was infected with malware, and the source of that malware was traced back to a third party's code. We were fortunate that the malware was pretty well contained, but the fact that this could happen at all raises questions about the security of our methods.

After I heard about this incident, I started looking into my company's software development life-cycle (SDLC) process, which is meant to help us develop systems in a very deliberate and structured manner. To my mind, any SDLC that doesn't include taking sanity checks on security isn't worth much. And upon investigation, it was painfully obvious that we lacked robust security sanity checks for third-party code. Apparently, assumptions were made and we ended up with verbiage in our contracts that said it would be the third party's responsibility to verify that all code was free of security bugs and other potentially threatening anomalies. Assumptions about security always make me wince

In my meetings, I want decisions made on roles and responsibilities, expectations and methodology. Of course, I don't expect developers or quality assurance engineers to manually review source code, so I expect to invest in technology that will help in this analysis.

As I prepared for this trip, I started looking into the technologies that are available in the marketplace for this sort of automated code vetting, and my initial investigation has revealed that several companies offer such tools. There are products that would reside in-house, or we could go with a software-as-a-service option. At this early stage, I find the SaaS model intriguing, since my company has a Web-based collaboration tool that allows third parties to submit code for incorporation into our homegrown software.

One question we will have to answer is whether we want to burden the third parties with the responsibility of doing the analysis or conduct the analysis ourselves. Burdening the third parties may hinder innovation. Doing it ourselves will add to our overhead.

Dynamic or Static

My research also taught me about the approaches that are available for code checking. There are two principal ways of doing this: static and dynamic. With static analysis, the raw source code is reviewed for indications of poor programming practices that could lead to a security incident, such as leaving sensitive information in the comments of the code; not conducting bounds checks, which can result in buffer overflow attacks; and lack of input validation, which may lead to SQL injection attacks. Dynamic analysis is more, well, dynamic. In a dynamic analysis, you actually attack the compiled application and look for indications that it's susceptible to exploitation.

One constraint for us is that we'll have to find a product that maps to all the programming languages we use; we don't want to have to invest in multiple products to cover everything. And we'll have to review the license model, the support structure, the reporting mechanism and overall flexibility when it comes to incorporating the product into our various SDLC processes. In addition, I'll want the ability to audit and govern the process if necessary.

After my travels, and no doubt a lot more meetings, I'll formulate business requirements and draw up process documents. I don't imagine this will be an overnight change, but given the risks, there will most definitely be a change.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Read more about Security in Computerworld's Security Topic Center.