devopsy.kinsta.cloud

Author: Fred Bals

  • Open Source Software and the Tragedy of the Commons

    Open Source Software and the Tragedy of the Commons

    With many eyes looking at code, “All bugs become shallow,” as software developer and author Eric Raymond called Linus’s Law in action. This is one of the reasons behind the popularity of open source: the volunteer communities working to improve and update the code.

    And according to a Purdue University study, Linus’s Law does, in fact, work. Open source communities regularly issue patches faster than their proprietary software counterparts. However, Linus’s Law only works when there are enough eyes on the code. And there’s no guarantee that the community behind any given open source project will continue maintaining the code.

    Of the 1,200+ codebases examined for “2020 Open Source Security and Risk Analysis” (OSSRA) report, 88% contained open source components that had had no development activity in the last two years.

    Now let’s take a trip back in time to glean a few lessons that history has offered. You see, in the early 19th century, “free lunches” were a popular saloon promotion. Patrons had to buy a beer (or drink or alcoholic drink of their choosing) to wash down whatever food the barkeep offered. And there’s the catch.

    Profits on whiskey and beer sales more than compensated the saloon for putting out the free lunch spread, which often was little more than soup, crackers and problematic pickled eggs. There’s a price for everything—whether evident or not.

    With popular open source code, this price of a free lunch has increased the pressure on those maintaining it—those who handle bug reports, feature requests, code reviews, code commits, etc., for their so-called “free” software. Increasingly, as open source grows in popularity, the price of free lunch has been developer burnout and the abandonment of their open source projects.

    It’s the tragedy of the commons in action—a resource growing so much in popularity that it can’t remain viable unless the community shifts to sustenance rather than exploitation. Witness the Twitter thread started by James M. South, creator of several popular open source solutions, who bemoaned the fact that, “#ImageSharp passed 6 million downloads this weekend and I’m a lot less happy about it than I probably should be.”

    South goes on in several follow-up tweets, “Over 5 years of development there have only been 98 collaborators, 23 of which have made more than 10 commits. … It’s not about money, it never was and never will be, it’s about sustainability.”

    Too few people—and their organizations—who rely on open source software are contributing to the projects they use. If you’re a developer and have a favorite open source component, you can contribute to its development through development, sharing your modifications, bug reporting, crowd-funding, letting the developers know how you are using it and helping others get started. That last may be the most important thing you can do for any open source project—helping build a user community large enough to sustain the project.

  • How to Source Vulnerability Data for True DevSecOps

    How to Source Vulnerability Data for True DevSecOps

    Open source comes with code vulnerabilities that must be considered in the DevOps process

    The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

    Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

    But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

    Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

    The NVD and Its Timeliness Problem

    Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

    For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

    The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

    The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

    Augmenting NVD Vulnerability Information

    Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

    For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

    A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

    Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

    Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.