Every piece of software we use requires some degree of trust. Whether it’s a content management system, an office suite, or an operating system – each app we install is a small leap of faith.
We have to trust, for example, that it’s secure, respects our privacy, and works as expected. In other words: we need to believe that the developer has created an app with good intentions and that using it won’t result in any intentional harm.
That belief is tested daily. Security flaws, malicious attacks, and all manner of bugs pose huge challenges. And so much of an app’s reputation depends on how the developer responds to these crises.
But as we are seeing more frequently, trust isn’t solely dependent on an app’s primary developer. That responsibility also spreads to any third-party scripts and libraries their product utilizes.
One prime example is the Log4j vulnerability. A flaw in this popular logging library from Apache made it possible for an actor to arbitrarily run malicious code. Its effects could be devastating.
As if this weren’t bad enough, patching the vulnerability became incredibly complex due to how many other apps and service providers utilize Log4j. This meant that each app had to upgrade its copy of the library, then distribute the fix to users. The process has to repeat again and again.
For web designers, this hits home on several levels. We put our trust into many apps (particularly open-source). And many have third-party dependencies. It puts us and our clients at risk.
Let’s take a deeper look at the issue and what web designers can do to stay safe.
Open-Source Software Is of Special Concern
The saga of Log4j has opened up a proverbial can of worms regarding open-source software in particular. In the United States, the White House held a meeting with top tech firms regarding the security of widely-used foundational software that is maintained by volunteers.
Popular examples include WordPress, Node.js, React Native, and OpenSSL. Beyond that, Google has published a list of over 100,000 projects that are deemed “critical”. They’re relied on by everyone from governments, corporations, educational institutions – right down to personal and small business websites.
This does not mean that any of the items on the list are inherently insecure. Rather, it’s a measure of the potential impact a security flaw could have. As the OpenSSF Securing Critical Projects Working Group (WG) states:
“For our purposes, a critical OSS (open-source software) project is an OSS project that can have an especially large impact if it has a significant unintentional vulnerability, or if it is subverted in either its source repository or distribution package(s).”
Volunteers and Limited Resources
To state the obvious, security holes are not limited to open-source software. Big proprietary projects from the likes of Apple, Microsoft, and other behemoths of tech also have their fair share.
The difference is that these companies have the resources to ensure any issues, once discovered, are promptly fixed. Projects that rely on volunteers may not have such luxuries. Some may need to scramble to find someone knowledgeable who can take appropriate action in a timely manner.
And if a project is no longer maintained? It places a huge target on anyone using that software – whether they know it or not.
The beauty of these projects is that their volunteers are incredibly dedicated. We’ve often saluted those who work behind the scenes of WordPress, for example. The willingness of people to contribute their time and talents is a wonderful thing.
But as Morten Rand-Hendriksen points out, some major systemic issues need to be addressed:
“We are acting as if these are still little hobby projects we’re hacking away at in our parents basements. In reality, they are mission-critical, often at government levels, and what got us here is no longer sufficient to get us anywhere but chaos.”
It’s admirable that a group of people, no matter how small or far-flung, can build an app that makes an impact on the world. But there are no assurances that the project will be sustainable over the long term. That can be problematic.
What Can Web Designers Do?
As web designers, we are in an awkward position. So much of what we do these days relies on open-source projects. And we reap the benefits of them every day.
The good news is that none of the issues outlined above means we have to abandon open source – nor should we. There is too much value in simply turning our backs on our favorite projects. If enough of us did so, that would likely make the situation worse.
Instead, we should carefully consider the apps we are using. Gain an understanding of the project, who’s involved, and the challenges they face. Look at its reputation within the industry and its longevity. Examine its changelog and see how often updates are released. Consider volunteering your time if you are able.
It’s also important to look at which third-party dependencies are associated with a project. This can be difficult to discern, but worth the effort.
Then there’s the role of service providers such as web hosts and APIs. They are additional links in this chain. Because, even if we’re certain that an app we installed is safe, we also need to rely on these providers to maintain their systems as well. Monitor them as best you can and don’t be afraid to ask questions.
Placing blind trust in software is not a wise choice. And while it may feel nearly impossible to keep up with all of this, it’s now a necessary part of the job.
Truthfully, we won’t be able to catch every issue before it becomes something bigger. But we can keep an ear to the ground and be proactive about the software we’re using.
The post Why It’s Getting Harder to Trust the Software We Use appeared first on Speckyboy Design Magazine.
0 Commentaires