Home Cd rom How to Avoid an Open Source Security Nightmare

How to Avoid an Open Source Security Nightmare


There have been some high-profile security issues with open source software. A disgruntled developer recently shipped intentionally modified versions of his faker.js and colors.js packages, which broke “thousands of projects” that depended on them. Some wonder if it is safe to use open source software. The White House certainly is — they’ve asked big tech companies to comment on software security following the Log4j issue, which exposed countless servers to remote exploitation.

Is code written by volunteers less secure than code written by professional developers? Do you need someone to sue if a product fails? Are you really getting your money’s worth?

What is Open Source?

Just as it would be a mistake to say that all open source projects are bug-free, it is a mistake to say that all open source projects have security risks. Different projects have different goals; some of them are much more concerned about the safety of their releases.

Josh Berkus identified five types of open source projects based on their structure:

  • A solo project is the passion of an individual or, at most, of a few dedicated people with the same vision.

  • A the monarchy is a successful Linux-like solo project that has gained the support of a large community of contributors, so the original creator acts like a benevolent tyrant.

  • A community project such as PostgreSQL arises among peers with a similar goal and is driven by consensus.

  • A corporate The project is often released as a fork of a commercial project, such as when Sun released OpenOffice as an open source fork of StarOffice. Its direction is guided by the company that published it.

  • A foundation, the most formal, is a self-contained enterprise structure – of which Apache is perhaps the best example. There, a steering committee makes the decisions.

In general, solo projects are the most exposed to security risks. Just as a writer can update their webpage with any content, a solo developer can update their code the same way. Often there is not enough interest in a community to forge solo projects, so they become de facto standards. We saw it with faker.js and colors.js, when Marak Squires modified his code to print flags and enter infinite loops.

The security of open source and closed projects depends on the orientation of their contributors rather than their structure. We were lucky that Linus Torvalds made safety one of his concerns. Theo de Raadt, has been aware of OpenBSD security from the beginning. In contrast, StarOffice (commercial) and OpenOffice had security vulnerabilities that allowed remote execution of arbitrary code in XML documents.

Many eyes focused elsewhere?

One of the ironies of open source is the assumption that many eyes improve security. For years we’ve heard claims that open source was safer because “the community” could review the code. The problem: “The community” rarely reviews the code, and everyone assumes that someone else does. This false sense of security really exploded during Heartbleed – the reality of too much code and too few eyes means we need better processes and automation to improve open source security.

There’s another false sense of security, though: don’t assume that closed-source software has better processes just because you can’t see them. In the case of Heartbleed, “the community” finally looked into OpenSSL flaws, and the solution was… more open source. LibreSSL, a fork of OpenSSL, emphasized security rather than backwards compatibility.

Open source requires shared responsibility

Even if you don’t pay money when you use open source software, that doesn’t mean you don’t have obligations — to your business, to your customers, and to the community. Be responsible when using open source software:

  • Know what you are using. One of the biggest dangers of some ecosystems is the ease with which one open source project can include another. Many projects today include other projects as components. Systems like npm make it easy to embed code without realizing it. Tools exist to help you generate software bills of materials (SBOMs) and analyze your code to see if you’re depending on something you didn’t know about.

  • Avoid solo and abandoned projects. A single malicious developer can inject a lot of harm, especially if you upgrade automatically. The danger of using abandoned projects is that they may not account for modern vulnerabilities. Assess the status of the projects you use with each release.

  • Test before publishing. Much of the danger with open source projects comes from upgrading without testing. If your code includes an open source library with an exploit, your users will hold you accountable. Certify with specific versions of projects and keep them up to date. Fork the open source libraries you use and dedicate resources to reviewing what has been validated.

  • Schedule updates. The Log4j vulnerability was particularly dangerous because it allowed the execution of arbitrary code on platforms with software embedded in ROM. For some IoT devices, there is no way to upgrade the Log4j library to fix it. This leaves a lingering vulnerability that cannot be fixed. Don’t put your product in the same situation. Provide an upgrade (and downgrade!) path for each component. Don’t wait for a security issue to update your code either – plan to update regularly to newer versions to improve the hygiene of your code.

  • Contribute to open source projects. Many open source projects provide useful code with few resources. Commit to contributing financially or by providing development or QA resources to the open source libraries you use. Don’t limit your open source contributions to the day you release the library — open source needs continued support, so include open source contributions in your annual budget and long-term planning. You want to make sure the latest version is as secure as the one you pulled first.

  • Invest in DevSecOps. Suppose frequent updates are the norm and not the exception. Whether it’s code created by your own team or code you’ve contributed from an open source project, be aware that bugs will occur, updates will be required, and in some cases rapid iteration will be needed to keep up with the changes. DevOps, in the form of CI/CD, is now table stakes; raise the bar by adding “Sec” – the ability to pass automated security checks left directly into the development cycle so that when those updates arrive you’re better prepared to release the patch with fewer sleepless nights and lots of less work and stress.

Wake up from the nightmare

If you’re afraid to use open source, it’s too late. You are unlikely to use a product today without open source components. It is almost certain that you are reading this with a browser based on open source technology, served by a web server with an open source kernel, all built with open source tools. Although a nightmare is not a reality, it can be a response to legitimate anxiety. Use open source software responsibly to avoid goosebumps.

This post was written by Senior Analyst Andrew Cornwall and it originally appeared here.