The term Open Source Software (OSS) describes a free software movement started by a previous generation of programmers, back when making a computer do anything was an impressive feat of logic and command construction. The open source initiative (OSI) is about the use of free and open source software, versus proprietary software or “closed source software”.
Under a GNU General Public License (open source software license) individuals can learn from working with open source code without buying or cracking corporate products. Open source developers can take pieces from open-source software or incorporate an entire chunk of their project capabilities whole-cloth. The open source software movement is a good resource for the technical community in terms of learning, open collaboration, open standards, developing, and research.
But there’s a major drawback working with open source technology: OSS isn’t natively secure. Open-source software can be used in your business stack, but only if your IT and development team treat it like an incomplete piece of code. Red Hat and Auttomatic (parent company of WordPress) are examples of two companies that supply open source software.
No matter how complete an OSS project might be (and they are projects, not products), they should never be considered complete and ready for unmodified implementation. Unfortunately, this common mistake leads many businesses to make serious cybersecurity mistakes by not properly securing tech stacks that include OSS elements.
Why OSS Leads to Business Security Mistakes
The core reason for OSS-related security mistakes is the misunderstanding of professional use. Open source was originally intended as a resource for programmers writing software code. Because programming is so complex and precise, programmers have always shared information and code snippets. Often with comments like "Here's how to write your Facebook API login handler in C++ but change the variables for your website and plugin names".
These disclaimers are understood, from programmer to programmer. Any classically trained or adequately self-taught programmer will know to attach their own security functions and advised security measure to, say, a basic-website package. But C-levels often don't have the tech-industry background to run down the checklist of security and maintenance requirements for using OSS software-pieces
This is where mistakes happen. Businesses incorporate an open-source project that has the elements they need for a website, but they don't take the steps needed to adequately harden the server and software before going live. These mistakes can be costly and result in market risk, financial risk, or a hack that compromises your organizational and client data.
Let's examine the most common security mistakes made by businesses when working with open-source software.
8 Common OSS Security Mistakes
1. Not Monitoring for Updates
Thinking practically, everyone knows that updating regularly is important to keep hackers at bay. Software updates are analogous to the practice of vaccines. You get them regularly so you're less vulnerable to viruses and infections. Any defenses you or your software may have against being hacked, are only as good as the defenses could be when the software was written.
Software companies constantly release updates and patches to close security gaps and counteract known infiltration methods. Not to mention the occasional updates in functionality and features. It's important to monitor for updates on your company's entire tech stack, both commercial and open-source software.
SaaS programs are often self-updating because the subscription includes some concierge maintenance. But open-source software often has little to no paid staff and/or minimal automation because it is, at its core, just shared a shared code based and snippets in a community. You often need to manually check for updates for any OSS used in your stack, then run your software through a backup and the update process.
However, half of all companies using OSS have a formal policy on open-source use. Even fewer check regularly for updates or have updated open-source elements of their tech stack in the last few years.
2. Failing to Assign a Security Officer
The next common mistake is not assigning a person or team to monitor security for the tech-stack or for the open-source elements. Many businesses wrap security up with general IT, but no oversight is given to form a complete security plan. Incomplete security planning leads to security gaps, often between otherwise secure tech elements or through one insecure program in your stack.
OSS is the most commonly hacked element of a company's tech stack because its code is publicly available and open to the entire software development (and hacking) community. Assigning a security officer, whether in-house or outsourced, gives one person (or team) the perspective to monitor and close your security gaps, including those introduced by open-source use.
3. Not Auditing for Vulnerabilities and Security Gaps
Every piece of software written has vulnerabilities and potential security gaps. Each technology and software in a stack will have a unique set of vulnerabilities. Some will form security gaps by sharing certain settings. Some will close each other's security gaps.
The landscape changes as new or existing elements are introduced, updated or swapped out. This means that it's necessary to constantly audit for vulnerabilities and seek to close security gaps in order to maintain data security. Only 17% of businesses regularly monitor their OSS code for security vulnerabilities. This leaves them exposed to weaknesses that can be discovered by hackers using the same open-source access to study, practice and penetrate these pieces of software.
4. Choosing Plugins and Extensions without Verification
Plugins are an important part of the OSS community because each project is inherently, and by design, substantially incomplete. Plugins and extensions are necessary to add functionality that was not part of the original, core project. However, anyone can write a plugin and submit it on the open-source marketplace.
Items in a plugin marketplace range from professional quality extensions to amateur projects. They also include honeypot plugins, made by hackers to purposely expose the code to gain access and control of the software at some future date.
This is why it's so important to verify any extension or plugin that you add to your OSS elements. Verification means checking out the developers, the studio, and the code itself for legitimacy and security. If you add a plugin without vetting it completely, there's a chance that it will, intentionally or accidentally, open a backdoor for hackers and malware. If you don’t have the programming skills to do this, you will need to hire someone who does.
5. Using Abandon-Ware OSS
In the tech community, the term 'abandon-ware' means software that no longer has a development team. It's not being updated for compatibility with the latest systems and it won't be getting any new security patches. Abandon-ware is known to be a "use at your own risk" undertaking and the abandonment of functional software is a real problem in the industry.
However, it becomes your business' problem if you choose to incorporate unsupported software or plugins into your tech stack. No matter how great the features are, if a project or plugin is not properly supported by developers then it will suffer from the security vulnerabilities of any aging, unsupported software. And if compatibility breaks down, you'll need to fully replace the unsupported OSS elements.
6. Installing Updates from Unknown Third Parties
A related risk to abandonware, in fact open source in general, is seeking out updates from unverified sources. Part of the raison d’etre of the open-source community is that anyone can contribute their work to a project, as well as download and use the project for themselves. This means that the community can keep abandon-ware alive or enhance software that others are using. But if you choose to download updates made by the OSS community, know whose code you are incorporating and what it does.
Hackers can and do offer "security" updates, plugin-ins and templates for OSS projects, hoping that the software users will unknowingly incorporate malware or back-door-vulnerabilities to their tech stacks. If someone is researching community updates and installing them, you'd better have a rock-solid vetting process.
7. Failing to Test Open Source Integrations Thoroughly
Testing software is a rigorous and important process. Whether you are developing software using open-source elements or incorporating OSS into your tech stack directly, tests are what ensures that everything works properly and that your security gaps are effectively closed. However, in business, it's always tempting to plan the fastest route rather than the most thorough methodology.
When it comes to using open-source software, it's always important to do substantial testing. Never assume that OSS will do what it says. Programmers make mistakes, and programmers you did not pay have less accountability than those who have a business reputation or relationship to protect.
8. Trusting that Open-Source is Already Secure
Finally, the most common mistake that businesses make with open-source software is assuming OSS is already secure. It's an easy mistake to make.
OSS projects seem complete. And in the business world, 'complete' includes all the necessary security functions for "plug and play". But OSS is the exact opposite of "plug and play". In the OSS world 'complete' merely means nominally functional.
Open source software can't be fully secure, because it must be customized to the needs and settings of each individual environment.
---
At QuickSilk we offer a secure web content management platform that includes the security protections you need. We take care of the constant checking, verifying, and updating of the tech stack and security. We do all this for you!
For more insights in building a secure website with QuickSilk’s drag & drop platform and avoiding these common OSS mistakes, contact us today!
