The Security Risks of Forking

One of the biggest controversies we’ve recently seen in the DevOps space — the HashiCorp license change from MPL to BSL — has raised a few questions not only from the open source community, but from security professionals about software supply chain.

👁 Image

Many are now wondering how to proceed with third-party dependencies that are not hosted by a foundation (such as the Linux Foundation or Apache Software Foundation), no matter how popular the tooling. It’s becoming apparent that this can be quite risky from numerous perspectives.

Many high-profile people from the global DevOps and cloud native community have expressed concern, including Kelsey Hightower:

👁 Image

While there has been much focus on the business side of it, and even a major fork in progress in the form of OpenTF, there is little discussion around the security questions that this move raises. In this post we’ll look at the security aspects of this change and what you need to keep in mind when building your software supply chain.

On Security Implications and OSS License Changes

First and foremost, we should start by thinking about the security risks of leveraging public-facing resources — this can be anything from containers on public registries to popular open source projects. (This Slim.AI state of container security report looks at some of these risks). However, when talking about forks of popular open source projects, we need to keep in mind that these can introduce security vulnerabilities, especially if they are not maintained at the same level as the original project.

While many times the intentions behind those forking the project are good, with the goal to help preserve the open source values and fundamentals of the original project, it’s hard to know in advance if those who have forked the project will be as committed to security as the original creators of the code. In this case HashiCorp has a proven track record in security as well as DevOps, as they are also creators of the widely adopted Vault project, has also made leading folks in the industry, like Akeyless CEO Oded Hareven, question why this project is not as widely debated as Terraform. It is yet to be seen if the new maintainers will have the same level of security expertise.

The OpenSearch fork that came following the Elastic license change is a good example of a project that has gained quite a following and due to a corporate sponsor (in this case AWS), have managed to build the trust the community requires for companies to be able to confidently adopt it.

Takeaways: Companies choosing to adopt forks of popular open source projects need to do  proper due diligence on the intended maintainers to ensure the project will retain the same security hygiene as the original creators of the project. At the end of the day, while it is possible to contribute patches and code to open source projects, this highly depends on the level of commitment from the maintainers to actually merge them. If they don’t patch or upgrade vulnerable versions, you are left with security risks that are out of your control. A good practice to vet the commitment to security posture is by taking the time to research who is behind the fork and whether they have the same security track record and update frequency as the original creators.

Maintaining an Up-to-Date Software Bill of Materials (SBOM)

With the license change, HashiCorp’s products will now have different terms of use. The need for an SBOM (software bill of materials) has gained widespread validation, particularly after the Biden Administration’s announcement that they will only work with software that maintains an up-to-date SBOM.  This is because an SBOM provides a “nutrition label” for software — and one of the critical things it includes are the licensing details of the diversity of software in your stack.

Therefore, it’s not enough for the license to change, it also needs to be reflected in your SBOM, which is crucial for risk assessment and compliance. We have spoken extensively about compliance processes and how they need a hard reset and how they often bog down engineering teams when they aren’t done right. Imagine completing rigorous compliance processes only to discover that your compliance is in jeopardy due to license changes that are not properly reflected in your SBOM.

Takeaways: If you know of a significant license change in your software stack, be proactive about updating your SBOMs to ensure that they are still in compliance with the standards and regulations your company is required to comply with from a business perspective.  Do a proper risk assessment in such situations to ensure this doesn’t expose you to any business or security risk.

Change Management and Security

At the end of the day, licensing changes can bring with them the need to qualify and then adopt new alternate tooling that the company deems safer or more cost effective.  These processes can result in modifications to software code, CI/CD, processes, integrations and much more. Like any new change management process, we need to make sure we consider all the security implications when adopting and migrating to new software.

Aside from the technical aspects of ensuring a secure migration of data, and configurations, there are also more functional and process-oriented aspects we need to consider. In this case, Terraform has been considered a mission-critical application that touches many parts of our applications, networking and infrastructure. Ensuring it is properly uninstalled and offboarded from your organization and all of your stacks, and its permissions revoked, are equally as important as secure installation of new tooling.

Takeaways: Don’t forget the end-to-end security hygiene of adopting new tooling and uninstalling old tooling when it comes to proper and secure change management processes. This is especially true with software that has a wide reach in our systems; mapping these with a proper inventory is critical to ensure no machines or systems are left with the unwanted (and in the future likely unmaintained) software installed.

Commercial vs. Open Source from a Security Lens

The choice to adopt commercial verses open source tooling comes with pros and cons for each. While commercial software comes with more restrictive licenses, less customizability and a dependence on the vendor to keep your software up to date and competitive, open source tools provide the code transparency and customizability many organizations today require. As many have said, just because you can’t see the code doesn’t mean it’s more secure — and we all know that open source is not a silver bullet either.

Commercial software, due to its cost and need to satisfy customers, usually has a much more stringent commitment and SLA to better support security updates and patches, where with open source it is largely best effort and dependent upon the core maintainers of the projects (as noted above). That said, the openness and visibility enable the intelligence of the masses and the ability to discover vulnerabilities earlier, and even patch them faster with a committed team, due to the ability to tap into the larger community. We believe that teams should be able to choose their own tools; that is why DevSecOps orchestration of both commercial and open source tooling is critical for security tooling to adapt to developer workflows.

Takeaways: Your choice as an organization when selecting commercial or open source technology to power your stacks comes down to your appetite for risk, and ability to support the projects you leverage in your code and stacks, in the event an urgent patch is required. Remember that though you can’t see the code doesn’t necessarily mean it’s more secure. However, seeing the code and knowing it has vulnerabilities that aren’t being patched in a timely enough manner can be equally distressing.

What We’ve Learned

It’s impossible to write and maintain all the code required to power modern application stacks. It makes sense to leverage great third-party tooling that is well maintained and not have to reinvent the wheel when it comes to technical problems that are already solved. That said, when we choose to leverage software that we haven’t written ourselves and do not maintain, it comes with its own set of risks.

These can be from a business perspective and the implications of a licensing change in a critical piece of software that can put your compliance programs in jeopardy, or to software that isn’t well maintained and puts your systems at risk. Like all security programs, it’s important to do the proper risk assessment and management when adopting any new tool to your stack to ensure that you are doing your best to keep your software and users as safe as possible. While these types of scenarios are out of our control, we do need to always have a security plan B in place, with proper change management procedures to ensure we prioritize the security of our systems above all else.