Financial Exchange

Reviving a Financial Services Application

A financial exchange needed to keep its Angular 1 applications secure after the framework reached end of life in 2022, when upgrading wasn't practical. Ollon took over maintenance under an SLA, patching vulnerabilities directly in the framework's source code as discovered. The exchange has stayed secure and compliant on Angular 1 without migrating, and Ollon continues to provide support.

Situation

A financial exchange faced a critical challenge with its applications built on Angular 1, which reached end of life (EOL) in January 2022. With Angular 1 no longer receiving updates or security patches, maintaining compliance with industry standards became increasingly difficult. Upgrading to Angular 2 posed significant resource and time constraints, making it impractical in the short term.

Solution

Ollon stepped in to provide ongoing maintenance and support for the exchange's Angular 1 applications post-EOL. Operating under a structured SLA, Ollon ensures rapid response and resolution to any security vulnerabilities discovered in the framework. This proactive approach includes timely patches and fixes directly applied to the core library, enabling the exchange to continue using Angular 1 securely while adhering to regulatory requirements.

Results

Since Angular 1 reached EOL, Ollon's support has enabled the exchange to maintain application security and compliance without the need for immediate migration to a newer version. By mitigating risks associated with unsupported software, the exchange has sustained operational continuity and minimized disruption to critical financial services. Ollon's responsive maintenance approach has allowed the exchange to focus resources on strategic initiatives rather than software upgrades, ensuring stability and security in their application ecosystem.

Technologies

JavaScript, Angular

Our Expertise in Action

End of life application strategy

A financial exchange had applications running on frameworks that reached end of life, first Angular in 2022 and later a Spring Framework version in 2024, and a full rewrite each time was neither fast nor affordable given the security compliance they were required to maintain. Ollon delivered ongoing maintenance instead, keeping each framework secure and compliant past its official end of life date rather than forcing a migration on an artificial deadline. That approach let the exchange stay compliant and upgrade on its own timeline instead of being forced into one by a vendor's support cutoff. The same pattern across two separate frameworks shows this is a repeatable approach, not a one time exception.

Legacy framework security patch maintenance

Running frameworks past their end of life date only works if new vulnerabilities get caught and patched quickly, since the vendor is no longer doing that work. Under an SLA requiring the exchange to keep those frameworks secure and compliant after they reached end of life, Ollon monitored the standard CVE databases and patched each vulnerability as soon as it became publicly known, testing the fix before pushing the updated package to the exchange's own repository. That ongoing patching is what kept the exchange compliant without requiring a migration off frameworks the vendor no longer supported. For both Angular and Spring, Ollon effectively took over support that each framework's own community had already abandoned given their age.

Angular Library Support

A financial exchange's application had run on AngularJS after the framework stopped receiving official updates, leaving new vulnerabilities as an open risk with no vendor patch coming. Ollon took over support directly in the framework's own source shortly after that support ended, patching and testing specific AngularJS vulnerabilities, including a regular expression denial of service issue and CVEs affecting the core library, as soon as each became publicly known. Each fix required understanding how the vulnerable code worked inside AngularJS itself, not applying a generic update the way a supported framework would allow. That source level support has kept the application secure on a framework its own community no longer maintains.

Spring Library Support

When the exchange's Spring Framework version reached end of life, keeping its Java application secure meant maintaining the framework's own libraries directly, since the Spring community was no longer doing that work. Ollon took over that support in Spring's own source, patching vulnerabilities across Spring Security, Spring Boot, and Spring Data as soon as each became publicly known, testing each fix before pushing the updated package to the exchange's own repository. That sustained patching has kept a Java application secure and compliant on a framework version its own community had already abandoned.