R&S®Trusted Application Factory by Rohde & Schwarz Cybersecurity

Application architectures have shifted toward microservices and container-based deployments, with APIs serving as the connective tissue between services. This evolution enables granular, continuous updates by replacing or adding microservices without disrupting the broader system—provided APIs remain stable and backward compatible. For organizations, these architectures underpin agile development and DevSecOps, but they also expand the attack surface: every microservice exposes APIs and becomes a potential entry point. Risks include lateral “east-west” movement between services and attacks spanning OWASP Top 10 categories as well as credential stuffing and DevOps toolchain compromise.

Common defenses such as securing code repositories, CI/CD pipelines, and using SCA, SAST, and DAST help, as do API management/security tools and web application firewalls, but many of these operate outside individual microservices. The described need is to embed security deeper into cloud-native applications without requiring code changes or custom integrations.

Rohde & Schwarz Cybersecurity’s R&S®Trusted Application Factory addresses this by modularizing security into components running at the pod/container level, while leveraging central security engines that can run on-premises or in cloud deployments. It supports inline and sidecar modes and scales with application workload. Protection relies on context-rich configuration (YAML plus OpenAPI): traffic matching OpenAPI definitions is allowed, while anomalous or malicious payloads (e.g., SQL injection, command injection, path traversal) are blocked, logged, and alerted—using a positive security model to reduce false positives. It also supports outbound traffic inspection to reduce data loss risks. The solution integrates into CI/CD, generates policies at deployment, logs broadly, supports major clouds and container platforms, and is recommended for evaluation as part of a broader application security strategy.

• Microservices architectures and container-based deployments have become the new normal, with APIs interconnecting microservices.
• Continuous, granular updates commonly occur by replacing microservices with newer versions and adding new microservices.
• Stable, downward-compatible APIs allow other parts of a solution to remain unaffected during microservice changes.
• Each microservice exposing APIs broadens the attack surface and increases the risk of east-west lateral movement.
• SCA focuses on understanding components/modules within an application, including identifying exposure to Log4j/Log4Shell via component detection.
• SAST and DAST are used to identify vulnerabilities, with DAST analyzing runtime behavior.
• R&S®Trusted Application Factory runs security modules at the pod/container level and can operate in inline mode or sidecar mode.
• Security engines supporting analysis can be deployed on-premises or in the cloud, with management components optionally delivered as SaaS.
• OpenAPI-conforming traffic is allowed, while unexpected payloads and attacks such as SQL injection and path traversal are blocked, logged, and alerted.
• Supported environments include AWS, Microsoft Azure, GCP, Docker, Kubernetes, OpenShift, and integrations with GitLab and Jenkins.

• “As long as APIs remain stable (downward compatible), other parts of the solution remain unaffected.”
• “Securing agile, dynamic workloads where every microservice exposes APIs requires different approaches for software security than the traditional way of architecting and delivering IT services.”
• “But the way security must become implemented must become as granular as the architecture, and as agile and dynamic as DevOps is.”
• “The attack surface is broadening, and the risk of so-called east-west traffic, i.e., attackers moving from one microservice to the next, is growing.”
• “All these approaches sit outside of the software.”
• “There is a need for baking security deeper into the world of modern applications, ideally without requiring developers to change code or to create custom integrations.”
• “This is done by ‘modularizing the security engines’ into modules that run at the level of pods (groups of containers) or containers.”
• “Traffic conforming to the definitions in the OpenAPI file is allowed, while other traffic such as SQL injections, command injections, path traversals, or unexpected payloads are blocked, logged, and alerts are raised.”
• “By defining allowed traffic, a positive security model is applied, which helps in reducing false positives.”
• “Quality of security analysis depends on the quality of the YAML and OpenAPI files provided by the developers.”