devopsy.kinsta.cloud

Tag: open source

  • CloudBees Extends SDM Service Reach

    CloudBees Extends SDM Service Reach

    CloudBees has extended the integrations embedded within its software delivery management (SDM) platform to add support for additional services provided by Google.

    Moritz Plassnig, senior vice president cloud and general manager for SDM at CloudBees, said these integrations with Google Cloud Build and Tekton pipelines are being provided as part of a long-standing alliance between the two companies to advance the adoption of best DevOps practices. The CloudBees SDM service runs on the Google Cloud Platform (GCP).

    As part of that effort, CloudBees has been making investments in an SDM platform that enables DevOps teams to pull metrics from any tool or platform. That data is then fed into an analytics cloud service through which CloudBees surfaces insights that identify, for example, how delays to a project might impact overall revenue goals.

    Interest in software delivery analytics has risen in the wake of the COVID-19 pandemic as organizations accelerate the building and deploying of digital business applications, said Plassnig. With employees and customers alike working from home to combat the pandemic, organizations are investing more in creating applications that provide digital alternatives to engaging end users, he noted, adding delays to any of those projects are likely to have a much bigger impact on business continuity strategies today than they did just a few short months ago.

    The CloudBees SDM service provides DevOps teams and business managers alike a real-time view of all product and feature development occurring across the organization, as well as a policy engine to trigger actions to better optimize the software delivery process. Organizations can also model and visualize the software delivery process while measuring overall DevOps performance.

    Rather than requiring organizations to standardize on a single platform to achieve that goal, Plassnig said CloudBees is leveraging application programming interfaces (APIs) to integrate metrics across a broad range of DevOps tools. That approach, he said, makes it possible to meet organizations wherever they are in terms of DevOps maturity.

    Support for Tekton pipelines is significant, Plassnig noted, because it’s expected that most continuous integration/continuous delivery (CI/CD) platforms in the future will be built using Tekton pipelines, which provide an open source framework for building platforms that are designed to be deployed on Kubernetes clusters. Jenkins X, originally developed by CloudBees, is one of the first CI/CD platforms to support Tekton pipelines, which were originally developed by Google. Jenkins X and Tekton pipelines are now being advanced under the auspices of the Continuous Delivery Foundation, an arm of the Linux Foundation.

    As more CI/CD platforms embrace Tekton, the platforms themselves will become less of a black box from an analytics perspective, noted Plassnig.

    In the meantime, CloudBees also expects Google to continue to gain momentum as a cloud service provider, he said. While Google trails Amazon Web Services (AWS) and Microsoft in terms of overall market share by a wide margin, Plassnig noted that with the arrival of Anthos, a cloud operating system capable of being deployed on multiple cloud and on-premises IT environments, it’s only a matter of time before services such as Google Cloud Build are employed more widely.

    Whatever the platform used, the one thing for certain is the rate at which software is being generated and deployed on various platforms will be watched much more closely.

  • Grafana Labs Update Aims to Simplify Observability

    Grafana Labs Update Aims to Simplify Observability

    Grafana Labs today released an update to the open source Grafana project that adds a viewer that simplifies tracking the path of a single request through a distributed system.

    Version 7.0 also adds a plug-in for Amazon CloudWatch Logs along with support for Apache Arrow, a unified data and plugin framework that promises to make it easier to build plug-ins for the analytics and monitoring tools that are widely employed in DevOps environments to provide observability.

    The latest release also adds a range of automatic rendering options for a variety of formats, including tables and non-time-series charts alongside panel plugins for maps, pie charts and gauges.

    Ryan McKinley, vice president of applications for Grafana Labs, said Grafana has gained traction in DevOps environments in part because it makes it easier to query and analyze multiple types of data without having to pull it all into a central repository. All queries are launched against data wherever it resides, he said, noting by chaining a set of simple point-and-click transformations, users will be able to join, filter, rename and calculate all in the same platform.

    That approach makes it easier for DevOps teams to set up observability platforms using any mix of tools and services without much help from internal IT operations teams. That approach is now also starting to gain traction outside of DevOps environments as business analysts look for easier ways to also analyze data from different classes of applications, McKinley added.

    While observability has always been considered a core tenet of DevOps, achieving it has been challenging for most organizations. Simply setting up all the underlying platforms required has proven too challenging for many IT teams. Grafana has emerged as a tool that enables DevOps teams to visualize relevant data within the context of a custom-built observability platform.

    It’s not clear to what degree Grafana might emerge as a de facto standard. However, during an economic downturn, it’s not uncommon for IT organizations to rely more on open source tools to reduce costs. Rather than having to lay off an analyst or developer, many organizations will first look to reduce their reliance on commercial software licenses. Many of those same organizations have been wrestling for years with a fragmented approach to analytics software that often can yield conflicting insights.

    McKinley said one of the benefits of Grafana is that it reduces the cost of developing different models that enable organizations to explore different potential scenarios. Too often organizations are wedded to specific models that might not reliably reflect a new business trend simply because the cost of creating a new model is too high or takes too much time.

    Whatever the analytics path forward, the one thing that is clear is that as IT continues to become more complex thanks in part to the rise of microservices, DevOps teams will no longer be able to function without some form of observability platform being readily accessible. The only real question now is how best to go about building and maintaining that observability platform.

  • Fortanix Adds Platform to Manage Confidential Computing on Azure

    Fortanix Adds Platform to Manage Confidential Computing on Azure

    Fortanix today announced that a software-as-a-service (SaaS) platform for managing instances of confidential computing on the Microsoft Azure cloud is now generally available.

    Confidential computing is an emerging approach to encrypting data while it is running in memory. Today encryption is only applied to data at rest. Confidential computing makes it possible to set up secure enclaves for processing encrypted data in memory, which has become an increased source of concern for vulnerabilities in IT environments.

    Faiyaz Shahpurwala, chief product and strategy officer for Fortanix, said Confidential Computing Enclave Manager provides IT teams with a SaaS platform that enables them to provision a confidential computing environment, verify the integrity of those environments and manage the application life cycle for secure enclaves. Applications running on secure enclaves are built using Docker containers and images.

    Fortanix, along with Alibaba, Arm, Baidu, Google Cloud, Huawei, Intel, Microsoft, Red Hat, Swisscom and VMware, is a member of the Confidential Computing Consortium, an arm of The Linux Foundation. Confidential Computing Consortium projects include a Software Guard Extensions (SGX) software development kit (SDK) from Intel, an open source Open Enclave framework that allows developers to build Trusted Execution Environment (TEE) applications using a single enclaving abstraction, and Enarx, a project providing hardware independence for securing applications using TEEs.

    Microsoft earlier this month made available a DCsv2-series of virtual machines (VMs) that provide access to a TEE based on Intel SGX. Fortanix, for its part, already makes available a Fortanix Self-Defending Key Management Service on Azure.

    Shahpurwala said over time most applications will take advantage of trusted computing environments. Most of the initial use cases will focus on applications in which data privacy and securing personally identifiable information (PII) is critically important, he said.

    In the meantime, cloud service providers are racing to make available platforms for building and deploying TEE applications. Less clear is to what degree those environments will be integrated with DevOps platforms. The Confidential Computing Enclave Manager provides a management framework from which to begin that process. The Confidential Computing Enclave Manager also provides tools to convert applications to enable them to run on Intel SGX.

    There may come a day when confidential computing makes security a core element of any DevOps process. As such, the idea that there needs to be a distinct approach to DevSecOps may in time fade away as security becomes a series of infrastructure capabilities that are invoked programmatically. As that approach matures, application security would simultaneously evolve to become a natural extension of any quality assurance process.

    Of course, it may be a while before confidential computing is employed pervasively. Not every IT team has made the switch to containers to build applications. However, given all the focus these days on data privacy regulations it’s clear the requirements for protecting data within an IT environment are becoming more stringent with each passing day. The challenge now is finding a way to address those concerns during the entire application lifecycle management process in a way that doesn’t slow down the rate at which applications are being built and deployed.

  • OpenStack Delivers Ussuri Update

    OpenStack Delivers Ussuri Update

    The OpenStack community today officially released Ussuri, an update to the cloud management framework that tightens integration between components including the ability to automatically provision bare-metal servers using the Ironic IT automation framework built for that purpose.

    In addition, the community has added IPv6 support to the Kuryr project for integrating OpenStack with container networking and support for the CRI-O image specification for Kubernetes clusters within the Zun container runtime project. As a result, IT teams can now employ Zun-created pods on Kubernetes clusters that can run Kata containers being developed under the auspices of the OpenStack Foundation.

    Jonathan Bryce, executive director of the OSF, said support for OpenStack remains strong with more than 1,000 developers from 188 different organizations making contributions to Ussuri. More than 24,000 code changes have been made to OpenStack in this release. According to 451 Research, the OpenStack ecosystem is on track to be valued at $7.7 billion by 2023.

    Most OpenStack deployments have been on top of virtual machines. However, as interest in bare-metal servers to run platforms such as Kubernetes has increased, so too has interest in employing OpenStack to automate the provisioning on that infrastructure.

    At the same time, the relationship between Kubernetes and OpenStack remains complex. Many organizations prefer to deploy Kubernetes on top of virtual machines to ensure isolation. Others view Kubernetes running on bare-metal servers as a way to eliminate the need for virtual machines altogether. It’s too early to say how that debate will play out but for now most instances of Kubernetes are deployed on virtual machines. The issue is whether to deploy Kubernetes on one of several open source virtual machines or employ commercial virtual machines from VMware that have been widely adopted in enterprise IT environments.

    The OSF is also trying to drive the development of Kata containers, which will enable IT teams to employ a container runtime on top of a lightweight virtual machine to achieve isolation between workloads. Bryce said IT teams should expect to see a significant upgrade to the Kata project that will, among other things, make the runtime easier to deploy.

    Investments in OpenStack over the last decade have been substantial, so it’s unlikely many organizations that have adopted it are going to abandon it anytime soon. However, in greenfield environments many organizations are considering rolling out next-generation cloud-native applications based solely on Kubernetes. The OpenStack community has already signaled its intent to foster as much interoperability as possible with Kubernetes, which is developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    In the grand scheme of OpenStack history, it’s not likely Ussuri will be remembered as a major update. However, it does serve as a reminder of how active the OpenStack community remains, especially as telecommunications providers continue to rely on the cloud framework to automate the provisioning of both 4G and 5G networking services.

    In the meantime, enterprise IT teams that have embraced OpenStack as well should expect to be employing it to provision infrastructure to run both monolithic and microservices-based applications for years to come.

  • Divide Narrows Between Open Source Community, Standards Bodies

    Divide Narrows Between Open Source Community, Standards Bodies

    The path through which open source projects become industry standard is about to become a lot smoother. The Joint Development Foundation (JDF), an arm of The Linux Foundation, this week announced it has been approved to become an official submitter to the International Standards Organization (ISO) and the International Electrotechnical Commission (IEC).

    ISO and IEC previously came together to create a unified process for submitting proposals to establish technology standards. The JDF was created to provide a consistent corporate and legal framework for launching open source projects being advanced under the auspices of The Linux Foundation.

    Mike Dolan, vice president of strategic programs at the Linux Foundation, said now that the JDF has been recognized as an official submitter by ISO and IEC, it can represent open source projects that also want to establish a formal international standard. The first open source project to be submitted by the JDF is OpenChain, which provides a specification for achieving compliance using open source software within the context of a software supply chain.

    Historically, there’s been a significant amount of tension between open source projects and standards bodies. Standards have often been defined by vendors as part of an effort to promote the adoption of a technology by promising customers a level of interoperability to avoid vendor lock-in. However, many of those standards have been so loosely defined that it wasn’t really feasible for customers to switch vendors without incurring significant cost.

    The open source community has pursued a different approach to standards. Whichever project gains the most support from developers becomes a de facto standard. That approach has benefited organizations because adherence to a defined set of application programming interfaces (APIs) makes it comparatively simple to replace one distribution of a project such as Linux or Kubernetes with another. With endorsement by organizations such as ISO and IEC, many more of those de facto standards may become actual standards. That’s significant because there are still many organizations such as government agencies that are required to acquire technologies that comply with an official standard.

    To create an official international standard the JDF committed to a process for developing specifications that are neutral to all contributors. The specification must be developed with sufficient industry participation to ensure the resulting work is representative of industrywide consensus, and the specification must be formed in accordance with standard Publicly Available Specification (PAS) editing standards so that each specification is easily understood.

    It’s too early to say how this commitment on the part of the JDF will be received among the open source community. Many of them have long given up considering some standards bodies to be relevant. However, as the divide between the open source community and standards bodies continues to narrow, the impact an open source project might have on the state of IT could become a lot more profound.

  • Eclipse Foundation Moving to Brussels

    Eclipse Foundation Moving to Brussels

    The Eclipse Foundation announced today it will begin to transition its headquarters from Ottawa to Brussels as part of an effort to advance international expansion.

    Mike Milinkovich, executive director of the Eclipse Foundation, said with so many open source organizations based in North America, there is a clear need for an open source organization to have a larger presence in Europe. As nearly half of the strategic members that provide funding to the Eclipse Foundation are based in Europe, it made sense for the Eclipse Foundation to take on that role.

    The Eclipse Foundation is now home to 375 open source projects resulting in more than 240 million lines of code. Some of the most widely employed Eclipse Foundation projects include the Eclipse integrated development environment (IDE) and Jakarta, which is a follow-on to Java Enterprise Edition platform, previously owned by Oracle. In total, the Eclipse Foundation’s projects represent more than 13 billion Euros of investment.

    In general, Milinkovich said contributions to open source projects have accelerated in the wake of the COVID-19 pandemic. Developers who are staying home to help combat the epidemic apparently have more time to contribute to projects. The expectation is by moving to Brussels, more European developers will contribute to projects involving technologies such as internet of things (IoT) initiatives that address industrial use cases, he added.

    The Eclipse Foundation plans to establish a new legal entity sometime in July, with personnel relocating or added to a Brussels office over time depending on the nature of the Eclipse project being supported, Milinkovich said.

    It’s not clear to what impact being headquartered in Europe will have on open source projects, which are by their very nature global. However, Milinkovich noted most of the recent live events hosted by the Eclipse Foundation have been held in Europe. It may be a while before anyone is attending an IT conference in person, but Milinkovich noted European developers already play a major role in the Eclipse Foundation projects.

    Between the Eclipse Foundation, the Linux Foundation and the OpenStack Foundation, there is no shortage of opportunities for developers to contribute to open source projects. Many of those projects count on contributions from developers who work for IT vendors that have a vested interest in a specific project. In fact, many open source projects provide a way for IT vendors to defer the cost of creating a core piece of technology that doesn’t provide differentiated value. Rather than reinvent the wheel, it makes more economic sense to share open source code with potential rivals.

    Of course, it’s then up to each IT team to decide whether to employ that open source code themselves versus relying on an IT vendor to provide a curated instance of it under a support contract. Regardless, the total cost of IT would be prohibitively higher right now if it were not for the proliferation of open source software. It’s also worth noting many IT vendors that build platforms on top of open source software would be considerably less profitable.

  • Report: More Appreciate the Value of Observability

    Report: More Appreciate the Value of Observability

    Observability may be a core tenet of any best DevOps practice, but the number of organizations that actually engage in it is still not nearly as high as it should.

    A survey of 400 software engineers published this week by Honeycomb, a provider of an observability platform, finds nearly half said they are not currently practicing observability. However, the number of organizations that expect to embrace it is growing. The Honeycomb survey finds 75% of those respondents who haven’t implemented an observability plan to do so at an advanced level within the next two years.

    Conducted by ClearPath Strategies, the survey also finds that about a third of respondents are still evolving their observability capabilities. Only 10% of survey respondents exhibited what the survey describes as highly advanced capabilities.

    Liz Fong-Jones, principal developer advocate for Honeycomb, there is some correlation between the number of developers an organization employs and their reliance on observability. Among organizations that have advanced observability capabilities, 42% have more than 100 developers.

    In general, Fong-Jones said interest in observability is on the rise because it is becoming much easier to instrument applications. The emergence of open source agent software has made it much easier for observability platforms to collect relevant metrics that go way beyond simply monitoring an IT environment by sampling application traffic and analyzing logs, she noted. Observability platforms, in contrast, make use of technologies such as dynamic tracing to provide deeper insights into the root cause of an application issue.

    That approach also ties more closely to a specific user benefit versus simply collecting metrics that don’t surface any actionable intelligence, she added.

    Fong-Jones noted that observability platforms are now also playing a key role in eliminating technical debt. As organizations embrace microservices, for example, it’s becoming more challenging to identify bottlenecks and potentially redundant microservices. Observability platforms make it easier for DevOps teams to uncover these issues at a time when applications are becoming more complex, she said.

    There’s no doubt reliance of observability platforms will continue to substantially increase as organizations dive deeper into best DevOps practices. Most applications deployed by most enterprise IT organizations are not that deeply instrumented. As instrumentation becomes more pervasive, IT organizations will be able to drive more value from observability platforms. That could be crucial because it’s not uncommon for IT teams to spend weeks trying to find the source of an issue that might only take a few minutes to fix.

    Observability may not always be top of mind for IT teams but within the context of a best DevOps practice, it’s crucial. Many organizations are clearly racing to deploy applications without being able to observe how application code is behaving. In the absence of observability, it’s a foregone conclusion that tensions between developers and IT operations teams will rise. The challenge and the opportunity are to get everyone involved in IT on the same page in a way that ensures everyone involved is talking about the same thing at the same time.

  • IBM Looks to Drive Edge Computing

    IBM Looks to Drive Edge Computing

    IBM today at its Think Digital conference launched an edge computing initiative anchored around an IBM Edge Application Manager, through which a single administrator can manage up to 10,000 nodes.

    Hillery Hunter, vice president and CTO for IBM Cloud, said IBM Edge Application Manager is based on the Open Horizon open source software originally developed by IBM that is now under the auspices of LF Edge, an arm of The Linux Foundation focused on networking and edge computing platforms. Open Horizon makes uses of machine learning algorithms to automate the management of fleets of edge computing platforms.

    IBM also launched IBM Telco Network Cloud Manager to orchestrate both virtual and container network functions. IBM Telco Network Cloud Manager is built on top of an instance of Red Hat OpenShift, which is based on Kubernetes, and Red Hat OpenStack Platform.

    Finally, IBM is making available a range of edge-enabled applications, including IBM Visual Insights, IBM Production Optimization, IBM Connected Manufacturing, IBM Asset Optimization, IBM Maximo Worker Insights and IBM Visual Inspector.

    Like most IT vendors IBM sees the rise of application workloads on the edge as an opportunity to drive adoption of hybrid cloud computing. In the case of IBM, all of these offerings run on the Red Hat OpenShift platform.

    IBM also announced the IBM Edge Ecosystem, which brings together independent software vendors (ISVs) and IBM partners to craft edge computing solutions. Additionally, IBM launched the IBM Telco Network Cloud Ecosystem, which is more narrowly focused on edge computing platforms deployed for telco-focused environments such as a wireless 5G network.

    IT vendors participating in those initiatives with IBM include Cisco Systems, Dell Technologies, Juniper, Intel, NVIDIA, Samsung, Packet & Equinix, Hazelcast, Sysdig, Turbonomics, Portworx, Humio, Indra Minsait, EuroTech, Arrow, ADLINK, Acromove, Geniatech, SmartCone, CloudHedge, Altiostar, Metaswitch, F5 Networks and ADVA.

    Edge computing will undoubtedly force organizations to embrace DevOps more aggressively. Managing thousands of edge computing platforms will require not just higher levels of IT automation infused with machine learning algorithms, but IT teams will also need to be able to deploy, secure, update and manage applications distributed across thousands of endpoints.

    IBM, of course, is not the only IT vendor eyeing the edge computing opportunity. The challenge IT organizations will face first is building new classes of latency-sensitive applications running in near real-time that will be built mainly using microservices. Once those applications are built, organizations will then need to update them continuously within the context of a highly scalable IT management framework.

    Naturally, some organizations will prefer to rely on external IT service providers to rise to that challenge while others will continue to build and manage their own applications and infrastructure. Regardless of the approach, the level of scale and complexity at which IT is being applied is about to reach a level that once would have been unimaginable. Not only will more applications run in near real-time, those applications will be integrated and share data with batch-oriented applications running in the cloud and local data centers. The challenge is finding a way to automate the management of IT at scale without requiring organizations to rely on manual processes, for which there are simply not enough IT professionals available to manage.

  • Deploying OpenStack: Pick a Distribution With These 7 Qualities

    Deploying OpenStack: Pick a Distribution With These 7 Qualities

    OpenStack, which turns 10 years old in July, remains the leading open source infrastructure component in private clouds. But, there is a plethora of OpenStack distributions out there, and selecting the right one is vital to the success of every organization’s OpenStack project.

    How do you know which is best? It’s an important question because, despite OpenStack’s popularity, companies often face serious challenges when adopting and deploying it. Put simply, OpenStack can be time-consuming and skill-heavy in order to deploy it, unless the chosen distribution is equipped to overcome those challenges.

    Thus, anyone planning to deploy OpenStack should make sure the distribution they pick meets the following seven criteria.

    Strong Economics

    Cloud environments are supposed to be more cost-efficient than proprietary hardware. That’s why enterprises love the cloud, after all. Therefore, the number one priority when choosing an OpenStack distribution is to make sure it can indeed reduce costs. That means steering clear of OpenStack platforms that are hard to deploy, maintain, upgrade and force you to struggle with basic operations. It’s also important that the distribution’s pricing model be clear and predictable so that organizations can plan expenses accurately.

    Totally Open Source 

    While OpenStack itself is open source, the installers provided by the vendors as part of their distributions often are not. This can lead to additional costs being applied to the licenses and situations where organizations are forced to pay for the distribution before even trying it out. Furthermore, all types of environments in use—including staging and development—need to be covered by the license, too. These pitfalls are sidestepped with OpenStack distributions that are 100% open source, providing better economics and flexibility for organizations.

    Predictable Release Cadence 

    While the release cadence of OpenStack is predictable and well documented, not all distributions follow the upstream quickly enough. Making sure the OpenStack distribution you choose supports the latest stable upstream release as soon as possible is crucial for a few reasons. The upstream release may have features that are important for the organization. Or there may be bug fixes that they feel are critical. Picking a downstream distribution with a predictable release cadence that stays in sync with the upstream ensures transparency and allows organizations to plan the upgrade process. 

    Long Support Runway

    Support services are essential for OpenStack production environments, especially when service level agreements (SLAs) apply. But, how long vendors will support older versions of OpenStack can vary. Though there is always an option to upgrade or re-deploy, there are times when it may be beneficial for organizations to stay with the current version. Thus, how long the vendor will provide support services is a key factor in choosing a distribution.

    Upgrades Made Easy

    There inevitably comes a time for most organizations when they want to upgrade their upstream OpenStack. However, OpenStack upgrades are known to be complex, and many commercial distributions do not support them. Even if they do, the process is complex and must be executed manually. Thus, choosing an OpenStack distribution that provides support for fully automated upgrades is essential for the success of the cloud operations team.

    Simplified Operations 

    Even after an OpenStack cloud is deployed, consideration must be given to the ongoing operations that can become complex and fragile. Maintaining the cloud on a daily basis includes operations such as scaling the cluster out or recovering it from failure. While most OpenStack distributions don’t provide mechanisms to simplify these tasks—forcing users to execute them manually—some do. Organizations should look to distributions that do a good job automating complex operational tasks, saving time and money.

    Flexible Technology Choices 

    OpenStack is a flexible cloud platform, supporting various hypervisors, software-defined networking (SDN) solutions and storage plugins. But many distributions are tied to a single stack. That means an organization may need to re-platform or move to a heterogeneous environment in the future. Avoid that trap by selecting a distribution that can adapt to work with new technologies.

    By looking for these seven qualities, organizations can get the most out of their OpenStack distribution and optimize the cloud infrastructure on which they increasingly rely.

  • Open Source Vulnerabilities Were Up 50% in 2019 — How Will It Impact Software Development in 2020?

    Open Source Vulnerabilities Were Up 50% in 2019 — How Will It Impact Software Development in 2020?

    Open source vulnerabilities have been on the rise in recent years, but 2019 was truly one for the record books with a spike of nearly 50% over the previous year.

    According to the recently released State of Open Source Security Vulnerabilities report by the WhiteSource research team, the number of vulnerabilities jumped from 4,100 in 2018 to 6,100 in 2019.

    Open Source Vulnerabilities
    Figure 1: Number of reported open source vulnerabilities per year.

    In hopes of better understanding what is behind this rise in the number of open source vulnerabilities, what it tells us about the state of open source usage in modern software development, and even where we are likely headed in the years ahead, let’s take a look at the report’s findings for insights on the current state of open source security.

    More Code, More Vulnerabilities

    According to the research report, the primary driver behind the rise in open source vulnerabilities is a function of the growth of open source. There are now more open source projects, code and members of the community than ever before.

    All of these good folks are working hard to not only write more code, often with the backing of large tech giants, but also to seek out vulnerabilities in the code that can put the users of their components at risk. The combination of more code being written and the number of eyeballs reviewing the code for those inevitable human mistakes, comes together to produce a larger number of vulnerabilities being reported.

    The increase in the number of vulnerabilities in open source components will have a considerable impact on software development. In recent years, we have seen open source components playing a bigger role in how developers build their applications. Most estimates believe that open source components comprise between 60-80% of the codebase in most modern applications. When a vulnerability is reported in a popular project such as Apache Struts or the Linux kernel, then huge swaths of developers can quickly find their software in need of patching.

    The Good, the Bad and the Bazaar

    WhiteSource’s research revealed the reassuring news that over 85% of reported open source security vulnerabilities have a fix available.

    One of the reasons for this improvement is the fact that more enterprises are dependent on open source components for their own software, so they are investing in making it more secure, via bug bounty programs, backing foundations that support open source security or backing the projects themselves.

    However, even as the situation in the field appears to be improving, there is still a way to go.

    The fact that many published open source vulnerabilities are not indexed in one central location adds complexity to this challenge for development teams attempting to stay on top of published open source security vulnerabilities. If proprietary software is still considered to be the classical Cathedral, well-organized information and support under one roof, then open source is very much the Bazaar.

    The WhiteSource report found that only 84% of known open source vulnerabilities appear in the National Vulnerability Database (NVD). This means that information about another 16% of the known vulnerabilities is out there, spread out among a wide range of resources. These might be security advisories, bug trackers and a laundry list of other locations. While 45% of reported open source vulnerabilities that were not initially published on the NVD eventually end up there, that could take months since their publication on other resources.

    The challenge for organizations is that they run the risk of using a vulnerable component unaware of the security updates, while hackers are scouring all resources, looking for vulnerabilities that could be their next meal ticket.

    Given the evolving security challenges facing organizations, what does the future hold for open source security in the year ahead?

    Our Predictions for 2020

    The easiest prediction that we can provide is that 2020 will have even more reported open source vulnerabilities than were published in 2019. The only question is: How big it will be? Chances are that the count will be more significant due to recent advances making it easier than ever to report and an open source vulnerability.

    This past year saw the launch of GitHub Security Lab which aims to help researchers, maintainers and users easily report an open source vulnerability and publish a verified fix in one centralized location. By simplifying the reporting and documentation process, GitHub has gone a long way in helping their users to protect their software with better quality reporting.

    Key Takeaways

    For many, the rise in the number of reported open source vulnerabilities might be concerning, making us confront the fact that we probably have plenty of them in our software right now. However, the situation is actually improving, and even heading in the right direction. When vulnerable open source components are reported, we get to track them and move quickly to remediate. Only once you know you have a problem can you begin to fix it.

    Hopefully, the increase in security awareness will keep pushing for a stronger, more organized and better supported open source community that will be resilient in the face of even more vulnerabilities that are likely to show up in next year’s research report.