devopsy.kinsta.cloud

Category: Blogs

  • Env Vars

    Env Vars

  • Couchbase Revamps DBaaS Based on Document Database

    Couchbase Revamps DBaaS Based on Document Database

    Couchbase Inc. has unfurled a revamped database-as-a-service (DBaaS) platform dubbed Couchbase Capella hosted on the Amazon Web Services (AWS) cloud.

    Scott Anderson, senior vice president for product management for Couchbase, said that as application development continues to evolve, it’s becoming apparent more organizations prefer to have providers of databases manage those platforms on their behalf. That approach frees up database administrators (DBAs) to spend more of their time building and deploying applications, he noted.

    Couchbase Capella is based on Couchbase Server 7, which added multi-statement SQL transactions capabilities to the document database, based on a JavaScript Object Notation (JSON) format, to make it possible to also run in microseconds transaction processing applications that previously would have required a relational database to process SQL ACID transactions.

    That release of Couchbase Server 7 also added schema and table-like organizing structures, called “scopes and collections,” within the schemaless database to make it possible to add a table while transactions are running.

    As a document database Couchbase has gained traction mainly thanks to developers who have opted to employ a database they could download and deploy themselves to build applications instead of requiring a DBA to set up a relational database. However, as the number of instances of a document database proliferates, a need to manage them across fleets of servers and cloud services has emerged.

    The challenge then becomes determining whether to hire a dedicated administer or employ a DBaaS managed by a vendor. Many organizations are opting for the DBaaS approach because it eliminates the need to hire a full-time administrator. Once an organization opts for the DBaaS approach, however, it next needs to integrate that service within its DevOps workflow to build those applications.

    There is, of course, no shortage of options when it comes to DBaaS platforms. The global cloud database and DBaaS market size is expected to reach $26 billion by 2025, according to a report from Adroit Market Research. Overall, the as-a-service market reached a record $13.4 billion in the third quarter, up 55% from prior year, according to a report published by Information Services Group (ISG).

    It’s not clear to what degree organizations will ultimately wind up relying on as-a-service platforms, but since the start of the COVID-19 pandemic, the shift to this approach to consuming IT resources has increased significantly. As a result, the way internal IT teams are organized is shifting as lower-level tasks are either automated or handled by an external IT team that works for a vendor.

    Regardless of approach, the amount of data being created and analyzed within organizations is only going to grow. Organizations will need to determine to what degree it makes sense for them to manage that data versus relying on an external services provider. The challenge, of course, when relying on an external service provider isn’t just technical; it introduces a new cultural dynamic that takes some time for many IT teams to appreciate fully.

  • Securing Your Software Development Pipelines

    Securing Your Software Development Pipelines

    Earlier this year, it was announced that the attack on IT management software provider SolarWinds had been used to compromise other organizations, including parts of the United States government. There were several reasons for alarm because of this news, but one of the biggest was the revelation that attackers breached SolarWinds’ software development process and pipeline. The level of concern was such that it led to a first-of-its-kind executive order on cybersecurity.

    The security of the software development process has been a concern for development teams for decades, beginning with Ken Thompson’s thought experiment around hacking compilers to inject vulnerable code (PDF). As the software development process becomes increasingly automated, this means there is more to secure. Indeed, the biggest difference between Thompson’s “Reflections on Trusting Trust” and today is that much of our concern stems from just how much we, as development teams, must trust code that was not written by us.

    The issue of code ‘not written here’ is bigger than just open source libraries – though those are a big part of the issue since a typical Java application is 97% third-party code by weight, according to the Veracode State of Software Security, 2020. Moreover, modern cloud-native applications are also comprised of additional types of code written by others, including container images, serverless code and other cloud-native artifacts.

    As a result, an attacker could compromise a development pipeline by one of a variety of means:

    • Poisoning an upstream open source repository by taking over an open source project, or by typosquatting
    • Compromising a container image repository
    • Gaining access to the continuous integration server and making changes in the pipeline to incorporate malicious code
    • Gaining access to the source repository, identifying an existing vulnerability (zero-day) in an application, and exploiting it in production

    So, what must be done to mitigate these threats? A lot of the answer comes down to testing, managing the chain of custody and monitoring access to internal resources.

    • Managing access—Systems that touch your software development process provide a door that, if not properly secured, may allow an attacker to walk in and compromise the software you ship to your customers. Things to be aware of here include the source control system, the continuous integration server and other tools (including quality and security tools) that have access to the source repository. Similarly, any activity that touches the source code, especially commits to the source code repository, must be properly authenticated with a developer GPG key. This prevents spoofing a user’s identity by setting git configuration parameters (this blog post from Alessandro Segala describes the problem nicely) or by stealing credentials.
    • Manage the chain of custody for software dependencies—Most modern software dependency managers allow connections to multiple software registries, including public registries that can be easily attacked or compromised. Configuring dependency managers to only allow connections to an authorized list of registries can help keep compromised packages from entering the build pipeline. This can also help to ensure that only dependencies that are free of critical and high vulnerabilities can be used in the application. This topic also relates to the next one on testing for vulnerabilities. Part of managing code coming from other parts of the software supply chain is looking for security vulnerabilities in the code. Consider a security scanning tool that can look for vulnerable open source libraries or container images with vulnerabilities and security misconfigurations.
    • Testing for vulnerabilities —Code introduced by an attacker may introduce new vulnerabilities. Using static application security testing (SAST) can help to identify serious security issues, including poor cryptographic practices, hard-coded credentials, and injection vulnerabilities. Performing SAST in the pipeline allows for the identification of critical and high severity defects early, enabling you to fail a pipeline upon their discovery and preventing insecure code from being deployed into production. Likewise, as noted above, testing for vulnerable containers and open source libraries can prevent vulnerabilities from being introduced via the software supply chain. Finally, using dynamic application security testing (DAST) to perform an end-to-end runtime test for a web application in a pre-production environment can help identify other exploitable issues in the end-to-end application. It can also find problems with application configuration that are only observable in the deployed environment. Both SAST and SCA might identify weaknesses in software that, while indicative of poor coding processes, may not be vulnerabilities. So, selecting tools that allow you to set a baseline of acceptable findings can help to ensure this control is adopted successfully.

    Solving all these problems requires thinking about different parts of the application development process as a complete system. To that end, Veracode collaborated with Venafi, Sophos and CloudBees earlier this year to put together a proposed blueprint for secure software development pipelines. The proposal is maintained on GitHub and is available for users to raise issues or propose pull requests on the blueprint—all input is welcome.

    The importance of getting this right cannot be underestimated. Hacks and breaches continue to hit the headlines, and putting in place the right tools, technologies and processes to minimize security risk in the software development pipeline is more critical than ever. 

  • Sustainability No Longer Just a Buzzword for Cloud IT

    Sustainability No Longer Just a Buzzword for Cloud IT

    A recent CloudBolt survey on IT sustainability finds that sustainability is no longer just a buzzword — the market is demanding real change, and it appears that environmental concerns finally are influencing large IT investments. For example, 67% say that a cloud provider’s sustainability initiatives are important in deciding whether to do business with them. A significant portion of organizations are even willing to pay a premium to support green initiatives!

    Below, I’ll review the report to find its major takeaways. We’ll see how sustainability is directing real action in cloud IT and briefly compare how the market perceives current green initiatives among three top cloud providers: AWS, GCP and Azure.

    Sustainability Gains Real-World Traction

    In June and July 2021, CloudBolt polled 256 global CxOs and tech leaders on its Pulse platform, and found that 76% of respondents now consider climate change an existential threat. Not only are IT purchasers factoring compute and cost, but a sustainability conscience is now influencing executives to direct sweeping change. In fact, 79% of respondents indicate their IT departments are expected to help their companies achieve specific sustainability initiatives driven by the board of directors of the C-suite.

    Interestingly, other studies found that a sustainability commitment results in tangible business outcomes. For instance, 88% of the research conducted by Oxford University and Arabesque showed that solid environmental, social and governance (ESG) practices result in better operational performance of firms and higher profits. This study also noted that 80% of the time, a company’s stock price is positively influenced by sustainability practices.

    Climate Conscience Guides Cloud Choices

    Most organizations now consider a cloud vendor’s sustainability initiatives when choosing whether to do business with that provider. A full 78% of respondents agree that the public/private cloud choices they make can materially affect the environment for better or worse. New environmental cloud commitments not only attempt to minimize carbon emissions from their data centers but factor in ecological ramifications and aim to erase companies’ historical carbon footprints, as well.

    Cloud consumers also want to contribute to addressing these green initiatives. An impressive 79% of respondents indicate that they will pay a premium to work with vendors who incorporate sustainability into their business. And 41% of companies are willing to pay a premium of 11 % to 15% of their current bills. This shows that sustainability is now a vital factor within the marketplace, and companies are willing to pay the price to increase their own environmental standing.

    Though this commitment is undoubtedly growing, the report did find that operational requirements such as security, cost and agility, still rank significantly higher than sustainability when comparing cloud providers. Though IT professionals recognize climate change as an existential threat, they still have day jobs and must keep operations moving.

    AWS: King of Green Clouds

    Slightly more than half (51%) of respondents agree that the industry-wide green energy commitment is real and growing among all cloud providers. However, when comparing the top three—Amazon Web Services (AWS), Azure and Google, AWS appears to be emerging as an IT sustainability leader; 41% of respondents perceived AWS as doing the most to address green initiatives.

    AWS is on track to power its entire operations with 100% renewable energy by 2025. With their solar plant investment in April 2021, Amazon became the largest corporate buyer of renewable energy in Europe. Around the globe, AWS has invested in a combination of on-site solar, solar farms and wind farms to power their data centers and Whole Foods divisions.

    To their credit, both Microsoft and Google also committed to climate pledges that affect their cloud footprint. Azure supports a similar initiative to reach 100% renewable energy by 2025, in addition to further investments to improve water, waste disposal and surrounding local ecosystems. Google Cloud’s commitment is to operate on carbon-free energy 24 hours a day by 2030, and the company has already achieved 100% renewable every year since 2017.

    Not only does AWS appear to be doing the most to address its environmental impact, it also retains the most market traction as a cloud leader. The majority of respondents (62%) said that AWS is winning the cloud wars while only 31% said Azure and just 7% said GCP.

    Final Thoughts

    It is heartening to see that ESG standards are having a measurable impact on a company’s cloud allegiances. The market now demands real change and is willing to pay the price for more ethical and sustainable cloud hosting.

    But choosing a cloud provider is only one aspect of reducing IT’s impact. As I’ve covered before, there are many ways IT can curb its climate impact. Such actions include optimizing overall infrastructure, shuttering zombie VMs, avoiding over-provisioning resources, increasing performance visibility, refactoring code and other measures. What’s great is that most of these initiatives have the added benefit of reducing cost to the business.

    The CloudBolt Industry Insights Report, The Truth About IT Sustainability: Paying More Green to Get More Green, surveyed 256 IT leaders on their perception of cloud sustainability. For additional insights, you can pick up a copy here.

  • Salt Security Adds Support for GraphQL APIs

    Salt Security Adds Support for GraphQL APIs

    Salt Security has extended its platform for securing application programming interfaces (APIs) to include support for APIs built using GraphQL.

    GraphQL is an open source data query and manipulation language for APIs that was originally developed by Facebook. It provides a more efficient approach to querying data than the REST APIs that are widely used today.

    Elad Koren, chief product officer for Salt Security, said adding support for GraphQL alongside existing support for REST APIs to the Salt Security API Protection platform will make it possible for security teams to discover those APIs, mitigate data exposure, stop attacks and eliminate vulnerabilities. The Salt platform parses the complex structure of each GraphQL query to identify unique object entities that are then used to create a complete inventory of the GraphQL APIs being employed.

    APIs built using GraphQL are more challenging to secure because of the unique call and response formats, noted Koren. Cybercriminals can also, for example, leverage GraphQL capabilities such as nested queries and query batching, to launch distributed denial of service (DDoS) attacks, he said.

    Many developers will tend to assume that, because GraphQL is relatively new, most cybercriminals are primarily focused on exploiting REST APIs. However, as more developers employ GraphQL, it’s only a matter of time before cybercriminals begin to find ways to exploit APIs that may not be as secure as the REST APIs that many organizations already know how to secure.

    The Salt Security platform itself is based on a big data engine that employs machine learning algorithms and other forms of artificial intelligence (AI) to identify attacks in real-time. It creates a baseline to identify legitimate system behavior while preventing cybercriminals from using penetration testing tools to perform reconnaissance.

    From a DevOps perspective, the Salt Security API Protection Platform integrates with tools such as Jira and Slack to ensure that remediation details are routed to the right development team in addition to helping track tickets to ensure remediation fixes are implemented. It also can be integrated with security information event management (SIEM) platforms from vendors such as Splunk and Sumo Logic to enable incident response for both DevSecOps and security operations teams.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to warrant additional security measures. Less clear is to what degree those security measures will be put in place by DevSecOps teams versus a security operations team.

    One way or another, however, the number of APIs that need to be secured is accelerating rapidly as organizations roll out a new generation of microservices-based applications that drive mission-critical digital business transformation initiatives. Each microservice has its own API that needs to be built and then secured. Unfortunately, most APIs are built by developers that don’t always have the greatest appreciation for security. As such, while more responsibility for API security is shifting left toward developers, many security teams would be well advised to make certain every API being deployed is fully secure.

  • Dynatrace Survey Sees Continuous Delivery Challenges Ahead

    Dynatrace Survey Sees Continuous Delivery Challenges Ahead

    A global survey of 1,300 application development and DevOps leaders conducted by the research firm Coleman Parkes on behalf of Dynatrace finds, on average, organizations expect to increase the frequency of their software releases by 58% over the next two years.

    Andreas Grabner, director of strategic partnerships at Dynatrace, an observability platform provider, said that while it’s clear organizations are embracing DevOps best practices to achieve that goal, the survey also found that more than a quarter (27%) of DevOps teams’ time is spent on manual continuous integration/continuous delivery (CI/CD) tasks. Nearly a quarter (22%) admit they’re often under so much pressure to meet the demand for application deployments that they must sacrifice code quality.

    In response, nearly two-thirds of respondents (62%) are investing in automation to eliminate manual tasks, while a similar percentage are looking to automate incident response processes. Another 45% are investing in observability tools, with nearly three-quarters (74%) noting that end-to-end observability will be essential to DevOps in the future.

    A full 98% also noted that extending DevOps to more applications will play a crucial role in driving digital transformation and optimizing customer experience. A total of 71% said a unified platform that seamlessly integrates their toolchains will be critical to scaling DevOps, while 79% said extending artificial intelligence to IT operations (AIOps) into the realm of DevOps is critical for their future success.

    Survey respondents, however, also identified siloed team cultures (75%) and application complexity (70%) as the primary barriers to achieving DevOps success. Organizations, as a result, are investing in the automation of manual CI/CD tasks (62%), eliminating manual incident response (62%) and end-to-end observability (45%).

    Grabner noted that, as more organizations build and deploy next-generation applications based on microservices constructed using containers and application programming interfaces (APIs), it will only become more challenging to automate DevOps processes. As part of an effort to reduce the cost of delivering those applications, Dynatrace donated Keptn, an open source enterprise-grade control plane for automating the continuous delivery of cloud-native applications, to the Cloud Native Computing Foundation (CNCF), added Grabner. The overall goal is to reduce the total cost of implementing DevOps as part of an effort to instrument more applications, he noted.

    While most organizations that have embraced DevOps have a good handle on how to implement continuous integration, achieving the continuous delivery side of the DevOps equation has proven to be more challenging. In the absence of standardization among the platforms, each application deployed on individual IT systems is a “snowflake,” in that it is unique to that platform. That issue, in part, is why so many IT teams still rely on manual processes to deploy applications.

    It’s only a matter of time before organizations begin to more aggressively automate the deployment of applications. That may become even easier to achieve if they standardize on a Kubernetes application programming interface (API) that can be implemented across any platform.

    In the meantime, however, it’s clear that, as the pace of digital business transformation increases, one of the most limiting factors organizations will encounter is the pace at which applications can be deployed and updated.

  • Postman Survey Shows Focus on Building and Deploying APIs

    Postman Survey Shows Focus on Building and Deploying APIs

    A survey of more than 28,000 developers and application programming interface (API) professionals published today by Postman found nearly half of respondents (49%) are now spending the majority of their time developing APIs. More than a quarter (28%) now spend 20 or more hours per week working with APIs.

    Kin Lane, chief evangelist for Postman, a provider of a platform for building APIs, said that shift reflects an increase in software development and integration activity that began at the start of the COVID-19 pandemic. Almost two-thirds of respondents (63%) said the pandemic somewhat or significantly affected their work, with almost half of those respondents noting that changes made with their organization were enabled and supported by APIs.

    Additionally, a full 94% of respondents said the investment of time and resources into APIs will increase or stay the same for the next 12 months. The biggest obstacle to creating APIs is lack of time (45%) while the biggest obstacle to consuming an API is lack of documentation (55%). In terms of API goals, the survey found that quality (80%), agility (66%) and reliability (65%) are the top three goals among survey respondents.

    However, the survey also noted only a third of respondents said they could build and deploy an API in anywhere from a single day to a week, with most requiring one week to a month. About one-third also said they deploy APIs to production between once per week and once per month. More than 80% of respondents noted that less than 25% of their changes fail while a similar percentage said they can recover in less than a day with a third reporting they fully recover in less than an hour.

    The Postman survey also found that more than three-quarters of respondents (76%) have less than five years of experience with API development. Only half of respondents indicated that they agree or strongly agree that the leadership of their API team has a clear sense of where their API practice should be in five years. However, microservices (58%) and Kubernetes (50%), containers (46%), serverless architecture (44%) and GraphQL (35%) were ranked among the technologies that respondents were most excited about heading into 2022.

    On the plus side, more than 60% of respondents felt their API leadership and governance teams demonstrated a “willingness to change” as well as duly considering “the interests and opinions of employees.” When it comes to regularly providing feedback and process, more than half of leadership and governance teams (53%) scored well.

    The top two ways API teams collaborate is via a dedicated collaboration platform (50%) or by publishing API artifacts to repositories such as GitLab, GitHub and Bitbucket (45%), according to the Postman survey. The most widely used DevOps tools are Jenkins (37%), Azure DevOps (26%), GitHub Actions (25%), AWS DevOps (23%) and GitLab Pipelines (22%).

    In terms of deploying APIs, continuous integration/continuous delivery (CI/CD) platforms are the most widely employed (57%), followed by deploying APIs in the cloud (38%), frameworks (34%) and custom-built deployment methods (27%).

    Just over 70% of respondents ranked security and performance as the top factors considered when integrating with an API. When producing an API, however, the top factors are integration with internal systems, integration with external systems, adding functionality to an internal system and enhancing functionality for an end customer. Similarly, when consuming an API the top factors are integration with external systems, adding functionality for end customers, adding functionality to internal systems and integration between internal systems.

    In general, Lane noted that, as more APIs are developed and deployed to drive various digital business transformation initiatives, organizations will need to pay more attention to API discovery and management. There’s a tendency for different teams within organizations to not only create redundant APIs but also forget about so-called zombie APIs that are no longer supported but can still be exploited by cybercriminals.

    Overall, Lane said the survey makes it clear more organizations are pursuing an API-first approach to digital transformation. The challenge now is managing all the APIs that can quickly become too much of a good thing.

  • How to Avoid the Most Common Online Service Costs 

    How to Avoid the Most Common Online Service Costs 

    Throughout the last year and a half, most organizations were forced to either create or develop their online service offerings at a rapid pace. Companies had to find alternate solutions to continue day-to-day operations in the transition to remote-first. Low development costs and the wide range of use cases have been primary factors in the continued rise of online services even as enterprises look to move back to the office. 

    Although the initial development costs are affordable to most global organizations, maintaining those workloads—such as internal self-service or software-as-a-service (SaaS) platforms—is a different story. Many enterprises fall victim to paying unnecessary expenses to keep their online services operating. When calculating the costs of these services, organizations often leave the costs of managing hardware out. In the event they are included, the cost breakdown is not typically accurate. 

    When transitioning to or enhancing online services, calculating the correct costs can be overwhelming. To avoid overpaying, companies need to properly assess the operational costs of their online services. Here’s how.

    Evaluate the Infrastructure

    First, determine what type of infrastructure fits best for the online offering or service. A popular trend is the “always-on” model, and with good reason. The success of online streaming services and high-availability digital workspaces encouraged enterprises to adopt this method. 

    However, it is important to note that these companies are successful with this type of business model because it fits best with their overall product and services offerings. Many organizations cannot thrive in an always-on style because they simply do not need to be always-on. After all, not every service needs to be available 24 hours a day. 

    If the online service is only needed during typical ‘office hours’ but can remain on standby after closing, the organization still needs to pay for those idle hours. These costs add up and can make for an unpleasant surprise when they show up on the monthly bill. Determine what the cost of using an always-on service will be for the organization before committing to it and weigh if it is necessary. Many times, an always-on service is not needed, and an alternate approach will do just fine. 

    Pay for What you Need

    The more users on a particular platform, the more data is used. Estimating the accurate amount of data use is a vital step in being cost-efficient. In many cases, organizations pay more than the necessary amount because of inaccurate calculations about how much data will be used. It is vital to assess data use regularly to make sure that customers have what they need without the business breaking the bank. 

    Saving money does not have to equal a poor quality of service. When paying for online services with an infrastructure-as-a-service (IaaS) provider, a business is paying for more than just a place to host its platform. IaaS providers also provide varying levels of support, allowing for organizations to take advantage of additional services at no extra cost. By partnering with an IaaS provider, an organization can experience speed, reliability and security without blowing the budget. 

    Assess if the Cloud is the Best Fit

    A common misconception is that online services are fully maintained in the cloud; however, that is not always the case. Building and testing services may require some operations take place in an on-premises location. An organization needs to evaluate whether on-premises is more cost-effective than developing its service in the cloud. Along with the potential for cost-effectiveness, on-premises solutions can sometimes prove to be more secure. Choosing on-premises or even a hybrid model for highly sensitive data may provide tighter security control. 

    Maintaining a service in the cloud can potentially transform an online business by offering flexible, scalable and cost-effective solutions. A scalable infrastructure becomes an imperative for a growing business, and with the cloud, services and consumption can grow as the business does. However, organizations need to consider their business requirements and see if their deployment decisions match the requirements for cloud or on-premises. 

    Evaluate your Total Cost

    Providers often give a basic estimate of total expenses, but it is always helpful to ask for your total cost of ownership. Looking at the total cost of ownership ensures clarity between the organization and the service provider. Overall, the most crucial best practice for avoiding unnecessary costs is to be aware of how your organization is spending money. 

    By assessing the above factors, organizations can cut unnecessary online service costs by only paying for what they need. An organization that is well-informed about its needs and use of resources is in a better position to succeed and scale their offerings—without breaking the bank. 

  • What 30 Years of Linux Taught the Software Industry

    What 30 Years of Linux Taught the Software Industry

    Linux has become the largest collaborative development project in the history of computing over the last 30 years. Reflecting on what made this possible and how its open source philosophy finally imposed itself in the industry can offer software vendors valuable lessons from this amazing success story.

    The web may not have reached full adulthood yet, but it has already crafted its own mythology.

    August 25, 1991: Linus Torvalds, a 21-year-old university student from Finland, writes a post to a Usenet group: “Hello everybody out there using minix — I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386 (486) AT clones […]”. A few weeks later, the project, which will eventually be known as Linux, is published for the first time.

    This is the starting point of an epic that few could have foreseen.

    Fast-forward 30 years and the Linux kernel isn’t only running on most of the web servers and smartphones around the globe, but it also supports virtually all of the much more recent cloud infrastructure. Without open source programs like Linux, cloud computing wouldn’t have happened.

    Among the major factors that propelled Linux to success is security. Today, the largest software companies in the world are taking open source security to new levels, but the Linux project was one of the first to emphasize this.

    How Linux Became the Backbone of the Modern IT World

    Brief History

    Open source predates the Linux project by many years and is arguably as old as software itself. Yet, it is the success of the latter that propelled this movement in the 1990s. When it was first submitted for contribution in 1991 by Torvalds, the Linux kernel was the GNU project’s ‘missing link’ to a completely free software operating system, which could be distributed and even sold without restrictions. In the following years, and as the project started to incorporate proprietary licensed components and grow in popularity, a clarification on the meaning of “free software” became necessary.

    This led to the coining of the term “open source” as we use it today, thanks in part to Eric Raymond’s seminal paper The Cathedral and the Bazaar, a “reflective analysis of the hacker community and free software principles.” Open source was chosen to qualify software in which the source code is available to the general public for use or modification from its original design, depending on the terms of the license. People may then download, modify and publish their version of source code (fork) back to the community.

    Open source projects started gaining traction in the late nineties thanks to the popularity of software like Apache HTTP Server, MySQL and PHP to run the first dynamic websites on the internet.

    Facts and Figures

    Today, not only is Linux powering most of the digital era, but open source has become the leading model for how we build and ship software. Though most people don’t realize it, much of the technology we rely on every day runs on free and open source software (FOSS). Phones, cars, planes and even many cutting-edge artificial intelligence programs use open source software. According to the Linux Foundation, 96.3% of the world’s top one million servers run on Linux and 95% of all cloud infrastructure operates on it. Other infrastructure also relies on open source: 70% of global mobile subscribers use devices running on networks built using ONAP (Open Network Automation Platform).

    Linux adoption is very high in professional IT, where it’s become a de facto standard, especially with the advent of the cloud era. In fact, 83.1% of developers said Linux is the platform they prefer to work on. This success is due, in large part, to the community that contributed to its source code since its creation: More than 15,000 developers from more than 1,500 companies. Linux went on to become, arguably, the biggest success story of the free software movement, proving that open source could lead to the creation of software as powerful as any sold by a corporation.

    The Linux Foundation, a non-profit technology consortium founded in 2000 to support the collaborative development of Linux and OS software projects, is itself a big success. It now has more than 100 projects under its umbrella, spread across technology sectors like artificial intelligence, autonomous vehicles, networking and security. Several subset foundations have also emerged over the years, including the Cloud Foundry Foundation, the influential Cloud Native Computing Foundation, and the recently announced Open Source Security Foundation. The Foundation estimates the total shared value created from the collective contributions of its community to a whopping $54.1 billion.

    All these achievements may not have been possible without the embrace of open source by the enterprise world, which may represent its biggest win.

    Enterprise Adoption

    Companies began to realize that many open source projects were easier and cheaper to implement than asking their developers to build the basic pieces of an internet business over and over again from scratch.

    Twenty years ago, most businesses ran atop proprietary software from Microsoft, Oracle and IBM, and the idea of collaborating on big software projects might have sounded laughable to them. Today, these companies, along with relative newcomers such as Google, Facebook and Amazon, are not only employing thousands of full-time contributors to work on open source projects like Linux, they also regularly choose to open source some of their state-of-the-art projects; from Google Brain’s machine learning platform TensorFlow and container orchestration platform Kubernetes to Facebook’s React.

    There’s no question that open source software created a new wave of business opportunities. As more companies took an interest in open source projects, they realized they didn’t necessarily have the in-house expertise to manage those projects themselves and turned to startups and larger companies for help.

    Even Microsoft, which famously warred against the very concept of Linux for nearly a decade, made a strategic shift to embrace open source in the 2010s, led by CEO Satya Nadella. The IT giant finally joined the Linux Foundation in 2016 and acquired GitHub, the largest host for open source projects, two years later. It has since become one of the biggest sponsors of open source projects.

    As a consequence, the stakes have been raised for open source software, which is the engine powering the shift toward the cloud for virtually every company. In this context, security is becoming a topic of the utmost importance, and the commitment to secure the open source ecosystem is growing fast.

    Setting a Standard for Security and Trust

    Open Source Security Issues

    Following the OSS adoption boom, the sustainability, stability and security of these software packages is now a major concern for every company that uses them.

    The Census II report on structural and security complexities in the modern-day supply chain “where open source is pervasive but not always understood” revealed two concerning trends that could make FOSS more vulnerable to security breaches. First, the report said it is common to see popular packages published under individual developers’ accounts, raising the issue of security and reliability. Second, it is very common to see outdated versions of open source programs in use, meaning they contain fewer security patches.

    The 2021 OSSRA report agrees: “98% of the codebases audited over the past year contain at least one open source component, with open source comprising 75% of the code overall.” The report also noted that 85% of the audited codebases contained components “more than four years out of date”.

    This highlights the mounting security risk posed by “unmanaged” open source: “84% of audited codebases containing open source components with known security vulnerabilities, up from 75% the previous year. Similarly, 60% of the codebases contained high-risk vulnerabilities, compared to 49% just 12 months prior.” Not only is the security posture affected, but there are also compliance issues that can arise from unsupervised integration of open source content because licenses can be conflicting or even absent.

    Because large corporations are now a big part of the open source ecosystem, their sponsorship is a welcome source of financing for many people whose work had been done for free until now, yet it may not be enough. The open source community is well-known for its commitment to independence, its sense of belonging and its self-sufficiency, and expecting contributors to voluntarily address security issues is unlikely to succeed.

    This is where the experience of building Linux over 30 years and coordinating the work of thousands of individual contributors may be an example to follow.

    Linux Foundations

    In Linux kernel development, security is taken very seriously. Because it is an underlying layer for so many public and private software ‘bricks’ in the digital world means that any mistake can cost millions to businesses, if not lives. Since the beginning, it has adopted a decentralized development approach with a large number of contributors collaborating continuously. Therefore, it has consolidated a strong peer-reviewing process as the community development effort grew and expanded.

    The last stable release at the time of writing is 5.14, released on August 29th, 2021, only a few days before the 30th birthday of the project. The most important features in the release are security-related: One is intended to help mitigate processor-level vulnerabilities like Spectre and Meltdown and the other concerns system memory protection, which is a primary attack surface to exploit. Each Linux kernel release sees close to 100 new fixes per week committed by individuals and professionals from the likes of Intel, AMD, IBM, Oracle and Samsung.

    With such broad adoption and long history, the Linux project has reached a level of maturity that few, if any, other FOSS projects have seen. The review process and release model have built confidence for numerous downstream vendors. Although the world is not perfect and it is arguably difficult for them to keep up with such a high rate of change, they can at least benefit from strong security enforcement mechanisms and they can adapt their security posture in concordance to their “risk appetite”: Vendors are able to do the calculus of determining how old a kernel they can tolerate exposing users to.

    Pushing the Boundaries of Open Source Security

    Heartbleed and the Fragility of OS Security

    In April 2014, a major security incident affecting the OpenSSL cryptography library; disclosed as “Heartbleed.” The developer who introduced the bug acknowledged that, though he was working on the project with a handful of other engineers:

    “I am responsible for the error because I wrote the code and missed the necessary validation by an oversight. Unfortunately, this mistake also slipped through the review process and therefore made its way into the released version.” OpenSSL, an open source project, is widely used to implement the Transport Layer Security (TLS) protocol. In other words, it’s a fundamental piece used to secure a large part of the web.

    Open source was seen as fundamentally secure for a long time because the more people examine a line of code, the better the chances of spotting any weakness. Additionally, this model prevents “security by obscurity,” whereby the bulk of the protection comes from people not knowing how the security software works—which can result in the whole edifice tumbling down if that confidential information is released or discovered externally.

    This incident was a major turning point for a large share of the biggest web corporations: They realized that many open source technologies underpinning their core operations could not be “assumed to be secure” anymore. Any human error could have huge implications; therefore, a specific effort had to be made to improve the security in this specific space.

    A New Era for Open Source

    As we advance in an era where open source is omnipresent in codebases, tooling, networks and infrastructure and is even in fields other than software, security awareness is starting to take hold. But it needs a lot more work.

    A big part of the challenge, to begin with, is for the industry to understand the scope of the problem.

    Google just announced that it will be committing “$100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities.”

    The Secure Open Source (SOS) pilot program, run by the Linux Foundation, will reward developers for enhancing the security of critical open source projects that we all depend on.

    In doing so, Google leads the way in enlarging the financial sponsorship of big players like companies and governments — which are increasingly sponsoring open source both directly and indirectly. However, they also recommend that organizations “understand the impact they have on the future of the FOSS ecosystem and follow a few guiding principles.”

    What could these principles look like?

    A Roadmap to Safely Use and Contribute to Open Source

    The Linux Foundation proposed a specific Trust and Security Initiative which describes a collection of eight best practices (with three degrees of maturity) open source teams should use to secure the software they produce as well as by a larger audience to “raise the collective security bar.” Here they are:

    • Clarifying the roles and responsibilities, and making sure everyone is aware of their security responsibilities across the organization.
    • Setting up a security policy for everyone; in other words, a clear north star for all members of the organization.
    • ‘Know your contributors’ is defined as a set of practices to make risk-based decisions on who to trust and fight offensive cyberwarfare techniques, such as the poisoning of upstream code.
    • Locking down the software supply chain: This has become a preferred target as adversaries clearly understood that they can have a bigger and more effective impact with less effort than targeting individual systems.
    • Provide technical security guidance to narrow potential solutions down to the more appropriate ones in terms of security.
    • Deploy security playbooks to define how to do specific security processes, specifically incident response and vulnerability management processes, like creating roles and responsibilities or publishing security policies. This may feel formal, antiquated and old-school but having pre-defined playbooks means that teams can focus on shipping software and not learning how to do security, especially at the least convenient and most stressful time.
    • Develop security testing techniques with automated testing strongly recommended since it scales better, has less friction and less cost to the teams and aligns well to modern continuous delivery pipelines.

    However, the authors of the guide are aware that some major challenges are still facing the industry and, as such, need to be addressed. They mention:

    • The lack of open source security testing tools
    • The fact that open source package distribution is broken
    • The fact that the CVE format for vulnerability disclosure is also broken
    • The lack of a standard for a security build certificate which would allow any consumer to transparently verify that a product or component complies with the announced specifications

    “The types of verification can and should include the use of automated security tools like SAST, DAST and SCA, as well as verification of security processes like the presence of security readmes in repos and that security response emails are valid.”

    A scheme like this could have a significant and lasting effect on the security quality of open source software and the internet at large.

    The Linux project, born 30 years ago, is present in all layers of the modern software stack today. It is used by all the largest server clusters powering the modern web and any business going digital will use it at some point. This unparalleled longevity and success have demonstrated that the open source model was compatible with the requirements of enterprise-grade services and economically viable. Now that open source is all the rage in the software industry, a consensus and action plan on how to ensure the sustainability of this ecosystem becomes urgent. The top priority for businesses that depend on it is to adopt strong application security guidelines, like the ones promoted by the Linux Foundation, which have proven their value.

    One last note on the nature of open source: As businesses are now much more bound by the common use of open source components to build upon, they should not fall into the “tragedy of the commons” trap. This would mean waiting until others take action; for instance, to improve the global software security landscape. This might be one of the biggest challenges confronting our highly collaborative industry.

  • Signals

    Signals