Don't sit back and wait for source code updates

Constantly updating the source code isn't as intimidating as it sounds, and it's the best way to take advantage of new features and protect your code.

译自 Don't Sleep on Source Code Updates，作者 Evan Prowse。

Going back to the steps to maintain and update source code can be a daunting task, especially for organizations that rely on open source software (OSS) and have limited support windows. Over time and with frequent releases of code, it's getting harder and harder to remember which what, which version was used, and why someone wrote the code that way. As technical debt accumulates, it becomes increasingly difficult to fix underlying issues or CVEs. In addition, as OSS frameworks and tools evolve, so does the amount of work required to migrate to the latest version.

Organizations operating in highly regulated industries face even greater challenges. In order to comply with mandatory regulations and standards, escalation can serve as a critical checkpoint and must be completed as per policy or when a CVE is present. Treating these upgrades as one-time events only when mandated adds another hurdle to the often complex and process-heavy application delivery pipeline.

We witnessed this firsthand at the end of 2023, when OSS support for the open source Java framework Spring Boot (2.x) version ended, and many organizations tried to make room on their roadmap for upgrades or extend their support windows with commercial support.

Business value always comes first

At a time when it takes months of work to deliver new code, code is sitting idle, and the data center is running smoothly for half a year, the slogan is simple: "If it ain't broke, don't fix it." "Quarterly releases are the best-case scenario. More commonly, updates occur twice a year, and sometimes even only once a year.

Most code updates are focused on delivering new features to the enterprise, with little time dedicated to addressing technical debt. Security and stability are often overlooked unless explicitly requested by the end user. Engineers and software architects struggle to defend these critical elements, only to end up seeing them evolve into bigger problems over time. As a result, tinkering with old code becomes a daunting task as developers stay away from aging codebases.

This contributes to the perception that updating source code is a complex, difficult, and low-business value process. Continuously updating source code has yet to take its place in organizational culture, and many companies are still holding their breath to do whatever they can to help them evade the imminent threat of CVEs.

The Importance of Upgrades: Spring/Java Examples

The Java/Spring ecosystem is a great example of the importance of continuous code upgrades. Java is an extraordinary language, and in its 25-year history, few updates have broken existing code. An amazing feat – but also a double-edged sword. While code written in the 90s may still run on the latest version of Java, you're in a bad position if you don't do any patching, maintenance, and dependency updates along the way.

Today, things are moving faster and there are more threats to application surface area than ever before. On a more positive note, the pace of innovation is also rapidly accelerating, with the demand for the latest and greatest tools and technologies driving development teams to upgrade.

For example, Java 21 and Java 22 are widely regarded as the most important releases in Java's history, providing key new features and innovations for those making upgrades. While Java support from Oracle has always been available, many organizations are missing out on potential savings and benefits by not upgrading.

Some organizations resist upgrading, arguing that older versions are more stable, but this is often not the case. Patches for Spring Boot 3.1 and 3.2 were both released on the same day, fixing the same issues, so no one is inherently more stable than the other. However, stick with 3.1 and you're missing out on the new features introduced in 3.2. For example, Spring Boot leverages the ability of Coordinated Restore at Checkpoint to speed up boot times. At the same time, Native Images creates a smaller application footprint and reduces the exposed attack surface. This combination makes applications less susceptible to potential threats and reduces the memory required to host them.

A culture of continuous upgrading

Creating a culture of continuous escalation enables your organization to keep pace with innovation and better defend against malicious actors. When an upgrade becomes a normal part of the software development lifecycle, the upgrade no longer takes two or three sprints, and you don't need to tell the project manager that you can't deliver features because you're dealing with a series of technical tasks. It's tools + automation + discipline that lets you get these things done as you go. The way forward isn't about how cool and fancy you can get, it's about maintainability of your code. It's about being able to look ahead to the next few years and be confident that your code will be maintained without adding more technical debt to the code running in production. While major updates may still require some work, there will be simple buttons and recipes to keep up.

