For many business leaders, this past month’s discovery of a security flaw in an open source software tool called Log4j Shell probably elicited little more than a shrug at first. After all, this was a concern for software teams and your people surely had it under control.
Then the reports started rolling in. Hackers were able to execute 100 attacks a minute by exploiting this hole. And it wasn’t just obscure companies or single brands at risk. Nearly everyone seemed to be impacted – governments at all levels and big brands like Apple, Cisco, IBM, Google, Minecraft, and many more.
How could a weirdly named logging library have such far-reaching implications?
The truth is that nobody really pays attention to all the libraries included in a piece of software. Especially for open source solutions. Modern build tools like Maven, Gradle and NPM automatically match a software team’s short list of needs against the wider tier of libraries that support them, the even wider next tier that supports those libraries, and so on.
Ultimately, hundreds of libraries can end up in a final build and software teams have limited motivation or ability to chase down all known security flaws because these are automated connections and tinkering with it could cause problems.
But for all the software teams and their wider organizational leaders suddenly dealing with the unanticipated fallout from Log4J Shell – a piece of software they might not have even realized was within their architecture, it raises uncomfortable questions.
As a business or executive team leader, how do you limit exposure from these types of tools and builds? How do you gain better visibility into what tools your teams are using? How do you contain this specific security hole? How should your team be preparing and building a plan of action for future security risks?
We’re here to help.
Chariot Solutions is a leader in open source software builds. Our team recommends three basic best practices to help your organization react quickly and decisively to the next inevitable security concern.
- When creating system builds, be aggressive about hunting down secure versions up-front and ensuring they work together. It will require more effort at first but will significantly limit your exposure once you’re operational.
- Catalog all the dependent libraries within your system tiers that are part of the overall build. This creates an easy reference list or manifest if unexpected issues or flaws like Log4J do arise later. It also avoids the sometimes impossible task of “rebuilding” a list after the fact.
- Sign up for and track vulnerability alerts, then ensure that your team is regularly monitoring them against your software manifest. Automate this with a tool if possible.
Putting in the effort as you design and execute your build now will remove any uncertainty when future security bulletins are issued. It will also significantly reduce the amount of time needed to fashion any needed responses.
There is no way to foresee every security emergency. But when every minute of a delay literally translates into dollars lost, having a plan in place delivers peace of mind.