Standard Libraries, Other Libraries, and Software Reuse

A software library is a repository of

Libraries can be developed by prewritten code, classes, procedures, any developer in the IT supply scripts, and other programming elements.

chain, and thus can be of

A developer might manually add a software almost any level of reliability, library to a program to achieve more verified correctness, and functionality or to automate a process without writing the code for it from scratch. suitability for purpose or This allows the developer to create the compliance with security functionality they want to use, or call, within needs.

the application, but without having to write all the code necessary to provide the functionality, because it is contained within the code library. This implies benefits can be realized simply by reusing components stored within the library.

For example, when developing a mathematical program or application, a developer may add a mathematics software library to the program to eliminate the need for writing complex functions. All the available functions within a software library can be called as required and used within the program that is calling it without defining them explicitly.

This leads to a loosely defined hierarchy (or family tree) of libraries, which may be useful when planning a software development project.

• Operating systems (OSs) and hardware libraries. These are provided by their respective vendors and should be supported with digitally signed updates.
• Programming language libraries. Each language may have dozens of libraries associated with it, supplied by the vendor of the integrated development environment (IDE) or language tool sets being used.
• Development frameworks. Microsoft's NET generally has multiple frameworks that encompass different functions and features.
• In-house, project-specific, customerspecific, or product division-specific libraries. Organizations may harvest their own successful projects for libraries of proven, tested, and trustworthy code to reuse in subsequent developments.
• Third-party, open-source libraries of unproven pedigree or nature. These may be from textbook, journal, or magazine publishers; blogs; or user community discussion boards. Much of this code is well written and should be suitable for reuse once it has been thoroughly inspected for potential back doors, classic coding errors, Trojans, or other logic bombs.

This last library level highlights the real opportunity to trade risk for time and money via software reuse strategies.

Reuse code too quickly, without adequate inspection, and you risk coding in a potentially exploitable vulnerability; spend too much time inspecting it and maybe you could have written better, safer code and had time to spare in the bargain.

Programmers are encouraged to reuse code wherever possible. Junior programmers are

• Third-party, open-source libraries, published by reputable sources. These may be associated with development frameworks and focus on specific sets of function, style of coding, or other development needs. These sources may be aftermarket vendors, researchers, end-user organizations or professional associations.

encouraged to do as much code reuse as possible; this can lead to them spending more time searching for a reusable snippet than just designing and writing a good new bit of code themselves. The time pressures most projects are under dictate this strategy. This can, however, lead in-house and third-party developers to take shortcuts, such as using code that they have not inspected closely or performed any security testing on. At this point, an organization starts to inherit the sloppy programming mistakes of others.