2/20/2021

Why (not) trust open-source software with data

3 min read
Share

To trust or not to trust open-source software, that’s the question. It’s open-source. Everybody can check the code where the data goes. Does that mean that the OSS is more trustable? It is, and yet, it is not.

Why should you care about security?

Well, if you have to ask, something terrible must have happened in your learning process of software development. If you are a newbie, let’s talk about it a little.

You don’t want your data to leak — especially the client’s data. If someone with bad intentions gets to your code, it can end with stealing your code, or even worse, stealing your credentials and your whole account.

When to beware

Imagine you want to use some OSS tool that requires some of your credentials — e.g., access token to your repository. Some indicators, it might not be the best idea to provide your AT, are below.

You should pay attention when:

  • The last commit was more than 3 months ago. It indicates no one cares about the project anymore. The problem doesn’t have to be the project itself, but the problem can be the dependencies with deprecated versions.
  • It's a brand new repository without history. Nobody has most likely checked the repository yet.
  • It has a small number of stars (when talking about GitHub repositories). This doesn’t have to reflect the quality of the code or the project. But be careful.

Would you trust the tool just because it’s open-source? I don’t think so. But it’s much more trustable than any other software. BUT only if it’s updated, so the developers try to mitigate the security risks. I don’t think anyone relies on the fact that since the tool is open source then anyone can check it, so I don’t need to.

When to calm down

You really want to use the tool, but you don’t have time to review the code? What are the indicators that it’s secure to provide your AT?

The code could be safe when:

  • The OSS is maintained. There are commits in the last 3 months, and there are no Pull Requests older than 3 months without any answer.
  • There are many users. You can follow the number of stars or the number of downloads.
  • It's a well-known company. It’s not necessarily the most secure app in the world, but you can be quite sure they don’t want to be discredited due to poor security measures.

How to make the OSS more trustable

You have an OSS tool, but you don’t have many stars, or it’s brand new. You still want the users to trust your code. The tool is well maintained, it’s quite large, but you’re not known in the community, and the number of users is insignificant. How to make potential users trust your code? That’s the question we had to ask ourselves since we develop an OSS tool that exactly fulfills this. Why should new users trust us? Or you, if you have the same problem?

Tell your users what the credentials are used for!

It’s been quite a while since we started developing DX Scanner — an open-source CLI tool that allows you to measure Developer Experience directly based on your source code. We know our software is secure and doesn’t collect any user data. But we totally forgot to tell the users!

Write down what data you collect and possibly send (if allowed by the user).

Some of our colleagues, who don’t participate in DX Scanner’s development, told us they trust the security of our product just because they know us. We took this notice seriously and realized that we should write down the article about (not) collecting data in our open-source tool.

Conclusion

If you're on the user side: An open-source tool doesn’t mean a secure tool. Always check the software that requires your credentials.

If you're on the developer side: Knowing that you build your software responsibly and securely doesn’t mean your potential users know it. Give the users a reason to trust you.

We wrote down the article on how we (not) collect data. Check it here.

Author
Prokop Simek
Prokop Simek
CEO

With more than 12 years in software engineering, I use my expertise to link business and technology for our clients.