Transform function logic without touching code.


Securing web apps is not just about protecting from threat, you must also fix flaws in software logic that can be exploited by expected traffic. They are normally due to application misuse that the developers had not envisaged. They are typically reported by security researchers through penetration test findings either prior to or post breach.


In some cases abuse may be noticed through advanced anomaly detection, however in most cases this is only useful in reporting and investigating a breach. Even if you can detect misuse, isn’t it better to just fix them?


So what sort of security flaws are we talking about:


List of security flaws

A real example of an application penetration test with a list of bugs


Then the developers that created the problems should fix them right? Although this is true, often development teams have constraints on them that mean the timing of patch deployment or bespoke code fixes is delayed.


These include:


1. The required fixes are not available There are a number of reasons that either the required vendor patches or access to the flawed code is node available. The vendor hasn’t produced it, the vendor is out of business, it was custom code developed by teams that are no longer employed by you, mergers or acquisitions where the dev team was not in scope.


2. Fixes are not technically compatible. In patching or upgrading the application to address security flaws other functional components break.


3. Fixes are not commercially compatible with the app. By upgrading or changing underlying components dependent software is no longer supported.


4. Teams have other priorities Developers and patching programs typically already have a prioritized plan that they are working. Urgently writing story books and then rearranging priorities has to compete with other tasks those resources need to deliver.


5. The development teams don’t have the skills. The specifics of security exploits matter and hence the ability to produce code that is resistant to known to the specific of an an advanced exploit or to bypass techniques is specialist knowledge.


6. Timeframes are short. Even for active development programs that have integrated security testing advanced exploit testing is either left till late in the deployment process and even worse, discovered whilst in production. However once an application is past active development and has moved into maintenance, addressing security bugs in the required timeframe is just not practical.


In any case, when compliance deadlines or for the launch of a new function are at risk fixing is an urgent matter. If a capability launch has to be delayed it may have serious impacts on already committed spend like advertising and compliance deadlines are typical rigid.


In all these cases shielding can help Shield First then remediate.