Web Application Defender's Cookbook

Externally Developed Applications

If a vulnerability is identified within an externally developed web application (either commercial or open source), the user most likely will be unable to modify the source code. In this situation, the user is essentially at the mercy of vendors, because he or she must wait for official patches to be released. Vendors usually have rigid patch release dates, which means that an officially supported patch may be unavailable for an extended period of time.

Even in situations where an official patch is available, or a source code fix could be applied, the normal patching process of most organizations is extremely time-consuming. This is usually due to the extensive regression testing required after code changes. It is not uncommon for these testing gates to be measured in weeks and months.

Another common scenario is when an organization is using a commercial application and the vendor has gone out of business, or it is using a version that the vendor no longer supports. In these situations, legacy application code can’t be patched. A common reason for an organization to use outdated vendor code is that in-house custom-coded functionality has been added to the original vendor code. This functionality is often tied to a mission-critical business application, and prior upgrade attempts may break functionality.