Common Roadblocks to Source Code Fixes

Maneesha Mariam

From the technical point of view, the initial mitigation strategy would be for an organization to rectify the discovered vulnerability within the source code of the web application. This is globally accepted by web application security experts and system owners. But nowadays, there arise many situations where modifying the source code of a web application is troublesome such as:

  • Lack of resources
  • Third-party Software
  • Outsourced App Dev (requires a new project for the changes)

Fixes in source Code level and Virtual Patching are considered as NOT mutually exclusive. They are processes that are executed by a different team.  

Common roadblocks to source code fixes

  • Patch Availability

It is difficult for a customer to modify the source code themselves if they identified a vulnerability in a commercial application. In such scenarios, the customer has to wait for an official patch to be released from the vendor side. An officially supported patch might not be available for the long term, since the vendors usually have inflexible patch release dates. 

  • Installation Time

The normal patching process in most organizations is time-consuming, even though the official patch is accessible or the source code fix could be applied. This is because of the extensive regression testing required after code changes. It is very common for the testing gates to be calculated in months.

  • Fixing Custom Code May Be Cost Prohibitive

Web assessments have to be done to identify the vulnerabilities in a web application. It includes source code reviews, vulnerability scanning, and penetration tests. Many of the organizations still believe that the cost associated with the identification of the vulnerabilities often pales in comparison to that of actual issue fixing. It is too expensive to re-code the application when vulnerabilities are not found early in the design or testing phases but rather after an application is already in production.

  • Legacy Code

In a situation, where the vendor has no longer supporting a version of their commercial application and it is using by an organization – the application’s legacy code cannot be patched. If the company is forced to use an outdated code because of the house custom-coded functionality being added on top of the source vendor code. This functionality can be tied to a critical business application and prior upgrade attempts may break the functionality.

  • Outsourced Code

As the business chooses to outsource their application development, they may find that executing vulnerability fixes might require a fresh project. Many organizations are facing the hard truth that poor contractual language continually does on the secure coding issues but only functional defects

See the below links:

 Virtual Patching
Advantages of Virtual Patching
Virtual Patching: Definition