The broad transition to cloud-native architecture requires new technology related to unintended attack vectors and vulnerabilities residing in application code. At the same time, the proliferation of security roles within organizations creates conscientiousness but also places an increased burden on stakeholders.

To tackle these security challenges, new tools exist that provide a comprehensive response within a single platform. Why are these tools necessary and how does the platform differ from pre-existing technology?

Organizations across the globe have adopted advanced cloud architectures in recent years. They’ve transitioned from developing monolithic applications to a series of microservices functioning within cloud containers and spread over several layers. Modern architecture has become increasingly more useful, bringing significant advantages to designing, building, and deploying applications in the cloud.

IDC research says that “by 2023, over 500 million apps will be developed using cloud-native approaches.” Container use is on the upswing. Gartner estimates that “90% of global organizations will be running containerized applications in production by 2026 – up from 40% in 2021. In addition, by 2026, 20% of all enterprise applications will run in containers – up from fewer than 10% in 2020.”

Cloud-native architecture enables your enterprise to unleash the full potential of your applications, giving them flexibility in response to internal and external demands. And as enterprises become more digitally focused and take on related transformation initiatives, shifting development to microservices and containerization makes sense, especially considering application modernization requirements.

That said, development within an advanced cloud-native environment requires new security technology. The latter needs to fully address potential attack vectors as well as weaknesses in developers’ code. Given this, two questions to consider are: who’s in charge of securing developers' code and what are the right tools to use?

Who’s in charge of security?

In the past, application developers and infrastructure staff worked in separate arenas. Sparring between the two was all too common. Today that boundary is blurred, with the work being shared between the various stakeholders. With respect to security, this is referred to as “shifting left”; that is, moving security testing efforts earlier – from operations to the development realm.

This emergent approach puts increasing security responsibility on developers. It evolved when companies realized that code could no longer wait to run in a production environment before being tested for weaknesses. Rather, it’s far more efficient to test it earlier during development.

The multiplicity of security roles is another aspect of this process. AppSec, DevSecOps, and product security all share responsibility for alerts, control, and resolution of various threats that target enterprise applications. Such significant changes don’t make application development easier for organizations. In today's more agile development models, where speed and automation rule, developers are under pressure to build and ship applications faster than ever.

The blurring of responsibility and the transfer of additional tasks to developers creates a challenge and adds more complexity. It can potentially delay development processes rather than help advance them at the accelerated rate desired by business demands.

A 2021 Gitlab survey might present surprising answers to the question, “Who owns application security?” It found that most operations pros lacked faith in developers’ ability to write secure code. Meanwhile, most developers felt they lacked proper security guidance. Not surprisingly, the study found confusion among respondents as to who actually owns security within the organization. While 33% thought SecOps did, 21% placed the responsibility on developers, 12% charged it to operations, and the remaining 29% thought everyone owned security.

In reality, everyone is responsible.

With cloud-native applications, analyzing the flow of vulnerabilities between and within microservices is no longer a functional requirement, but rather presents a critical threshold.

Organizations need accurate analysis and insights to 1) respond to security testing across all code layers at any point in time, and 2) enable high-quality, productive collaboration between various development and security stakeholders.

Thus, a change in approach is needed – a method by which all can work in a coordinated manner to enable in-depth security processes and distributed ownership. Ideally, developers should be planning and implementing security while coding applications. This should include application security testing (AST) cycles to find vulnerabilities long before they make it to production.

Guessing game

But assessing code vulnerabilities is complex. Cloud-native technology combines several code layers (e.g., cloud, clusters, containers, microservices), such that your testing process really requires several teams: security teams, development teams appraised of the implementation, and DevOps teams that understand infrastructure.

Looking at how most organizations decide with whom and where cloud-native application security should reside, there are two places where it’s typically emphasized. The first is during pre-production/development, where security ownership is firmly in developers’ hands. The second focuses on security during application production or runtime. Both DevOps and security teams own these stages.

During pre-production, integrating security mainly refers to implementing AST (Application Security Testing). Such tools partially meet the vulnerabilities assessment requirement in a two-pronged approach: automatically examine code components before app construction/distribution and active code testing that attempts to break an application from an attacker's point of view.

The three AST categories

Dynamic AST (DAST) – Shows results based on external behaviour (e.g., response to a dummy attack) rather than examining internal communication vulnerabilities. DAST often displays false-negative results due to insufficient coverage and the tools’ inability to identify internal application vulnerabilities. They also have difficulty defining weaknesses that originate from internal communications within and between apps.

Static AST (SAST) – In search of scenarios that point to security breaches, these tools analyze inactive source code. To find application layer vulnerabilities, SAST identifies the source function. Such tools separately test each application and its microservices but ignore context and the big picture. They might show multiple false-negative or false-positive results due to their inability to evaluate the full context and application data flow.

Interactive AST (IAST) – Such a tool combines DAST and SAST techniques to increase accuracy. Providing an analysis similar to SAST, IAST examines process behaviour inside a running application. But for cloud-native apps, such tools don’t have a wide view of the communication between layered components. They also require a setup process that includes manual deployment and maintenance for each app component, along with significant development resources.

Multilayered, contextual risk assessment

As described, existing AST solutions require running each tool separately to detect code vulnerabilities in cloud-native apps. They aren’t always synchronized with one another, nor do they know how to cross-reference and use enriched data from other code layers in the environment.

Thus, assessing multi-layer, distributed code requires a new approach and toolset. Testing with enriched data pulled from the development, cloud, and orchestration layers provide comprehensive results.

Oxeye has launched a new platform to meet this increasing need. Advanced testing technology streamlines cloud-native security processes, thereby assisting once-isolated teams in their collaboration effort. It essentially combines all AST methodologies with a new generation of security control assessment (SCA) capabilities.

Data enrichment provides the most accurate insights into critical vulnerabilities. By enriching security check findings with data gleaned from all app components and layers, Oxeye finds and verifies multiple weaknesses within layered code – from the developing application to the cloud environment. And for effective and rapid mitigation by development teams, the platform provides prioritization and reproduction steps.

Such context-sensitive analysis of surrounding components, additional microservices, and various infrastructure layers provides reliable results with infinitely high accuracy. The vulnerability context at each application development stage helps everyone to better understand risks and their materialization. Teams can immediately focus on what is most important, thereby shortening remediation time.

Written by Dean Agron, CEO and co-founder of Oxeye