More enterprises are making increased usage of open source software, but, as they do, they tend to overlook its security implications. When choosing an open source project as a component of a company, product, or service, it is easy to get lost in the list of alluring new features, when actually the first thing to check is the security policy. For starters, does the project have one?
It is expensive to have a security team, and not all open source projects can afford it. Sometimes there is not even an email address for reporting security vulnerabilities. In these cases, vulnerabilities are likely to be reported publicly on the development list. The company becomes responsible for monitoring this list, which could have high traffic, and mean fixing bugs in a timely fashion. This is doable, but it requires a level of skills and commitment higher than usually anticipated.
Security Contact ListsFortunately, most projects have a security contact list, but the process of dealing with security issues is often not clearly stated. It can be the result of a deliberate choice to reduce bureaucracy, but the consequence is that discoverers and users alike do not know what to expect from it. For example, the typical time between discovery and disclosure, or whether responsible disclosure is supported, is crucial information.
Responsible disclosure entails keeping a list of trusted users and reporting vulnerabilities (and fixes when available) to them first, before they are made public. This way, users, especially the ones with large deployments or complex update procedures, have the time to update their systems before having intruders knocking at their doors. Responsible disclosure is commonly considered one of the best models to reduce exposure time, but it is not often employed. When it is, the pre-disclosure list might still be limited to just a specific class of customers. For example, the main pre-disclosure list for the Linux kernel, OSS Security Distros, is only for Linux distributions. If your organization is not a Linux distribution, it cannot join. This is done to prevent the list from becoming too large and unmanageable.
When pre-disclosure is not available, it is essential to monitor public security announcements lists and patching systems immediately. It is a race against attackers. Fortunately, most of the time it is a low-effort activity and can be at least partially automated, but for this to happen the security announcements list needs to be well maintained. This is the first thing to check in a project.
Security teams have limited resources. Their job involves evaluating every vulnerability report, negotiating a disclosure date with the discoverer, developing a fix for the bug, and writing an advisory and sending it to the public announcements list on the due date. Older releases might be diversely affected by vulnerabilities, therefore maintaining multiple releases for security increases the team's efforts almost linearly. It is not surprising that most security teams commit to handling issues only for the most recent release. Users should be aware of which releases are maintained for security at any given time, and schedule deployment-wide upgrades well before old releases become unmaintained. Nothing is riskier than running orphaned software in your datacenter.
Support the Security TeamsIt is viable to handle security updates for open source projects without upgrading them into commercial software, but the process needs to be properly understood. The only way to reduce the risk of exposure is to keep up with security patches, but this activity requires very different levels of effort depending on the security policy of the upstream project. Decision makers need to be fully aware of it in order to quantify the consequences of incorporating a specific software component into the company stack. Furthermore, open source is about taking and giving back. If your company is basing one of its products on open source software, consider contributing back, not just with code, but also with code reviews and security management. Support the security teams of the open source projects you care about today.
Comments