Taking advantage of Software-as-a-Service (SaaS) without losing control over sensitive data is a longstanding dream. Companies often rely on third-party providers to protect their most sensitive data or workloads. However, this leads to compliance and trust issues. SaaS models based on confidential computing promise to resolve this conflict: Companies should be able to take advantage of the flexibility of SaaS without compromising the confidentiality of their data.
A security review I recently conducted, however, painted a different picture, because it is precisely these security promises that can lead to dangerous blind spots. If we assume that a platform is “secure by design”, we often stop scrutinizing the actual implementation.
In this blog post, I’d like to explain why confidential computing solutions should also be audited regularly and independently, and how companies can ensure the security of such solutions.
Table of Contents
An Introduction to Confidential Computing and Secure SaaS Models
To understand the implications of such blind trust, let’s briefly look at how confidential computing works:
- Traditional security measures protect data at rest through disk encryption and data in transit through protocols such as TLS.
- Confidential computing extends this protection to data in use by running applications on hosts with TPM-based attestation or within special, hardware-based Trusted Execution Environments (TEEs).
The core idea is that the exact state of all code that views or comes into contact with the data is known and verified. A hardware-backed cryptographic proof can be used to verify that the endpoint to which the data is sent is actually (and exclusively) running the expected firmware and software. TEEs can also provide additional protection mechanisms such as memory encryption.
Confidential SaaS Model
Software-as-a-Service (SaaS) providers are increasingly leveraging confidential computing to deliver zero-trust environments. In a confidential SaaS model, the provider offers an environment to which they themselves have no access, and the user can request a cryptographic proof – known as an “attestation quote” – from that environment. This quote verifies the underlying hardware and the exact state of the software loaded on it. Customers verify this quote against known measurements to ensure that they are interacting with the correct, uncompromised software before sending sensitive data.
Six-Month Blind Spot – How Confidential Computing Does Not Work
In theory, the confidential SaaS model offers very strong security, but it breaks down if the hosted code is flawed or opaque. During a recent security review of a service based on confidential computing, I discovered a critical anomaly in the provider’s “trusted” codebase. The deployment process included a dependency using a fixed cryptographic hash.
While pinning dependencies using a hash is a common security practice to prevent tampering with upstream sources, the source code associated with this specific hash was unpublished and completely unknown. Such unknown code could theoretically contain any malicious payloads, such as backdoors or data exfiltration.
This opaque dependency had been present in the production environment for more than six months. Throughout this entire period, neither customers nor partners – who had relied on and trusted the platform’s security – nor auditors noticed or questioned it. Since the hardware attestation successfully matched the measurements published by the provider, all parties involved assumed that the system was entirely trustworthy. However, the attestation only proved that the enclave executed the vendor’s exact code – it did not prove that the code was actually secure, written with good intentions, or free of malicious backdoors. In this case, the code turned out to be harmless, but no user who used the platform during those six months could have known that for certain.
Why Continuous Monitoring Is Absolutely Essential
The fact that the unknown, missing code was not detected or reported paints a clear picture: Even organizations that are security-conscious enough to opt for a SaaS model based on confidential computing do not fully understand the trust model and its implications. When a company opts for a confidential computing SaaS model, there is no “evaluate once” or “evaluate every few years” approach, as there is with a standard service provider.
The only way to fully leverage the security benefits of this approach is to conduct a security review for EVERY release of the platform.
Yes, this is time-consuming. But it’s also the only way to ensure full trust in the application. If regular audits aren’t conducted, there’s no difference in terms of the actual level of trust compared to a standard SaaS service – you’re simply hoping that the providers are doing the right thing.
If attackers or malicious insiders manage to inject malicious code (whether published or unpublished) into the approved build process, confident computing will perfectly protect and execute this malware – and the attestation will confirm that this code is being executed.
Limitations of AI-Powered Security Reviews
Fortunately, certain code and security analyses can now be supported or partially automated by AI. However, it is important to keep in mind that AI-assisted reviews are not error-free.
In my security review, the analysis was also supported by AI. Although the system correctly identified the existing dependencies, it classified them as non-critical – even though the entire project and the relevant trust relationships were available as context. This shows that even AI-based assessments have blind spots and that expert interpretation by security professionals therefore remains essential.
How Companies Can Properly Secure Confidential Computing SaaS Models
So what should you do to benefit from a SaaS service based on confidential computing? I recommend the following steps:
- Demand total transparency: Reproducible builds are the bare minimum. Everything that is executed or loaded within the trusted environment should be visible and verifiable. If the service is built on a specific platform, that platform should also be included.
- Demand an audit-friendly lifecycle: All planned deployment changes (including code) should be released at least a few days – preferably at least a week – before go-live; emergency changes should be clearly scoped and easy to verify. All changes should be clearly traceable and linked to a change log or similar tool.
- Review every release: Following an initial, thorough manual security review, all changes for each individual release should be reviewed. If some of these reviews are to be automated using AI, it is important to ensure that a properly validated framework is used that enforces the correct checks being performed in the correct manner. In addition, regular manual reviews and a “human-in-the-loop” approach should continue to be used to ensure that all trust expectations are met.
- Monitor and verify: Changes to the provided manifests or hashes should be monitored and detected. It should be ensured that every hash listed in a deployment manifest corresponds to a release that has been verified. Availability should be carefully weighed against security risks to determine whether access to the service should be blocked in the event of an unexpected change.
The added trust in confidential computing SaaS models stems from transparency. If this transparency is not used to regularly verify that the solution is doing what is expected, there is no real advantage over a traditional SaaS service.
Building Trust Together
Would you like to have your existing processes or solutions reviewed? Our cybersecurity specialists will provide you with comprehensive support:
