|
|
|
|
 |
| Tech Update
|
|
Assessing the risks of open source
Source code security
|
By Thomas Murphy
September 13, 2002
| Provided by |  |
|
|
|
Beyond legal issues, most companies are currently concerned about software security. Security may be compromised in many ways, but the two broad categories are intentional and non-intentional. Intentional problems deal with specific code placed in the source with the intent to break security. This may be code with viral or Trojan horse behavior, back doors, or triggered destruction. Non-intentional security breaches are mainly caused by memory faults, which provide hackers with the ability to force open a door into standard infrastructure. These types of problems are currently seen most often, and generally occur in commercial software.
| [an error occurred while processing this directive] |
The most common way to identify security problems caused by memory issues is to utilize one or more memory profiling tools. These tools can track down many common pitfalls, such as uninitialized blocks of memory, buffer overflows, and memory leaks. Rational's PurifyPlus and Compuware's DevPartner Studio are good examples of products that aid in detecting such problems. They should be part of the software development process for all internally created software, and utilized as part of the evaluation process for all acquired and downloaded software. However, memory issues are becoming less critical with managed runtimes such as .Net or Java. These systems do allow native calls, and any code that accesses legacy will utilize this functionality, but the majority of code protects access to memory.
The more difficult-to-assess security problems are intentional defects. It is far easier to build secure software from the ground up than it is to assess a large library, a source, or an application to determine appropriate behavior. Application code that opens a back door to systems is nearly impossible to detect. However, to access a back door exposed as an API would require the attacker to load and run an application installed on corporate systems that expose the API. Network security will manage which users can access systems and load or run software. But applications such as Web servers or other systems that expose public functionality could be utilized to provide undocumented behavior.
The larger concern is that software may be installed that transmits critical data or performs a specific harmful behavior. This includes code that is triggered by an event (such as a specific date). The fear in open source is that, because it is a community effort, a malevolent person could utilize the process to place dangerous code in the standard distribution. Although some risk of this happening does exist, we do not believe it is greater than in a closed-source environment, where a vendor could hire someone who will then follow virtually the same process. The interview process certainly can not determine whether an extremely talented developer may have less-than-desirable career goals. However, because of the control of a commercial product over contributors and the ability to assign liability to a specific source, most organizations will focus their efforts on managing open-source products.
 |
|
|
|
|
[an error occurred while processing this directive]
![]() |
|
[an error occurred while processing this directive] |
![]() |
|
![]() |
[an error occurred while processing this directive]
|
|
[an error occurred while processing this directive]
|
[an error occurred while processing this directive] |
|
|
|
|
|
