Software Development is Stuck
As an industry, we are building systems and frameworks for software developers to use at a frenzied pace - more so now than at any other time since the invention of the personal computer. Every day, there is a new framework, product, project, or general murmuring around some advancement in software development. Look at NPM (Node Package Manager); you will see more than 1M packages. Then we have the ecosystems around Python, .NET, Java, and the growing Rust community. We won’t even touch generative AI.
All of these libraries equate to more and more plumbing enabling product teams to move fast because they are leveraging such a significant amount of prebuilt functionality.
But the cost is coming.
Our world's security threats grow daily, and supply chain attacks grow. Have you already forgotten about Equifax, SolarWinds, or the Log4J attacks? This fast iterative approach to pushing new software products is starting to have real-world effects, and not just for complex industries, but for everyone because the code that is in a product today is shrouded in a secrecy of dependencies.
What is worse, a commercial vendor saying their libraries are confidential, or 327 build dependencies to construct a web app? This product now ships 327 components of unknown origin. And any of these dependencies can change anytime - and the development team has no idea. Maybe some of these components have lines inserted from foreign actors?
Why does the development team not have a clue?
Because that's the intention of these large package managers and build systems - to abstract away and hide the complexity of building software. This is the supply chain of software, and it's one of the most dangerous parts of the modern software product development process.
The only difference between this ship,
And this ship,
Recommended by LinkedIn
Is the intent.
Let's look at how these problems come into play.
Our industry has a hard time telling the truth. The truth is that most "product development" is some type of maintenance, or small feature development, on existing products. One doesn't need to discover and connect with users when the software offered is built into customers' internal workstreams. This type of development, though most of the activity, has a risk because the eyeballs and systems monitoring the code is less stringent than the big, new, shiny, go-to-market product coming down the pipeline. Whom are bad actors going to attack? The product under the spotlight, or the tech systems sitting in the shadows. Hackers aren't as distracted by shiny objects as product development teams.
These distinctions are important because customers need what they pay us for, to work all the time, securely, and not be slow. Here, I didn't even say fast. Fast is for new products, with new expectations and market competition. Customers (businesses in the context of this writing) say they want fast and unique. Still, when the board pushes back and the Wall Street Journal is covered in articles about foreign government and private group hacking attacks, they will opt for a solution that is secure, stable, and fast enough. Corporate boards aren’t end users, and decisions for mission-critical systems are hardly ever organic.
And it gets worse
The software industry will continue to suffer as security and reliability are traded for arbitrary development cycles and pressure to hit artificial deadlines. It's the same today as it was 20 years ago. Agile railed against fixed timelines. But the next generation of people who picked up the original Agile ethos weaponized the concepts into big business for themselves, replacing a two-year timeline with 48, 2-week sprints - when the two are the same thing!
Security and unreasonable development cycles are also why doing business with smaller companies is becoming more challenging. Having certifications is helpful, but trust will still be questionable. Does this company follow its SOC or ISO compliance certifications? It's fair to wonder if a four-year-old company, growing and turning over people, can maintain its HIPPA compliance when so many people are transitory or their primary concern is survival. Desperation leads to unintended consequences.
Conclusion
We are a heavily constrained industry by time and cost, and this will only become harder as the required security demands grow. There is only so much of the security monitoring toolchain which can be automated before that is attacked as well. Finally, consider this proposition, how can you move faster by implementing more "secure" libraries if you don't own the code in those libraries? It's turtles all the way down!
These are the topics that matter. Who can get to market fast and securely when those two concepts are a dichotomy? Nailing these challenges down is what sells enterprise systems.
Great piece. I have always said that much of what we do in technology is manage (and hopefully reduce) complexity. Part of the issue comes from the fact that for many developers, software development - no matter what the task - starts with the words, "Let's use [insert third-party library here]". Another part, is that the main current in the corporate ocean is to build features/add functionality, etc.. Maintenance is like a call center in a company - it doesn't bring in income, it is an expense. "We need to upgrade/fix/maintain" is something that is usually said by those of us who work in the bowels of the ship. Maintenance and security, which go hand-in-hand, are two of the most important things in technology.
Truth! Great article Stephen. Another issue we see are teams constantly jumping to new and better frameworks, but often don’t clean up the old ones. So they have the old, the new, and the new-new. A maintenance and security nightmare. I also attribute a lot of insecure development and design to the “MVP”. The concept of the MVP is good, but often leads to security controls getting deferred or left behind.
Thank you for stating this in no uncertain terms: "Our industry has a hard time telling the truth." Just like extracting that SUV, our industry can be fixed, but some of the trim and other mechanical parts will wind up being broken, and subsequently replaced, in the process. But, what sadly is needed more, is a change in "driver" so that we don't wind up becoming "stuck" again. How many C-levels and Wall Street shareholders will be willing to admit that they're part of the problem? Few, if any. An so the blame will be forever passed down to us "doers", who have been backed into a corner, overworked, and over stressed. I fear that the next "big news" will not be how many attacks a company prevented by their security policies, but that an even bigger incident than those mentioned will happen.