Choosing Security Tools: A consideration of open source, closed source, and services
Open source is a statement about community and user interaction, but many open-source projects use proprietary services to manage project security. This is not actually a contradiction: source code freedoms are orthogonal to the axis of control and convenience that stretches from self-hosted solutions to managed service platforms.
Open source tools are a great value-add for software teams that want to quickly and easily improve their development processes. Free tools exist for almost every possible need, from source control hosting (git, Gitea and GitLab), code review (Gerrit, GitLab and Gitea), dependency automation (renovate), bug tracking (Trac and Bugzilla) and even AI autocompletion (Code LLama) as well as a huge variety of smaller tools like linters, formatters, and testing tools. Despite this, many open source software teams choose to use proprietary development and security tools like Snyk, SonarCloud, Coverity, and CircleCI, even if the open source software is equally powerful and easy to use.
Self-Hosting and Managed Services
The answer, of course, is that these proprietary tools are offered as a Service: that is, that there is a team which is responsible for ensuring that the tools continue to work. Keeping a service working involves both fixing the inevitable infrastructure failures and affirmatively handling upgrade issues – issues that are often security-related. While self-hosted software is as powerful and flexible as software as a service, both open-source and commercial organizations lag behind on applying these security updates because it’s a job outside their core mission.
While it’s generally important to keep up to date with security updates on all tools, those updates are particularly critical for security-related tools such as vulnerability and package analysis tools, which may be responding not only to static rules, but also to changes in the threat landscape and to newly-discovered software risks.
Up till now, we’ve been contrasting open source and managed services, but a little thought should make it clear that open source and managed services are not intrinsically opposed forces. Projects like LetsEncrypt and Sigstore offer open source, public good instances: these take care of running the service as well as all of the bootstrapping costs that may be hard for an individual or organization to pay (managing certificate authority keys and trust is a great example of a cost that’s best paid by a specialized team). On the other side of the spectrum, there are open-source tools (like Renovate) which can easily be run in a serverless way using a tool like GitHub Actions – users are shielded from much of the complexity of running the tool, but are still responsible for upgrades and security fixes.
Services Graph
While open source is a philosophy about how users can contribute to a piece of software, services are much more transactional: do I get more value out of the tool than I put in? Ultimately, that’s what we want from most of our tools: a tool should be a useful and labor-saving device, even if it’s a tool we use when pursuing a hobby (and many open-source maintainers are not paid to contribute and are doing it for the love of the craft). Hobbies should be fun, and maintaining tools is rarely part of that fun.
If Services Matter, Why Open Source?
While most developers want services ready to hand while building and developing software, many also want to be able to take a hand in building the tools when it suits them. Having an open bug tracker and codebase allows developers who are already familiar with software to solve their own issues with tools that are familiar, and invites users to become part of the community and contribute. Open source is an “open” sign in the window encouraging folks to come in and make themselves at home.
No matter the size of the team providing a service, demand for features, documentation, and bug fixes will always outstrip the capacity of the team. Open source provides developers a way to “vote with their time” on items that are important to them by rolling up their sleeves and volunteering to implement features or fixes they need. Sending a Pull Request to implement a feature is a bit like offering the project a free pony – all they need to do is review the changes and commit to keeping the feature up to date after it’s merged. And, like a free pony, they may also push back and say “this isn’t the right home”, and the author can choose whether to maintain the fork, donate the work elsewhere, or let the code go free.
The “fork” option with open source highlights a second major benefit of open source – if the original project authors can no longer keep up with the project, you at least get to keep all the pieces. Long term, if you keep depending on the source, you probably want to fork the code and ensure that it’s maintained and security patched, but at least the option is available. If you were using a proprietary service and the entity behind it disappears, you may not have the option to keep running it on your own dime.
Lastly, open source software provides a guarantee that the source code is available for review and audit. While it’s not clear that “with enough eyes, all bugs are shallow”, open source at least gives users a chance to audit and review the application code and share their findings with others. Users who are sufficiently engaged in the project can even influence the direction of code, contributing fuzzing tests or doing other security-related work like dependency audits. While not everyone will have the ability to contribute at this level, projects like Kubernetes and Sigstore have benefited from public and published security audits which benefit all users. Being able to point service users to the service’s source code (and build attestations) is a powerful statement of application security.
Open Source Is A Service
With all the discussion about open source using managed services, it’s easy to forget that open source maintainers are themselves providing a valuable ongoing service every time that they address a security issue, release a patch, or review a PR that adds tests to their existing package. The world relies on open source being stable, secure, and constantly-updated. While the service provided by maintainers may not have a published API, a pricing sheet, or rate-limits to prevent abuse, the software they update and secure is critical for all the software that exists around us.
At the end of the day, application security depends on open source maintainers having the resources necessary to fix, patch, and improve their components. Supply chain security is a critical security lens for software projects, but so too is test coverage, vulnerability management, and development patterns. Many of these aren’t things that maintainers love to build, but are a “cost of doing business” in order to spend time building and sharing the software they love.
Conclusion
At Stacklok, we strongly believe in open-source, but we also believe that most developers want services they can rely on and trust rather than additional tasks to keep pace with user expectations. The sigstore model of open-source software operated as a public good instance is compelling, which is why we’re continuing to contribute to Sigstore’s operations.
