Following Log4j: Supporting the developer community to secure IT
How bad was the Log4j vulnerability for open source’s reputation? One of the most high-profile exploits in recent years, it even led to a government advisory from the UK’s National Cyber Security Center being issued after Iranian state hackers took advantage of it. It’s hard to say just how much impact this incident had, but a recent report from VMware found that one in ten companies say they will no longer use open-source software.
This will be a tough rule to make stick—open-source software and the communities that support it are essential to modern IT, and so highly unlikely that the reliance on open-source projects will reduce. While some security teams are beginning to assess their own open-source security by implementing SBOMs, many businesses are considering ditching open-source software altogether. Instead of reluctantly using open source and blaming developers when something goes wrong, businesses should be working with the open-source community with the aim of improving security and working to minimize the fallout from the next vulnerability.
A dedicated community
Open source isn’t about being able to provide quick fixes for developers; it’s a dynamic community that’s there to help businesses and people solve problems. Unfortunately, open source gets a bad rap, as it is seen as populated by hobbyist. This is made worse by the unearthing of vulnerabilities that can affect businesses across the globe (e.g., Log4Shell). Log4j’s vulnerability has highlighted just how much modern software relies on open-source projects and what can go wrong when a major vulnerability is discovered.
Open-source projects are everywhere, meaning there is no quick fix to the problem of open-source security. The developers and maintainers of Log4j are a team at the nonprofit Apache Software Foundation, made up of just 16 unpaid volunteers distributed all over the world. Their motivation isn’t fame or profit, they do this because they have a passion for writing software and solving problems in their free time. Following the incident, the team dedicated weekends of unpaid hours to make sure patches were available to keep businesses safe. Outside of this one group, developers and security teams globally also worked endless hours to make sure their own code was protected and patched. But the issue could have been discovered and fixed well beforehand if the team had enjoyed even a fraction of this level of support.
The Log4j vulnerability was so devastating because it touched so many different applications. The lesson for CSOs isn’t that open source lacks security but rather that they should have a greater appreciation for the developer community and ask themselves how they can support the development of open source to the extent that when the next vulnerability appears, the time to deliver patches is as short as possible.
How can businesses help?
Developers are not going to stop using open source resources and it would be foolish to expect in-house developers to start writing tools from scratch, especially as developers are such a scarce resource. Open-source tools will remain a key resource for the future of web development. Instead of thinking about redeveloping tools to remove open-source elements, businesses should instead support the future of open-source projects and encourage a focus on security. This is how:
1. Invest in the community: Many free open-source projects are managed by a single person with a few interested community members. Companies looking for talent can employ these lead developers and aid them in setting up their own foundation which is an investment in the software’s overall lifetime. Where this isn’t possible businesses can otherwise make wider contributions such as investing in conferences and access to hardware for different developer groups. Ultimately this helps in strengthening the community by giving them access to tools and resources that will provide greater innovation on future projects.
2. Commission improvements: If a business is highly dependent on an open-source solution, then it has some responsibility to contribute to its success and invest in ways to improve it. This could be a missing feature or an opportunity to improve it. Businesses can implement bug bounty programs to identify any vulnerabilities in their software, but they can also commission improvements from the open-source developers. Paying to improve open-source software is not incompatible with its ethos if it remains open source. This is especially important if security upgrades are needed.
3. Promote projects: Open-source projects don’t function the same as commercial products. They don’t have marketing or any budget behind them. However, if a business promotes a particular set of open-source solutions, this helps raise awareness for the tools, both internally and externally. It also encourages people to share their own experiences and contribute to the overall community—possibly even contributing to projects.
4. Work more collaboratively: If there is a tool that a business is heavily reliant on, it should make its own contributions to the software or encourage staff to engage with the community directly. This can be via sponsoring developers to network at open-source conferences or encouraging them to work with open-source communities directly. This gives a business more oversight into the tools that it’s using as well as more powers to encourage security or other applications. At all times, it’s important to remain collaborative, no matter how much is contributed.
In addition to benefiting the business, open-source engagement improves developer morale and performance. It shows that their work has meaning and value. Too often lead developers abandon projects because of the workload, drama, and discord. Why would a developer want to spend time away from friends and family to do something that nobody thanks them for? By providing tangible support it not only improves the overall work environment but also keeps developers motivated.
Open source security will remain a hot topic for many—after all, developers are still patching the Log4j vulnerability. But instead of looking for alternatives to open source, we should instead be working with open source—collaborating with the community means businesses get all the benefits of open source software, support a valuable resource, and know that they are secure.