We strive to build security into our applications and services in every phase of the DevSecOps engineering cycle. In this post, I want to address how the distributed engineering teams and the central security teams can join forces in the testing phase. I also want to discuss the advantage of their combined efforts in the DevSecOps model shown below.
Distributed applications security testing
In the Oracle Cloud SaaS infrastructure, security QA testing of our applications happens in the test phase of the SaaS development cycle. In other engineering environments, depending on the complexity, these static security analysis functions are ideally performed in the build phase.
Regardless of the phase, all distributed security QA teams need to continuously perform certain functions as part of the standard engineering cycle. At Oracle, these QA teams are in the individual lines of business and are responsible for the following functions:
Centralized security testing
The central security organization also performs critical security testing as part of a preproduction or release phase of the DevSecOps cycle. At Oracle, this central org is SaaS Cloud Security (SCS). Some of the most important functions that it performs are:
Power of the combined security teams
The QA teams in the lines of business and the SCS organization are equally governed and guided by the central corporate architecture and product security organizations that oversee all products at Oracle. The combination of the two security teams provides a holistic view and assessment of products and services in the cloud.
This aggregate approach promotes and reinforces a “” SaaS security posture. We embrace and continuously leverage all phases of the DevSecOps engineering cycle to identify, review, and mitigate all risks in many phases in the DevSecOps framework.
Please reference for more context and insight into the that we use at Oracle.