SE Radio 559: Ross Anderson on Software Obsolescence

Ross John Anderson, Professor of Security Engineering at University of Cambridge, discusses software obsolescence with host Priyanka Raghavan. They examine risks associated with software going obsolete and consider several examples of software obsolescence, including how it can affect cars. Prof. Anderson discusses policy and research in the area of obsolescence and suggests some ways to mitigate the risks, with special emphasis on software bills of materials. He describes future directions, including software policy and laws in the EU, and offers advice for software maintainers to hedge against risks of obsolescence.

Ross John Anderson, Professor of Security Engineering at University of Cambridge, discusses software obsolescence with host Priyanka Raghavan. They examine risks associated with software going obsolete and consider several examples of software obsolescence, including how it can affect cars. Prof. Anderson discusses policy and research in the area of obsolescence and suggests some ways to mitigate the risks, with special emphasis on software bills of materials. He describes future directions, including software policy and laws in the EU, and offers advice for software maintainers to hedge against risks of obsolescence.

Show Notes

• SE Radio 541: Jordan Harband and Donald Fischer on Securing the Supply Chain

• Episode 481 – Ipek Ozkaya on Managing Technical Debt

• Episode 535 – Dan Lorenc on Supply Chain Attacks

• Episode 538 – Roberto Di Cosmo on Archiving Public Software at Massive Scale

• Episode 489 – Sam Boyer on Package Management

• Security Engineering, 3rd Edition by Ross Anderson

• “Software Obsolescence – Complicating the Part and Technology Obsolescence Management Problem” by Peter Sandborn (IEEE Trans on Components and Packaging Technologies, 2007)

• The Restart Project.org Podcast: Software Obsolescence

• Strategies to the Prediction, Mitigation and Management of Product Obsolescence (O’Reilly)

• Key challenges in maintaining software obsolescence

Transcript

Transcript brought to you by IEEE Software magazine.

This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Priyanka Raghaven 00:00:16 Hello everyone, this is Priyanka Raghaven for Software Engineering Radio and today my guest is Ross Anderson, and we’ll be discussing software obsolescence. Professor Ross Anderson is a professor of security engineering at the Department of Computer Science and Engineering at the University of Cambridge, where he’s a part of the university’s security group. He’s also professor of security engineering at the University of Edinburgh. He’s an author of the book called Security Engineering, A Guide to Building Dependable Systems. And his areas of interests are security, dependability, and technology policy. I wanted to have him on the show to discuss software obsolescence after a very engaging conversation at his office at Cambridge University. And welcome to the show.

Ross Anderson 00:01:04 Thank you.

Priyanka Raghaven 00:01:06 At SE Radio, we’ve done a few shows on technical debt, managing software, supply chain attacks, a show on software archiving, but we’ve never done a full show on obsolescence. And the reason I wanted to do it was because of the fact that it’s hitting everyone now and very little attention is actually being paid to it. So, let’s just start right from the top for our listeners. Would you be able to explain what is obsolescence or end of software life?

Ross Anderson 00:01:35 Well, as time goes on, people add new features to software. The software features interact, you end up getting the dependability issues, you end up getting security vulnerabilities, and so the software has to be upgraded. And of course, no piece of software lives on its own nowadays. The artifacts with which we interact tend to have millions of lines of code, they talk to servers; the servers talk to apps. There’s a whole ecosystem at every node. And so, whenever you’ve got a new version of iOS or Android or Linux or whatever coming out, that has implications that ripple through the whole ecosystem. Similarly, when components such as web kit get upgraded that can ripple through many other parts of the system, and now we’re making things still more complicated by bringing in new types of components in the form of machine learning models, which will be embedded here, there, and everywhere.

Ross Anderson 00:02:30 And coordinating the disclosure of vulnerabilities, the upgrade to patch vulnerabilities, the upgrades that are necessary for dependability is becoming an ever more complex task. How this reflects in real life is that you may be tempted to go and buy a fridge for a bit more money because it’s advertised as a smart fridge, and it talks to Wi-Fi. And then two years later you find that the manufacturer doesn’t maintain the server anymore and it turns into a frosty brick. So, we find that artifacts that used to be good for 10 years or 20 years or 30 years suddenly become dysfunctional because the software that was built into them to support complex business models fails far before the underlying hardware does. And this is about to be a serious problem. For example, with cars. On the one hand, it’s great that we move to electric cars because an electric powertrain has got maybe a hundred components instead of the 2,000 components in an internal combustion engine powertrain.

Ross Anderson 00:03:35 So you don’t need to hire as many car mechanics, but there’s so much more software that you have to hire lots of software engineers to pick up the maintenance burden that has not been eliminated but merely shifted. This is going to have all sorts of political and economic effects worldwide. It’s great for India because there will be lots and lots of jobs for software maintenance engineers with the big tech companies in India and then many new startups. It’s perhaps less good for employment of skilled mechanics in north America and Western Europe. And over the next 20 years, all these implications are going to be working their way through the system, and it’s up to us as technologists to try and understand what’s going on, to try and figure out how we can make better tools to make software last longer, to figure out how we can perhaps redesign institutions so that we can do coordinated disclosure of vulnerabilities better. There’s a whole lot of pieces to solving this problem.

Priyanka Raghaven 00:04:33 I think, like you rightly said, it’s a maze and there’s a lot of things that need to be tied up in maintained. So, one of the questions I wanted to ask you, picking up from that is, when a software gets obsolete, does that mean nothing works or can it still be used with risks? And if you could just maybe talk a little bit about the risks, because there’s a case where you can actually work on things which are obsolete, but then of course there’s a lot of risks, associated risks.

Ross Anderson 00:05:00 Well, the question is whether the artifact that you’re trying to maintain was designed so that it would have a known death date or whether it would merely degrade. For example, my wife had a Lexus that was almost 20 years old, which we got rid of last year and replaced with a new car. But for all the time that she owned it, we couldn’t use the GPS because the GPS — the navigation and map display — was of a generation that was designed 25 years ago, and it had a strange popup screen that would show the moving map display, which still popped up annoyingly in the dashboard, but it depended entirely on getting a new DVD every year from Lexus with a new updated map of the whole world in it. And Lexus stopped supplying that about 10 years ago. So, here’s a car with a subsystem that was completely nonfunctional.

[...]

Original source

📄 IEEE_SoftwareObs.pdf

📄 ecp10077050.pdf