Faberwork’s Notes and Trends offers new approaches and tools for companies to proactively address uncertainty and risk. Here we look at the US government’s report on cyber risk and coding languages.
The generic term “legacy code,” the bane of the IT department, is on its way to a definition courtesy of the US government. Legacy code is usually thought of in the negative. It is not a new code. The code may have been written in COBOL, FORTRAN, or any number of other languages people don’t even recognize today.
However, the problem is that the legacy code is not merely expensive to run. In this period of rampant cyber risk, it can be dangerous. The level of danger for a company is usually small, even if the code is compromised. The prospect of cyber war means that the collective risk has risen to the level of the Office of the National Cyber Director.
The problem with cyber risk introduces us to the recent White House paper on the topic. For those not used to administrative processes, the White House report BACK TO THE BUILDING BLOCKS: A PATH TOWARD SECURE AND MEASURABLE SOFTWARE, February 2024 looks like any other governmental study. It is not.
Is this another Y2K?
The Y2K event was a creature of our clever creation. Early computers were, by today’s standards, tiny. Computer code, COBOL or otherwise, needed to be extremely concise and efficient. The world of programmers soon agreed informally on a simple hack. All dates should have two digits for the year, instead of four. So, 1995 was simple 95 in the code. It was acceptable until the year 2000 came on the horizon. Then 05 could be 1905 or 2005 etc.
As the millennium approached, individuals, corporations, and governments panicked. The US spent over one hundred billion dollars alone to fix the problem. It was, with minor exceptions, fixed and the crisis passed. Nevertheless, Y2K has lessons for us now.
Corporations, especially, should pay close attention to what happened at the millennium. The federal government studied the issue closely and coordinated attempts to ameliorate it. Corporate customers, like those facing Y2K, asked for certification that the company’s code is safe. These types of certifications may well begin to emerge now. Is the mere use of COBOL, FORTRAN, and C++ now a breach of contract?
What to do with legacy code
Legacy code is getting the beginnings of a definition from the White House report. Code, generally, needs to be “Memory-safe.” This demands that the programming languages used are themselves immune from bugs in their memory access. This approach follows the suggestions of Microsoft and Google. The “suggestions” have been directed to C and C++ because these studies found that around 70% of serious security bugs result from memory problems and that these languages are central to the problem.
In a sense, anything that is not memory-safe has become the core of a company’s tech debt. Technical debt, like legacy code, is an ill-defined term. Technical debt is the accumulated IT property/liability of a firm, which is under-performing or suboptimal in some important way. Usually, it is some version of legacy code but may also encompass systems that are no longer supported or other varieties of undocumented programs.
While the notion that the country suffers from a tech debt legacy has been around for years, its size and importance have recently achieved new recognition. The accumulated tech debt legacy is now estimated to be on the order of $1.5 Trillion. And there is nothing invisible about it. It accounts for over 20% of corporate technology assets.
The tech debt has long been recognized as a corporate risk management problem. Now companies are attempting to manage it like any other liability. No one expects to eliminate the country’s tech debt in the short or long run.
The rapid change in technology, however, presents a problem with corporate programs to amortize their tech debt. Tech debt continues to accumulate and has become a macroeconomic concern. Companies over the last decades have been required to digitalize their processes to remain competitive. As it did so, each year it added to its accumulated technical deficit, some of which was legacy code.
Now, the White House paper makes it clear that tech debt, or a portion of it, has grown into a national issue. Indeed, a national defense issue. And one for which the government will likely first seek a kind of Y2K consensus solution.
With aggressive government actors seeking to exploit weaknesses in the code, and not a static target like a date, the country’s legacy code problem grows. It may not be possible to have a consensus solution. The solution may need to be 100% compliance.
Governments exposed
Governmental entities are themselves likely to be the most exposed to the problem since they have many of the facilities that are likely to be targeted in a cyber-attack. Corporations are also highly exposed to cyber-attacks emanating from the tech deficit and its legacy code.
Corporations need to plan for the heightened problems created by the White House paper. What the government does not compel, the legal system will require. The cyber threats now facing the country will demand action. The government is headed toward legislating minimum safety requirements for public code. That said, it may not be possible to achieve effective regulations soon due to a lack of political will or a short time frame. In a longer time frame, governmental action should be expected.
The civil system, on the other hand, should be expected to act as it did in Y2K. Then, the sale of computer systems came with a certification that the code was cyber-safe. At least the code can’t contain known defects like defective legacy code.
Are programs written in C++ now automatically in breach of existing contracts? Will new contracts bar the use of C++? It is not too early to ask. The potential cost of legacy code just got a lot higher.
In addition to the risk of cyber-attacks, the legacy code has many other operational issues. These will be addressed in an upcoming article.
