Security manager's journal: Keeping in-house code safe

Our manager's company has shockingly little oversight on the security of software code written for it by third parties.

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.

Trouble Ticket

At issue: A third party's software code unleashed malware.

Action plan: Look at the entire software development process and incorporate automated checks of source code.

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 principle 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.

Security Blog

Join In

Share your thoughts and ideas about security in discussions with fellow IT pros at Computerworld.com/blogs/security.

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.

Tags securitydata protection

Keep up with the latest tech news, reviews and previews by subscribing to the Good Gear Guide newsletter.

Mathias Thurman

Computerworld (US)

Comments

Comments are now closed.

Most Popular Reviews

Follow Us

Best Deals on GoodGearGuide

Shopping.com

Latest News Articles

Resources

GGG Evaluation Team

Kathy Cassidy

STYLISTIC Q702

First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.

Anthony Grifoni

STYLISTIC Q572

For work use, Microsoft Word and Excel programs pre-installed on the device are adequate for preparing short documents.

Steph Mundell

LIFEBOOK UH574

The Fujitsu LifeBook UH574 allowed for great mobility without being obnoxiously heavy or clunky. Its twelve hours of battery life did not disappoint.

Andrew Mitsi

STYLISTIC Q702

The screen was particularly good. It is bright and visible from most angles, however heat is an issue, particularly around the Windows button on the front, and on the back where the battery housing is located.

Simon Harriott

STYLISTIC Q702

My first impression after unboxing the Q702 is that it is a nice looking unit. Styling is somewhat minimalist but very effective. The tablet part, once detached, has a nice weight, and no buttons or switches are located in awkward or intrusive positions.

Latest Jobs

Shopping.com

Don’t have an account? Sign up here

Don't have an account? Sign up now

Forgot password?