Problem solve Get help with specific problems with your technologies, process and projects.

Security issues of using shared code

Security pros need to be aware of code that is being "borrowed" for custom applications.

If you've ever written a lot of code, you've probably found yourself thinking, "Someone must have already tackled this problem." You may even have gone a step further and done a Google search for relevant code that you might be able to incorporate into your project. But have you ever stopped to think about the security ramifications of using this type of code? If not, you should!

If you're a security administrator, you should take the time to ensure that you know the source of all of the code running on your systems. If your developers are "borrowing" code from external sources, you need to be aware of the validation procedure used to vet the code before introducing it into your environment and the risks inherent in reusing code. If you're a developer, you need to be clear about the appropriate security procedures to follow when importing code from a third party.


Of course, the level of scrutiny that you apply to reused code should vary based upon several factors. Let's take a brief look at the factors you should take under consideration:

  • Source – Where did the code come from? Was it a trusted source? If the code was written by a fellow developer within your organization, it probably requires less scrutiny than something downloaded from the Internet.

  • Complexity – The more complex a piece of code, the more scrutiny it will require. Unfortunately, the more complex the code, the less likely developers will be to tear it apart line-by-line looking for security flaws. If the code is simple (such as a template that creates an HTML drop-down box listing the 50 states), you can check it for vulnerabilities in a matter of minutes (if not seconds!). On the other hand, a 4,000 line program takes a lot more reverse engineering.

  • Application – Code that runs on your Web server should undergo much more scrutiny than code running on an internal client. You should analyze the operating environment and take those considerations into account when determining whether it's appropriate to reuse code. If you're writing an application that facilitates the transfer of funds between accounts for Web users, you'll probably want to write the entire thing from scratch. On the other hand, you can probably get away with borrowing portions of a form used to request more information from your company.

Sharing reusable pieces of code is not uncommon. There are entire books and Web sites dedicated to sharing code, either for a fee or at no cost. As paranoid as it sounds, you must assume that any piece of code that you obtain from someone else is designed with malicious intent. After all, as security professionals, it's our job to be paranoid!

About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the Guide to Databases.

This was last published in July 2004

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.