In one of my favorite episodes of the original Star Trek series, the main characters are forced to re-enact a surrealistic version of the gunfight at the OK Corral. Ensign Chekov, who is accustomed to using a phaser, brashly remarks that if someone shoots at him with an old-fashioned revolver, he will simply step out of the way. Soon afterward, he is "killed" by a simulated gunman. Chekov learns the hard way that just because something is old or obsolete doesn't mean it's not dangerous.
Today, in the real world, we’re learning similar lessons. For example, firmware that's written in older programming languages like C may pose risks that aren’t directly addressed by newer software supply chain security processes.
I’m thinking specifically of the software bill of materials (SBOM), which was conceived for the purpose of listing components and revealing vulnerabilities in software and firmware products. When you’re analyzing code written in newer programming languages such as C# and Python, SBOMs are wonderful. But they’re not so wonderful when you’re analyzing code written in older languages.
"It's very hard to represent components in SBOMs for firmware written in C/C++," says software supply chain security expert Tom Alrich, the author of Introduction to SBOM and VEX.
Why is this a problem? Because much of the firmware in critical infrastructure (e.g., dams, water treatment plants, electricity grids, nuclear power stations and transportation systems) are programmed in those older languages. SBOMs work like X-ray vision to show you what’s “inside” the software. But the tools used to generate SBOMs work best on products written in newer languages. If you’re trying to determine the vulnerabilities in a piece of equipment that was programmed 15 or 20 years ago, SBOMs won’t be nearly as helpful.
“Writing in higher-level languages like Python is quick and easy, and there are lots of tools to help you through the steps in the software development lifecycle,” says Michael Scott, CTO and co-founder of NetRise, a company specializing in firmware component analysis. “Older code doesn’t have that kind of ecosystem. But older code is what’s running on our most critical infrastructure.”
In other words, the code running on your exercise app is probably more secure than the code running at your local electric power station. For Scott, who served in the U.S. Marine Corps Cyber Warfare Group and the Marine Corps Forces Cyberspace Command, prioritizing security issues in newer devices “misses the heart of the matter.”
Indeed, a recent report by the White House Office of the National Cyber Director (ONCD) calls “on the technical community to proactively reduce the attack surface in cyberspace” and “prevent entire classes of vulnerabilities from entering the digital ecosystem by adopting memory safe programming languages.” The ONCD’s report, titled Back to the Building Blocks: A Path Toward Secure and Measurable Software, definitely leans toward the future, which is admirable. Here’s a snippet from the report:
"Memory safety vulnerabilities are a class of vulnerability affecting how memory can be accessed, written, allocated, or deallocated in unintended ways. Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++. Choosing to use memory safe programming languages at the outset, as recommended by the Cybersecurity and Infrastructure Security Agency’s (CISA) Open-Source Software Security Roadmap is one example of developing software in a secure-by-design manner."
All well and good. But it seems likely that downplaying problems caused by older code would only lead to more problems down the road. A recent article in the Wall Street Journal cites a report by the Consortium for Information & Software Quality (CISQ) estimating “that the cost of poor software quality in the U.S. has grown to at least $2.41 trillion.” Essentially, insecure code is a deadweight on our economy, a form of debt that we pass along from one generation to the next.
It’s probably true that memory safe programming languages are the key to a better and safer future. But that leaves us grumbling over how to deal with safety and security issues in the present moment. “What's the point of having an SBOM if I can't dig into the firmware image and assess its security?” asks Terry Dunlap, a convicted hacker who subsequently worked for the U.S. National Security Agency and now trains cybersecurity professionals. “I think this points to a deficiency in the whole SBOM process. If it's relying primarily on package manifests and package manager data, which can be manipulated, then how do you know the data is actually the way it was intended from the manufacturer? Do we know if anybody messed with it in transit? We don't know.”
Clearly, we’re in the midst of a deep and wide conversation. As much as we would like to, we cannot simply focus on the future and forget the past. Even technology must play by the rules.
I opened this post with a reference to Star Trek and I’ll close with a quote from The Great Gatsby: “So we beat on, boats against the current, borne back ceaselessly into the past.”
To be continued!