New technology is required to address unintended attack vectors, vulnerabilities and other issues in application code as part of the broad transition to cloud-native architecture. The proliferation of security roles within organizations not only increases conscientiousness, but also places a greater burden on stakeholders.
These tools provide a complete solution within one platform to address security challenges. Why are these tools important and how does it differ from existing technology?
Modern cloud architectures have been adopted by organizations all over the globe in recent years. They’ve moved away from building monolithic apps to a series or microservices that work within cloud containers. These microservices are distributed over many layers. Modern architecture is becoming more useful and offers significant advantages when it comes to designing, building, deploying, and maintaining applications in the cloud.
IDC researchAccording to the company, cloud-native apps will create over 500 million new apps by 2023. Container use is on a rise. GartnerAccording to estimates, 90% of global organizations will have containerized applications in production by 2026, up from 40% in 2021. Furthermore, 20% of all enterprise applications in 2026 will be running in containers, up from 10% in 2020.
Cloud-native architecture allows your enterprise to unlock the full potential of your apps, giving them flexibility to respond to external and internal demands. It is becoming more digitally-focused and taking on related transformation initiatives that enterprises shift development to microservices, containerization, and especially considering the application modernization requirements.
However, cloud-native development requires new security technology. This security technology must be able to address both attack vectors and vulnerabilities in developers’ code. This raises two questions: who is responsible for protecting developers’ code? And what tools should they use?
Who is responsible for security?
In the past, infrastructure staff and application developers worked in separate areas. The practice of separating the two was common. Today, the boundary is blurred as the work is shared between all the stakeholders. This is also referred to in security terms. Moving leftThat is, Moving security testing efforts from operations to development earlier
This emerging approach places developers under greater security responsibility. It was created when companies realized that code cannot wait to run in a production environment before it is tested for weaknesses. It is much more efficient to test it early in development.
Another aspect of this process is the multiplicity of security roles. AppSecOps (DevSecOps), and product security are all responsible for alerts, control and resolution of various threats targeting enterprise applications. These significant changes do not make application development more simple for organizations. Developers are under increasing pressure to ship and build applications faster in today’s agile development model.
The blurring between responsibility and the transfer to developers of additional tasks creates a challenge and adds complexity. It can delay development rather than allow them to progress at the rapid pace required by businesses.
A Gitlab survey 2021This might give surprising answers to question, “Who owns application security?” It found that most operators professionals had little faith in developers’ ability to write secure code. Most developers felt they lack security guidance. It is not surprising that the survey found confusion among respondents regarding who owns security in the organization. 33% thought SecOps had the responsibility, 21% charged it to operations, and 29% placed it on developers. 29% believed everyone owned security.
In reality, everyone is accountable.
Cloud-native applications make it possible to analyze the flow of vulnerabilities within and between microservices. This is not a requirement but a critical threshold.
To 1) respond to security testing across all codes layers at any time and 2) facilitate high-quality, productive collaboration among various development and security stakeholders, organizations need to have accurate analysis and insights.
To enable distributed ownership and security, it is necessary to change the way everyone works together. Developers should be planning and implementing security while developing applications. This should include application testing (AST) cycles that find vulnerabilities long before they are released to production.
Guessing game
However, assessing code vulnerabilities can be difficult. Cloud-native technology is a combination of multiple code layers (e.g. clouds, clusters and containers, microservices), so testing requires several teams. Security teams, development teams are appraised of the implementation. DevOps team members must understand infrastructure.
There are two areas where cloud-native security is often emphasized when looking at how organizations decide with whom and where they should reside. The first is during pre-production/development, where security ownership is firmly in developers hands. The second focuses security during application production, or runtime. These stages are shared by security teams and DevOps.
During pre-production, integrating safety primarily refers to implementing AST. 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 – DASTThis results are based on external behaviour, such as a response to a dummy attacker, and not internal communication vulnerabilities. DAST often returns false-negative results due insufficient coverage and inability of tools to identify internal application vulnerability. They also have trouble identifying weaknesses that arise from internal communications between and within apps.
Static AST, (SAST)These tools analyze inactive source codes to find security vulnerabilities. SAST identifies and tests the source function in order to find vulnerabilities at the application layer. These tools test each application and its microservices separately, but they ignore the context and the whole picture. They may show multiple false-negative and false-positive results, due to their inability evaluate the entire context and flow of application data.
Interactive AST (IAST).This tool combines DAST with SAST techniques to improve accuracy. IAST provides a similar analysis to SAST and examines the process behaviour within a running application. These tools don’t provide a comprehensive view of communication between layers for cloud-native apps. They require significant development resources as well as a setup process that involves manual deployment, maintenance, and support for each component.
Multilayered, contextual risk assessment
To detect vulnerabilities in cloud-native apps, it is necessary to run each tool separately. They are not always synchronized and they don’t know how to cross-reference or use enriched data from different code layers in the environment.
Multi-layer, distributed code assessment requires a new approach. Tests with enriched data taken from the cloud, development, and orchestration layers yield comprehensive results.
This is why Oxeye has created a new platform. Advanced testing technology streamlines cloud security processes and aids once-isolated groups in their collaboration. It combines all AST methods with a new generation security control assessment (SCA).
Data enrichment is the best way to get accurate information about critical vulnerabilities. Oxeye enriches security check findings with data from all components and layers of the app. This allows Oxeye to find and verify multiple weaknesses in layered codes, from the developing application to cloud environments. The platform offers priority and reproduction steps to enable developers to quickly mitigate the problem.
This context-sensitive analysis of the surrounding components, microservices, as well as other infrastructure layers, provides reliable results with an inexhaustible accuracy. Every stage of the application development process provides a vulnerability context that helps everyone understand potential risks and how they might manifest. This allows teams to immediately focus on the most important things, which reduces remediation time.
Written by Dean Agron CEO and cofounder of Oxeye