Open Source Security Approaches You Should Know

Introduction

The rise of usage and adaptation of open source technologies in many organizations across sectors shows results. IT leaders had led their organizations to embrace open source, busting the myths and fears about open source that cropped up when the technology first came out.

On the other hand, however, the agility of open source did not come without its own set of security challenges, which provided many organizations and IT practitioners with another opportunity.

Source

Before we dive into security approaches, I'd like to describe why organizations adopted open source.

Here are some of the reasons:

• Community-driven and open source software are more likely to have faster development timelines.
• Using open-source software works out cheaper than creating and maintaining proprietary software.
• Popular open-source software can give you excellent technical support.
• They remove the frustrations of vendor lock-in.

Open Source Security is a Different Game

If your organization is in the experimental part or has just started embracing the use of open source technologies, you have probably wondered: "How can we secure this?"

Good question! However, it is much better to first appreciate the benefits of open source before answering that question.

Just remember that where there are challenges, there are available solutions. But, to manage open source applications, we need to understand their underlying risks.

Once we have decent awareness, we can help our organization wisely choose the tools and strategies needed to help mitigate open source security issues.

Here are some mindsets you need to understand:

• When it comes to security vulnerabilities, proprietary software uses SAST or DAST tools to detect possible vulnerabilities. In the open-source community, known vulnerabilities publicly. So you can use tools that have a database of these vulnerabilities to stay updated at all times.

• When it comes to publicizing information, proprietary software owners keep everything private within their organization. Inversely, open-source information is publicly available. So, if there are security issues, these issues can be easily be mitigated.

• When it comes to remediation, you need to research and find a fix when dealing with proprietary software. However, most open source projects' documents are available, including histories of their issue. And knowledge-based sites give actionable remediations.

• When it comes to the scan phase, proprietary software is generally scanned only during development, whereas open-source software, even in post-release, is continuously monitored.

The point here is that open source is a different ball game. It would help if you had a different mindset when managing open-source software, especially when dealing with security. There are solutions and best practices available for many of the difficulties you will face in your journey because many communities and organizations have provided them online based on their own experience dealing with open-source software.

Even large corporations embraced many aspects of open source, which has led to innovation in the use of open-source through the years. And because it is open-source, developers have given back to the community as well.

Now, let’s discuss some approaches to open source security to understand the tool usage and importance.

Open Source Security Approaches

To manage security risks inside your organization's software project, we give you five helpful tips to keep in mind.

1. Keep Inventory of the Open-Source Components in Use

Having a list of open source components in use in a particular project is crucial.

An excellent example of this is the NPM package that resides inside your package.json file. If you're not familiar with the package.json file, imagine the list of packages installed in our project in a structural way, including its dependencies.

You don't have to do this manually. Many build tools can create the inventory for you, including the graph of the dependencies of these software components.

Now, the next step is to validate that these components don't contain any security vulnerabilities. When it comes to vulnerabilities, it depends on your organization's appetite. Furthermore, many tools provide steps to mitigating security vulnerabilities and can help fix these issues.

Note: This kind of open-source security build and analysis tool is not like static analysis tools.

2. Respond to Security Vulnerabilities

A build and analysis tool that checks open source dependencies for security vulnerabilities, including in-depth analysis and mitigation, is excellent.

Here are some pointers on how to respond to security vulnerabilities:

• For minor issues or everyday exposure in an open-source component, update the packages. You can even automate this depending on your build tools.
• Your tool will provide suggestions for medium issues because they have a database collection of such vulnerabilities, including their histories and fixes.
• For significant or high-risk vulnerabilities, your tool will provide in-depth information and mitigation steps.

3. Check if the Project Is Authentic

Selecting an open-source project in the first place is hard. Picking a project that is just starting and has caught your eye because of the value it brings to your team is not without risk. Therefore, it is a must that your organization study any small open source projects you have chosen and own some part of it, at least for awareness.

Moreover, you can check whether a chosen open source project is trustworthy and if the maintainers are competent enough? Will they respond if needed? Are they authentic, or are they, attackers?

These questions need answers for your good and your team's sake. But then again, these are just recommendations. Decisions will still need to come from your team finally.

Furthermore, a common practice is a responsible disclosure whenever someone updates or fixes a specific bug in an open-source project. That fix is recorded for all to see.

Thus, the open-source community will be aware of the fixes and the root cause.

The advantage of this is it allows the projects to improve and become good candidates for open source projects continuously.

4. Avoid Security Sprawls

Copying and pasting a credential like a database password into your source code is not a best practice. However, even though this is bad, most developers have done this at some point in their life.

Credentials are almost always the target of attacks, especially if you're a developer who puts the certificates, keys, configurations, and secret keys into your source code.

Compromised credentials lead to security risks. It is what you call security sprawl.

Security sprawl is a piece of sensitive information inside plain text on your source code, config files, and elsewhere.

Now, what's the solution?

First, put all the credentials into one place to be stored centrally and encrypted with access controls and audit logs.

Then, you can easily use these keys in your project and be confident that they are secure.

This practice is known as secret management.

5. Make It a Habit to Update Open Source Components

Keeping your open source up-to-date helps avoid vulnerabilities that exist in older versions.

It is crucial to use updated versions to receive bug fixes and undisclosed security fixes.

An example of a good tool that can help you keep track of new and upcoming vulnerabilities is the WhiteSource Vulnerability Database which covers a range of programming languages and over a million open source components.

Moreover, you can report a vulnerability to help the database be up to date from the new vulnerabilities that arise daily.

Conclusion

Open source is awesome! But it is not free, and it doesn't come without risk. That's why we need to understand and appreciate what open source is.

An excellent way to start is understanding the difference between closed source and open source, which is where we started in this article: Open Source Security Is a Different Game.

After that, we have shown you some security approaches to open source to help your organization see the big picture and start from there.

But please remember that these are just guideposts, and everything will still depend on your organization’s risk appetite when it comes to open source security risk.

Once again, I hope you have enjoyed this post as I have enjoyed writing it.

Stay tuned for more. Until next time, happy programming!

Please don’t forget to bookmark, like, and comment. Cheers! And thank you!

History

• 14^th September 2021: Initial version