As we reflect on the 25-year anniversary of Y2K, it’s easy to view the lead-up to December 31, 1999, as anti-climactic. Thanks to the hard work of IT professionals and developers, what could have been a global disaster was averted, as we were fortunate to foresee the problem in advance. Yet, 25 years later, some of the lessons learned from that event now need to be applied to software-defined applications.
When you reflect on the 1999 Y2K-scale event, one can see that we are all facing “Y2K” threats nearly every day now – particularly with increasing numbers of critical vulnerabilities exposures and the coming age of AI in the world of software development. In this new environment, it’s important to remember the lessons learned from Y2K, and try to anticipate our next major “Y2K-scale” event to implement these learnings.
Years of “Mini-Y2K” Moments
There are tremendous benefits to the software advancements made in the last 25 years. Work flows have improved, device capabilities are rapidly advancing, bugs can be corrected in a matter of hours vs. days or weeks, etc. As such, society has grown almost entirely reliant on properly functioning software to live. Unfortunately, it is that reliance that has the power to bring the world to a standstill if critical software vulnerabilities are exploited.
In the last four years, there have been a couple of notable moments that had the power to replicate what we feared would happen during Y2K including:
- December 2021: Log4J/log4Shell vulnerability
- Month 2024: XZ backdoor attack that could have been disastrous if the community had not responded as quickly as it did.
- July 2024: CrowdStrike outage
Log4J was the first moment that the world realized that a single vulnerability in a major programming application could cripple major software systems if exploited. The CrowdStrike outage, almost three years later, highlighted similar issues – this time with real-life examples of what can happen without the software we take for granted, including grounded flights, banking systems brought offline, and over $5 billion in losses for Fortune 500 companies. XZ Utils was a library that was embedded in multiple operating systems, and a new version all of a sudden included a sophisticated attack that opened an SSH backdoor.
There are countless other lesser-known instances where software vulnerabilities, if not discovered and patched, have the power to take down our critical infrastructure. For example, in July, a leaked Python access token was discovered in DockerHub. Had it fallen into the wrong hands, this access token would give a threat actor administrator access to all of Python’s, PyPI’s, and the Python Software Foundation’s repositories, supposedly making it possible to carry out an extremely large-scale supply chain attack.
The moral of these stories is that we’re experiencing more “Y2K’s” now, as attackers have realized that compromising a software development lifecycle is a viable way for a malicious user or group to gain unauthorized access to valuable software resources and assets.
Lessons Learned from Y2K and Adaptations for Software
Our infrastructure has changed a lot since 1999, most notably through a move away from a hardware-first mentality to a more software-first mentality. Solutions to solve business issues and to provide a competitive edge now rely on virtualized infrastructure, headless servers, microservices and a cross matrix of dependencies.
However, principles learned from the events of Y2K are highly applicable to today’s software-defined age in terms of what’s required to ensure safety and sustainability:
- IT leaders must have accurate inventories of what should be running in production and how it was built, and automated ways to detect deviations.
- The need for safer, faster responses with the aid of automation, when a confirmed critical vulnerability or risk is detected.
- Details matter. Updates for an enhanced user experience are great, but they shouldn’t come at the expense of mission critical functionality or system reliability. Losing visibility is a risky proposition and will cause issues.
- Coordinating and practicing responses across business owners, Dev(Sec)Ops, HR and IT teams in moments of disruption to ensure continuity of mission critical assets and processes.
These lessons and subsequent events that have caused outages and data breaches have fundamentally altered the developer and IT security job functions. More and more is being asked of these professionals, requiring them to have a far more robust skillset than they once did to protect their tech stacks and environments. In the era of Y2K, the IT, security, and developer job functions were well defined but often siloed. Now, the lines are blurred – it is inefficient and dangerous to assume that software development and security are not intrinsically linked.
Luckily, the teams securing our software supply chain have risen to the challenge and adapted accordingly, which is why we are able to talk about recent software-related incidents as “what-ifs” rather than post mortems. The teams are ready to detect, and quickly respond to and mitigate risks when they arise.
The Next “Major” Y2K Moment: The 2038 Problem
While we’ve explored how recent events were commensurate with the potential scale of Y2K, we are currently on the way to a nearly identical situation set to occur in 2038.
Dubbed the “2038 Problem,” it refers to an issue with UNIX time (expressed as UTC) where the Linux operating system will not be able to record time past the date of January 19, 2038. Is it going to matter? UTC is critical for the ability to authorize certificates for devices that run on Linux. Luckily, we have learned from the Y2K event and modern programming languages are designed to overcome this potential weakness. The real problem might occur for those older legacy systems that could suffer an issue. So, we still need to be vigilant and identify them before that impending date because those issues will be complex challenges that won’t have a straightforward solution.
How we address these problems in the next 13 years will be paramount. But the good news is that we’ve learned from the Y2K event and the subsequent software catastrophes. We will still need to improve and effectively strategize with the best minds in the industry to overcome these challenges since they are not going away – this means continuing to remove the barriers that silo developers, security and IT teams and create seamless collaboration with a common goal of securely delivering software to the world.
About the Author
Paul Davis is Field CISO of the JFrog. He is an experienced IT Security Executive who works to help CISOs, IT execs and security teams, enhance protection of their software supply chain. Additionally, he advises IT security startups, mentors security leaders, and provides guidance on various IT security trends. Paul can be reached on the company website at https://jfrog.com/blog-author/paul-davis/
