--- title: Cloud PaaS through the lens of open source – opinion description: Through open source, PaaS vendors can offer transparency on critical vulnerabilities, and through a portfolio of providers, customers can cut their risks. url: https://canonical.com/blog/cloud-paas-through-the-lens-of-open-source-opinion?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Rob Gibbon](https://canonical.com/blog/author/robgibbon "More about Rob Gibbon") 30 August 2021 # Cloud PaaS through the lens of open source – opinion [Big Data](https://canonical.com/blog/tag/big-data) [cloud](https://canonical.com/blog/tag/cloud) [Open source](https://canonical.com/blog/tag/open-source) [paas](https://canonical.com/blog/tag/paas) [Security](https://canonical.com/blog/tag/security) --- Share the article **Opinion piece by Rob Gibbon – Product Manager at Canonical. All views expressed are the author’s own.** ## The open source perspective viz. PaaS Open source software, as the name suggests, is developed in the open. The software can be freely inspected by anyone, and can be freely patched as required to suit the security requirements of the organisation running it. Any publicly identified security issues are centrally triaged and tracked. Associated software patches are also developed and distributed in a coordinated manner. The process is based on broad collaboration between government agencies, open source software vendors, security researchers, community contributors and oftentimes the obligations set forth in the widely adopted GPL open source software license. Platform as a Service (PaaS) solutions, generally speaking, are developed as proprietary, black-box solutions. Whilst the software offered by the PaaS solution is sometimes free open source software, the provisioning and management solution surrounding the software is almost always proprietary to the PaaS vendor. The customer may have little to no visibility into the provisioning and management engine codebase and the problems that might exist therein, and is likely to depend on the PaaS vendor to fulfill many of their security obligations. PaaS providers have maintained an excellent security posture for many years. Exploits are rare, and when they are identified, the vendor’s response is usually rapid and decisive. But PaaS is still a relatively new technology in terms of general adoption, and where an exploit in PaaS is identified, its scope can be quite devastating for users of the service in question. “[ChaosDB](https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases)” for example, was a privilege escalation vulnerability identified on the popular Microsoft Azure CosmosDB platform, that potentially allowed attackers to gain access to database instances that had the “Jupyter Notebook” feature enabled. Whilst Microsoft acted responsibly and rapidly addressed the threat presented by ChaosDB, it is nevertheless an example of a PaaS vulnerability with potentially broad scope and far reaching consequences. I believe Microsoft acted commendably, but Microsoft also has the scale and the resources to be able to act in a decisive manner – something smaller or less experienced PaaS vendors might struggle to do. | | | --- | | **Juju – open source composable applications engine** [Juju](https://juju.is) is a free, open source engine from Canonical, the publishers of Ubuntu, for building composable applications. Juju offers application vendors and integrators the ability to rapidly assemble PaaS provisioning and management solutions for applications and has been used for deploying and operating diverse systems like Apache Spark, Kubernetes and MatterMost. [Learn more about Juju and Model-driven Operations.](https://juju.is) | ## PaaS and the shared responsibility model In the shared responsibility model of public cloud computing, the PaaS vendor is typically responsible for a great deal more of the security procedures and controls than in a classical on-premise or even cloud infrastructure as a service (IaaS) deployment – such as one founded on proven, mature open source software. Thus with PaaS the customer usually surrenders much more control and visibility, yet remains the accountable party. For many enterprises (for example, those that operate in licensed and strictly regulated verticals such as financial services,  telecommunications, or institutions directly accountable to the public and organisations that deliver safety critical services) the risks posed by the prospect of an attacker gaining full access to data platforms – especially those hosting secret, sensitive or personally identifiable citizen data – are likely to be unacceptable. For many others with perhaps less at stake, the risks presented by a security breach on a PaaS solution doubtless remain unpalatable. ## PaaS as open source software: my opinion From a security standpoint, I believe PaaS still has a way to go until it can match the level of procedural maturity and confidence that open source software deployments can offer to those accountable for enterprise information security. Whilst I firmly believe in the complementary premise of PaaS as a flexible and convenient customer option, as an open source proponent I advocate for vendors to develop PaaS provisioning and management systems in the public domain as open source software. By making their solutions available to public scrutiny, PaaS vendors can sponsor transparency, traceability and the timely resolution of critical vulnerabilities. Open source software offers PaaS vendors a proven path to engendering long term trust and supports customers in maintaining their accountability. By establishing a diversified portfolio of service providers and solutions, I believe customers can proactively minimize their risk of exposure. Hybrid and multi-cloud solution architectures that operate over the top of cloud service providers can be founded on robust, open source technologies and can be hardened according to customers’ own unique needs and security best practices. * Learn more about [Managed Application services](https://ubuntu.com/managed/apps) from Canonical * Learn more about Canonical [Managed Kubernetes and private cloud services](https://ubuntu.com/managed) * [Contact us](https://ubuntu.com/managed/apps#get-in-touch) to discuss your requirements [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### Canonical joins the Open Secure AI Alliance](https://canonical.com/blog/open-secure-ai-alliance) Canonical is now part of the Open Secure AI Alliance, announced by NVIDIA with partners across cloud computing, cybersecurity, enterprise software, open source foundations, and... [Canonical](https://canonical.com/blog/author/canonical) 28 August 2026 [### Januscape vulnerability CVE-2026-53359 mitigations available](https://canonical.com/blog/januscape-linux-vulnerability-mitigations-available) Introduction A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID... [seth-arnold](https://canonical.com/blog/author/seth-arnold) 11 July 2026 [### DirtyClone Linux kernel local privilege escalation vulnerability fixes available](https://canonical.com/blog/dirtyclone-linux-vulnerability-fixes-available) On June 25, 2026, JFrog published their research into CVE-2026-43503, referring to the vulnerability as DirtyClone. The vulnerability had previously been responsibly disclosed... [Luci Stanescu](https://canonical.com/blog/author/lucistanescu) 1 July 2026 [### pedit COW kernel local privilege escalation vulnerability mitigations](https://canonical.com/blog/pedit-cow-linux-vulnerability-fixes-available) Mitigations are available for the Linux vulnerability with CVE ID CVE-2026-46331. The CVE ID was assigned on June 16 2026 and highlighted as a local privilege escalation (LPE)... [Luci Stanescu](https://canonical.com/blog/author/lucistanescu) 1 July 2026