Cloud services have long been an integral part of the IT landscape. Companies of all sizes use them to flexibly operate applications, store data or accelerate development processes. But with the benefits come new risks. Anyone who moves their data and applications to the cloud is relying on a shared infrastructure that is operated by external parties. One key question is: how can security-relevant cloud applications be protected and their security fundamentally assessed?
If the area of application requires certification of the cloud application, its security assessment is still independent of the circumstances at the cloud service provider. Industry-specific cloud audits provide orientation for this, but how meaningful can these provide support in a certification process? Particularly in dynamic environments in which software is constantly being further developed and immediately pushed into operation (CI/CD), security gaps arise that traditional certifications cannot fully cover.
Shared responsibility – shared responsibility in the cloud
A central concept in the secure use of cloud applications is the shared responsibility model.
- Cloud service providers (CSP) take care of the operation of the infrastructure: servers, storage, network and virtualization.
- Customers are responsible for their own applications, data and the correct configuration.
The interaction is crucial: while the provider must ensure that the platform is stable and trustworthy, it is up to the customer to secure their own software. One example of this is the isolation of containers. If several applications are operated in parallel on the same platform, they must be prevented from influencing each other or exchanging data in an uncontrolled manner.
The limits of traditional certifications
The Common Criteria have been a recognized standard for the evaluation of IT security products for many years. They allow products to be tested in a structured manner, but they have their limits when it comes to cloud environments.
One problem is the timeline:
- Certifications confirm the security status at the time of testing.
- However, cloud environments are constantly evolving. New functions, updates or configuration changes can alter security at any time.
The situation is similar with cloud-specific audits such as FedRAMP in the USA or the BSI C5 in Germany. They check whether a provider complies with certain minimum requirements. But here too, the reports reflect the past. By the time an audit is completed, new risks may have long since emerged. This time lag is known as an assurance gap – a gap between documented and actual security.
Typical risks in the cloud
Practice shows that many security problems are less due to a lack of standards than to everyday misconfigurations and a lack of transparency. Here are a few examples:
- Incorrect settings in containers or orchestration tools (OWASP CNAS-1) can allow unwanted access from outside.
- Misuse of Kubernetes credentials (OWASP K06) allows attackers to take over central control functions.
- Known vulnerabilities such as IngressNightmare (CVE-2025-1974), which occurred in 2025, show that important components of the cloud itself are also the target of attacks.
- Software supply chain risks: Modern applications rely on countless libraries and third-party components. Without a complete software bill of materials (SBOM), it is almost impossible to understand which dependencies are in the system and which vulnerabilities may be introduced as a result.
These examples make it clear: Cloud security is not just a question of technology, but also of processes and transparency.
Ways to close security gaps
How can companies close these gaps? There is no simple solution, but there are several approaches:
- Combination of certification and audit
Certificates such as the Common Criteria create a solid basis. However, companies should also rely on continuous audits that regularly check ongoing operations.
- Establish DevSecOps
Security should not only be tested at the end. In today’s development cycles, not only should new features be tested, but vulnerabilities should also be actively sought – from simple automated checks to penetration tests and ongoing monitoring.
- Clear contracts with cloud providers
Companies should specify in service contracts which security requirements the cloud provider must guarantee. For example, additional requirements from a Common Criteria certification process can be included in the agreements.
- Clearly define shared responsibility
To ensure that shared responsibility is practiced, this must also be documented in annual audits. This creates confidence that the operation of a certified IT security product is also carried out in a secure manner.
Conclusion: Security as a continuous process
Cloud security is not a one-off project that is completed with one certification. Instead, it requires constant attention and adaptation. Standards and audits are important building blocks: they provide orientation, but they do not guarantee that attacks on day-to-day cloud business will be effectively warded off.
Companies should be aware that security in the cloud is based on shared responsibility. The provider provides the infrastructure, the customer must secure their applications and configurations. Trust in the cloud can only be built if both sides deliver – and not just once, but by continuously reviewing and disclosing.