The goal is to create a culture where continuous upgrades are an integral part of your process without having to think twice. It's a guarantee that the products you release to the market today will stand the test of time, remain safe and reliable for years to come, and ensure that you meet compliance requirements. It sounds great, but it takes investment to make it happen.

Enhance your ability to upgrade

For organizations that haven't gone through the upgrade process and are still using legacy Java, the ability to upgrade isn't always easy to turn on. There's no cheat code to skip the training and let it work at scale. Every organization has patterns or methods, such as internal libraries or legacy APIs, that can't simply be plugged into existing recipes...... Code changes will be inevitable.

It's time to hit the gym – you need a workout plan. Here are three recommendations to consider.

1. Start with leadership buy-in

As with any major work-style change within an organization, a cultural change supported by leadership is critical to success. Before you can move forward, people who are responsible for things other than the functionality of the application must be on board. This could mean CIOs, CSOs, enterprise architects, or even application owners with a portfolio.

Software leaders can no longer bet their business (and their customers' business) on the safety and reliability of their code. Reducing the time from CVE bulletin to code patching is now critical.

2. Prioritize release schedules and portfolio visibility

Most importantly, good planning and visibility are key prerequisites before getting your hands dirty with any code. This starts with knowing which versions are coming soon. For example, in 2023, there are only four weeks when there are no releases for the Spring Framework. The Spring team is constantly bringing in third-party dependencies so that everything under each release is patched, tested against each other, and verified to work.

It's very valuable to know what's coming, and to know the release train of those dependencies, so you'll always know when everything is patched.

It's also important that your CSO needs to have a list of all known CVEs, as well as visibility into what's actually running in your application portfolio. As the functionality and codebase grows, it's easy to lose something. Developers are always looking for solutions to solve their problems, so maybe on the way they plugged in a library here and there to help them solve the problem they need to solve. You need to keep up to date with all of this.

3. Leverage tools and automation

By using scanning tools and application discovery, you can identify the biggest risks in your portfolio, categorize applications as opportunities that are easy to upgrade, and determine which ones require more effort. This is where automation comes into play.

Automation tools

When you're ready to start upgrading your application, you need to determine a reasonable starting point that won't impact or disrupt your existing development pipeline. It may not be sustainable to have all teams start working on escalations individually; Conversely, a small team and some automation might be a good place to start.

For analysis that identifies applications that are easy to upgrade or require less human intervention, tools such as Open-Rewrite provide an easy way to start automating refactoring and fixing. Open-Rewrite includes an automated refactoring engine that runs pre-packaged, open-source refactoring recipes for common framework migration, security fixes, and style consistency tasks.

Once you've addressed the applications that are easy to upgrade, you can start working on complex applications that don't have existing recipes. As you learn more about the applications that need to be upgraded, you can develop your own recipes to extend your upgrade efforts and build your own framework for future use.

Application platform

One question that may arise when considering upgrading source code is how to manage the code running in production while the upgrade is being made. Do you stop the app when you upgrade? That's where the advantages of an application platform over a patchwork of tools and services come in. According to the 2024 State of Cloud Native Application Platforms report, enterprises are looking for a single platform experience that supports multiple application types and deployment models. A cloud-native application platform allows you to run multiple instances that can be upgraded or patched while others are running, or change the operating system layer of instances running with cloud-native build packages in production.

Rinse, repeat, learn

To truly achieve a state of continuous escalation, it is necessary to "return to the gym even if you are tired and sore." However, once you've found a workout that fits your lifestyle, you'll incorporate it into your daily routine. By going through the upgrade process, you'll figure out which patterns work for your organization, learn how to make better use of tools like Open-Rewrite, and create recipes and your own frameworks to help apply them at scale.

Nowadays, everything is moving faster, and there are more opportunities for malicious actors, but there are also more possibilities and innovations that can be exploited. So, don't bet your business on the way it has been done in the past; Start implementing small changes today and work to build your own culture of continuous upgrading.