A business application may function normally for years, yet hidden technical debt may accumulate behind the scenes. When a vulnerability is flagged in an application, or a third-party library/application releases a new version, teams sometimes implement a workaround first rather than updating the library for a permanent fix. These decisions can make sense at the time. The cost becomes visible when the team responds to the vulnerability and finds that deferred upgrades make the fix harder. Years of delayed maintenance can turn a small vulnerability fix into a major application upgrade, which may involve upgrading multiple libraries to a new major version. Upgrading to a newer version can change how an API or application behaviour functions. At this point, developers, as well as the security team, will need to spend more time identifying all the affected components, which can delay fixing the applicable vulnerability.

Consider a hypothetical situation whereby an online retail application relied on a certain framework for several years. When the security team identifies a vulnerability in the framework itself. The team should check which framework versions are affected and which supported release contains the fix to start assessing whether if there’s another component that needs to be upgraded as well. After investigation, they may find that the current library version doesn’t match the latest framework or the application server needs to be upgraded as well. The work from simply upgrading the framework involves source code upgrades, integration testing, regression testing, a deployment plan for different environments, and a rollback plan. Meanwhile, the teams need to ensure that all functions still meet business requirements despite a major version upgrade. This example provided doesn’t mean that all old software is unsafe. It means that any delayed maintenance or upgrade will affect the decision made during a time-sensitive response.

Here are some factors that developers will need to consider to help teams manage technical debt and its security impact.

Know what the application depends on

Teams will need to have full knowledge of what is the version of libraries dependencies, framework, runtime and operating system that are currently used by the application. Documenting functions helps plan regression tests, while recording component versions and usage helps assess whether a vulnerability applies.

Rank the debt that affects response

There may be different frameworks or runtimes for the application however, it doesn’t mean all need the same response. Developers will test and check to consider whether a fix needs to be applied and see if the component is still being supported. If it does not affect the application or a safeguard is already in place, the team should check whether it adequately addresses the specific risk. It will help to make a decision whether to defer the upgrade and come to review it at a later date.

Prepare upgrades before an advisory forces them

Regular scanning of source code, dependency scanning and monitoring security advisories help teams to detect vulnerability that required attention to it. With small upgrades planned regularly, it will help to improve decision-making when come to future security fix as there would be a planned test cycle that helps to identify whether it could break any critical function before deployment. For example, a hypothetical online retail application will need to test sign-in, placing an order, checkout and payment integration to ensure the workflow functions normally after the upgrades.

Control temporary exceptions

Sometimes it is good to document the solution that was used as a temporary workaround to resolve urgent matters and who implemented it, together with a timeline for developers to review it in future. If no documentation was done, this temporary workaround may silently become part of the system. It may work well temporarily however, the main risk is that nobody revisits it to resolve the underlying issue.

Having technical debt can slow down a team’s response time when a vulnerability affects its application. Keeping documentation of application functionality, library dependencies and operating system version and testing upgrades regularly can help with managing technical debt. Teams can be by tracking one application tracking and use that as an example to review maintenance work for their other application and build a regular maintenance cycle.

 

Follow us on LinkedIn for the latest happenings/updates.