Empirical Evaluation of a DevSecOps Proxy Pipeline for Multi-Tier Web Applications

Abstract

The use of DevSecOps seeks to ensure that the functionality of securing software is incorporated throughout the software development life cycle, but the difference between the theoretical model and the empirically proven version, specifically for multi-tier web applications, remains wide. This research proposes the evaluation of a “proxy” DevSecOps pipeline, defined as an automated intermediary architecture that decouples intensive security scanning from the primary build flow to prevent bottlenecks. Designed specifically for multi-tier PHP-based web applications, the model leverages infrastructure as code (Terraform) and Static Application Security Testing (SAST) to ensure that security validation remains continuous without impeding the integration speed. This research utilized the Terraform model on the Amazon Web Services cloud platform, with three EC2 instances and Jenkins integration, and the use of many tools for the testing process, divided into the following experiments for DevSecOps functionality measurement: the first for the baseline efficiency process, the dynamic scaling process, the validation test for the fail-safe mechanism, and the accuracy process for the vulnerabilities’ detection. This research indicates that the process exhibited stability and consistency for the average execution times, which took 122.08 ± 1.69 s, and low values for the 5.04% additional cost for concurrent executions. The 100% activation process for the fail-safe mechanism for the injection of vulnerabilities indicates that the process took 41.82% of the total pipeline execution time, demonstrating that security validation is the most time-intensive part of the automated proxy workflow, and the low costs of 0.0047 dollars for the entire process, specifically for the infrastructure aspect. The false positives for the process were measured as 10–15%, and the low costs for the entire process, which took 0.56–0.58 s for the total process.

1. Introduction

The need to incorporate security processes into development cycles has become highly pressing in recent times, with the goal of achieving greater speed in delivery without sacrificing security. DevSecOps can be viewed as more of a method that integrates security into development and operation cycles to mitigate the weaknesses of traditional security approaches related to increased risk considerations that involve security only as the final endpoint [1,2,3]. Although there are immense benefits achievable through DevSecOps adoption, there are major hurdles to developing efficient pipelines.

While DevSecOps is theoretically mature, its empirical application faces a significant “adoption gap.” According to a Systematic Literature Review (SLR) of 54 primary studies, organizations face 21 distinct challenges, with tool integration (technical) and lack of specialized skills (human) being the most prevalent factors leading to pipeline abandonment or failure. These challenges quantify the severity of the gap between theoretical frameworks and practical, scalable implementations in multi-tier environments [3].

Our proposed solution responds to these challenges with a practical assessment concerning a “proxy” DevSecOps pipeline intended to test PHP-based multi-tier Web applications. The “proxy” pipeline approach offers an efficient and automated processing mechanism, which stresses “Static Application Security Testing” without hampering integration with Continuous Integration/Continuous Delivery (CI/CD) methods [4,5]. Unlike traditional DevSecOps implementation methodologies that are complex to execute due to increased overheads, “proxy” pipelines are efficient with strong security checkpoints.

Our proposed pipeline makes use of infrastructure-as-code concepts [6,7] to deploy itself on Amazon Web Services to create development, production, and Jenkins environment instances. As per this pipeline, there are various security testing steps involved in the testing phase [8] related to unit testing, code analysis [9], code styling analysis, and vulnerability testing. The use of Jenkins to orchestrate these steps makes sure that security testing of committed code occurs before deployment.

We not only make theoretical contributions to architecture but also offer empirical validation for pipeline efficacy. We test our pipeline in four diverse settings: measuring its original efficiency, testing dynamic scaling in a scenario involving simultaneous developer commit activities, testing its safe mechanism functionality, and accuracy in security detection. These tests allow for empirical validation based on execution speed, system resource usage, and vulnerability detection rate per execution, among other parameters.

The value added by our work lies in filling a gap between our theoretical model of DevSecOps and experimental evidence related to implementing a DevSecOps pipeline. Although there are plenty of papers describing DevSecOps models and guidelines in terms of their principles or design details, there is not much related to experimental validation of individual DevSecOps pipeline implementations.

This proposed study looks to fulfill the following objectives:

• To evaluate a multi-tier PHP Web application proxy DevSecOps pipeline based on DevSecOps best practices, using infrastructure as code and Static Application Security Testing;
• To set up baselines concerning re-executions performed to gauge pipeline execution impacts;
• To gauge pipeline scalability to serve multiple developers concurrently working;
• To test safe, secure mechanisms to ensure system stability;
• To measure security accuracy;
• To define a cost analysis.

This manuscript will continue as follows: Section 2 will introduce basic concepts related to DevSecOps basics and related work. Section 3 will describe our materials and methods related to implementation details, our experimental design, and data collection. Section 4 will provide results related to our experimental design. Section 5 will interpret our results. Section 6 will conclude our paper with major takeaways, limitations of our solution, and future directions.

2. Related Work

Our current research was conducted by developing standardized criteria to measure the implementation of DevSecOps, where there have been considerably fewer resources in the literature, as surveyed in this work [1], where there are merely 20 non-overlapping measures between research, as opposed to the industry, where there is also no overlap between industry measures. The three main measures obtained include categories named organization, people and culture, process capabilities, and technology, where there has been inadequate representation of measures related to the business or organization rather than technology.

Comparison between general DevOps metrics and DevSecOps metrics shows important results. Amaro et al. [10] has identified general DevOps metrics, of which nearly half were related to security. This finding shows the importance of security in the development process, which requires less emphasis in the form of the DevSecOps process, indicating that the proper execution of the DevSecOps process might include the formulation of existing security practices in this regard [11].

The Framework of Business Index Concerning Security [12] was proposed in 2025 for showing reliable keys that can define the success of DevSecOps project implementations measures. This includes a number of important indexes, namely the Performance Security Index, which aims to link software security in terms of time, as well as monetary measures; the Security Coverage Index, which measures the completeness of security tests performed in the software; the Internal Security Index, which conducts a project-wide assessment for security, focusing also on training; the Early Security Index; the Training Security Index; the Collaboration DevSec Index; the Tool Robustness Index; and the Project Security and Performance Index.

The business factors are key considerations in the assessment of DevSecOps, aside from the security parameters. The importance of security as the core aim in the DevSecOps [13] approach should not underestimate the influence of the organizational needs pertaining to time, cost, and profit in the project feasibility, as well as its acceptance by management. The reduced development time usually has a positive impact on profitability, though it must be balanced concerning the cost of security.

Since the World Wide Web was launched in the early 1990s, the technology environment for the deployment of web applications has provided key insights in terms of the adoption environment. Based on W3Techs, the key observations include the popularity of PHP as the most widely used server-side programming language, which has a usage share of 72.9%, the popularity of the web server software Nginx, which stands at 33.2%, while the adoption of the Unix operating system, which powers the web, amounts to 90.3%. The existence of Amazon Web Services represents a key player in the data center market. The adoption rate of PHP in the web development community gives rise to unique security challenges, as well as opportunities. One of the most frequent applications of web applications based on PHP technology involves the usage of Content Management Systems, bringing forth normalized architectures, along with possible vulnerabilities. The maturity levels of the existing PHP security testing tools help in SAST implementations [14].

3. Our Approach

3.1. Implementation Architecture

3.1.1. Infrastructure

Our implementation focuses on a multi-tier PHP web application on an established commercial CMS system, with sufficient complexity that mirrors the complexity of an enterprise system. The CMS choice utilizes well-established and battle-hardened system architectures that have benefited significantly through community development, so that research can concentrate on advanced security and performance issues in place of application-level issues. The application deployment on Amazon cloud builds a production-level environment with full-service settings that facilitate superior performance, as well as proper handling of requests.

The experimental setup utilizes three Amazon EC2 instances with distinct settings. The development environment caters to a requirement of 4 Gb RAM, two virtual CPUs, and 10 gibibytes of storage, with the operating system being CentOS version 7. The software environment consists of PHP version 7.0.0; Percona Server MySQL version 5.6; the nginx web server software versioned at 1.24.0; the Varnish reverse-proxy application versioned at 5.2; and Redis and Memcached used as the cache layer, with RAM stores implemented using Redis and Memcached technologies. Additionally, the experiment utilizes the Sphinx Search Engine versioned at 2.2.1 and the HHVM Virtual Machine versioned at 3.22.0. The production environment matches the settings of the development environment with identical settings that suffice the concept of disparity-free testing with identical settings on different environments. The production system thus requires the same environment requirements with identical settings that exclude disparity as a variable factor during the experiments aimed at determining the performance of the environment. The third setup utilizes the same experiment environment with distinct settings. Infrastructure setup utilizes the power of Terraform to enable the infrastructure-as-code approach. This involves the creation of three Amazon Web Service instances of type EC2 with proper Virtual Private Cloud and subnetting settings configured within the infrastructure setup of the cloud environment. The setup of the Jenkins environment incorporates automated setup scripts utilizing the user data approach that allows the environment to operate as soon as it is set up.

To distinguish the proposed proxy model from traditional DevSecOps implementations,

Table 1. Traditional DevSecops pipeline vs. proposed proxy pipeline.

Feature	Traditional DevSecOps Pipeline	Proposed Proxy Pipeline (This Study)
Integration Logic	Direct synchronous security gates in the CI flow.	Intermediary “proxy” logic (asynchronous validation).
Orchestration	Complex, multi-tool dependency chains.	Terraform-based automated infrastructure.
Execution Logic	Synchronous/Blocking gates	Asynchronous “proxy” layer
Detection Time	Variable	(0.58 s) Optimized
Execution Time	Often ranges from 20 to 60+ min.	122.08 s (average total runtime)
Operational Cost	High (Requires dedicated security engineers).	Minimal ($0.0047 per run) via EC2 automation.

outlines the architectural and operational differences.

The Static Application Security Testing pipeline we implemented follows standard Jenkins orchestration best practices. This makes it easy to measure the per-tool resource consumption of the security testing tools—a crucial element of the cost analysis. PHPStan, PHPMD, and SonarQube utilize their default rule sets to perform security testing. PHP Parallel Lint offers tool-level parallelization of security tests, allowing for the simultaneous analysis of several PHP files using a single tool execution. Jenkins aggregates the output of all security testing tools into a single log file for the developers to review. This is a more appropriate approach for security teams working within the small-development-team scenario we targeted, as they would be less inclined to use automated conflict resolution and would instead want to review the output of security tests to avoid false-negative results due to tool output filtering.

3.1.2. Pipeline

The DevSecOps proxy pipeline consists of six stages of tasks that guarantee rigorous testing of the code before deployment into the production environment. This ensures that the nature of the development meets the highest production requirements. The first step of the pipeline consists of a code checkout and the initial compilation of the code under development. The second step of the pipeline involves the execution of the automated tests; this comprises the execution of the unit tests that ascertain the functionality of the code and the analysis of the code based on metrics of its quality, which include the measurement of the code’s length, the complexity of the code according to the cyclomatic complexity metric, and the maintainability of the code based on its index. The third step of the DevSecOps pipeline entails the execution of the security scan using PHP-specific security scanning tools. The fourth step of the pipeline involves the execution of the performance scan of the web server that tests the reaction of the application when subjected to hypothetical loading. The fifth step of the pipeline comprises the deployment of the code into the production environment, which involves the compilation of the code with the inclusion of the optimization requirements of the production environment. Finally, the sixth step highlights database operations such as migration, data inserting, and data refreshing. One of the most important architectural considerations deals with the scope of security testing that should take place within the proxy pipeline. Static Application Security Testing is conducted within the proxy pipeline because of its ability to offer immediate results during the development phases [15] of the application life cycle, whereas Dynamic Application Security Testing occurs only in the production environment.

3.1.3. Integrating Static Application Security Testing Features

SAST [16] automation involves the integration of various specialized tools using the Jenkins automation environment. Unit testing incorporates the usage of PHPUnit with the purpose of performing functionality-based testing, with the guarantee that changes made in the code do not affect the expected functionalities. Code analysis incorporates the usage of PHP Code Analyzer with the purpose of conducting standard code analysis reviews; PHP LOC with the purpose of measuring the lines of code metrics of the code; PHP Static Analyzer with the purpose of pinpointing potential coding errors through the application of static code analysis reviews; PHP Testability with the purpose of determining the maintainability aspects of the code functions; PHP Depend with the purpose of determining the code dependence and coupling characteristics that may exist within the code; PHP Pre-Deprecation Detector with the purpose of defining the usage of the older PHP coding functionalities within the codes currently used; PHP Post-Deprecation Detector with the purpose of finding the functionalities that may change due to the different versions of the PHP coding system currently used; and PHPStan with the purpose of conducting enhanced type-checking. Style testing utilizes PHP Mess Detector for detection of variables with unused arguments and cyclomatic complexity metrics, PHP Code Sniffer for adherence to coding standard ruleset requirements, PHP Copy Paste Detector for detection of copied code segments, PHP Dead Code Detector for detection of dead code that can safely be removed, and PHP Parallel-Lint extensions that enable parallel lint syntax checking of multiple PHP files. Security testing utilizes Local PHP Security Checker with Composer Dependency Scanner, which scans the composer-used packages with the PHP Security Scanner detection of malicious patterns of code and security holes, which include the misuse of eval functions, SQL injections, cross-site scripts, remote code execution scripts, and hard-coded sensitive values. All of these tools run on standardized pipeline phases with particular command calls. This setup ensures that whenever the developers commit their codes to the repository, the pipeline automatically carries out the complete security and quality testing on the codes. This makes the testing [17] process an internal part of the software development process.

To minimize the performance bottleneck, the SAST toolchain utilizes parallel processing logic. Specifically, PHP Parallel-Lint is used to check file syntax concurrently across the multi-tier application. Rule selection is triggered automatically upon code commits via Jenkins. Conflicting results between tools (e.g., PHPStan vs. PHPUnit) are aggregated into a single XML/JSON report to provide developers with a unified vulnerability view [18]. Scanning is performed in an aggregated block to ensure that the developer receives a single, comprehensive security report, which minimizes context switching compared to multiple individual tool alerts.

3.2. Experimental Design

3.2.1. Pipeline Efficiency Baseline

This scenario achieves performance measures based on 20 successive executions of the pipeline with an identical environment, with no code changes made in between. Every pipeline measurement marks distinct timing information for each stage, such as checkout time, build time, running unit tests, code analysis time, style test time, security scan time, performance test, production build, deployment time, and database migration. Overall end-to-end pipeline running time is computed for each iteration. It aims to determine whether there is convergence on these running times to some fixed average, which is crucial for any production environment. After the establishment of baselines, we incorporate code modifications representing real-world development changes, which include new features developed, requiring changes to multiple files in applications. We proceed to carry out 20 more iterations in the pipeline based on the new codebase. Comparative analysis is employed to ascertain the code modifications effect on pipeline running times in regard to answering our research question on whether typical development changes affect the performance in any way. PHP 7.0 was intentionally chosen to represent Legacy Technical Debt. This choice validates the pipeline’s effectiveness in detecting vulnerabilities in older, unsupported environments, which is a high-priority challenge in industrial security migrations [3].

3.2.2. Dynamic Scaling Evaluation

It consists of three parallel pipeline runs to simulate parallel commits to different branches by different developers. These three parallel runs will have the same infrastructure setups running on Terraform to enable comparison. These commits will be triggered in short intervals to maintain real-world team collaboration settings. Each parallel pipeline run records the same timing data, just like in Scenario 1. It intends to analyze scalability in pipeline executions, as well as any resource contentions, in realistic scenarios involving multiple developers. Data from running scripts concurrently is compared to running scripts individually to measure any performance loss, if there is any, during concurrent running. Resources such as CPU utilization, memory, and network I/O are tracked via a natively prepared script while running scripts concurrently.

3.2.3. Fail-Safe Mechanism Validation

It means checking the efficacy of security in the pipeline by incorporating security bugs in code commits. These security bugs consist of typical PHP code security bugs, such as calling an eval function for remote code execution, SQL injection attacks via string concatenations in SQL statements, XSS attacks in PHP via unescaped output, storing password information in code, and other vulnerable escaping mechanisms that could result in bypassing XSS attacks. The goal consists of verifying that the pipeline properly detects security concerns with failure responses in place to safely end pipeline runs in case of such detection. The expected behavior for the pipeline would entail failure on detection of security concerns; code halts on detection from progressing to other environments; and report generation indicating security concerns, with mentions of code files and lines in execution logs, which, in some failure scenarios, would not have been cleaned up.

3.2.4. Security Detection Effectiveness

Within this situation, the accuracy of Static Application Security Testing will be assessed based on observation to see how it detects security vulnerabilities during different executions of the pipeline with different conditions in the code. Its objective is to understand its reliability and to eliminate any false positives. The evaluation goal is to involve the pipeline on the application to examine the vulnerability detection models. Data is collected for each case concerning the tools identified and the accuracy of vulnerability identification. These results validate, in an empirical fashion, not only the comprehensiveness of security testing via pipelines, but also their limitations in their present tool setups.

3.2.5. Rationale for Parameter Selection

The reason for choosing parameter selection of test for experiments is based on balancing their significance to statistics with their feasibility. A total of twenty executions for each pipeline were chosen to provide enough iterations for averaging while being project-time feasible. These parameters will allow for identifying performance differences in a statistically significant manner. It is assumed that three other developers, representing a small group, would be enough for testing scalability, not requiring excessive project setup for simulation. These parameters were chosen with research needs in mind.

To evaluate scalability, the pipeline was tested under concurrent load from three developers. Results showed that while execution time increased by only 5.04% (from 122 s to 128 s), memory utilization on the AWS T2.micro instance peaked at 88%. This identifies memory as the primary factor affecting scalability in cloud-based proxy models, rather than tool detection speed.

3.3. Data Collection and Analysis

3.3.1. Data Collection Procedures

Data collection processes are designed to maintain high rigor and reproducibility for all experiment situations. The logging feature offered by the Jenkins platform can deliver high-resolution timestamps for events like starting and completing pipeline stages for precise execution time computation. The Jenkins platform can store all console outputs for each pipeline run involving all tool outputs, errors, and system messages. A special script was natively developed to monitor CPU and memory utilization, disk input/outputs, and network throughput during pipeline execution.

In Security Detection Effectiveness and Fail-Safe cases, outputs of the Static Application Security Testing tool are analyzed for vulnerability types, severity levels, file paths, and code lines to extract this information. Build success or failure flags are key for validating fail-safe measures.

3.3.2. Statistical Analysis Methods

Statistical analysis involves descriptive, as well as inferential, statistics to determine pipeline performance and to establish whether variations are measurable. Descriptive statistics in terms of mean, median, standard deviation, and coefficient of variation are discussed below.

Normality of distribution is tested to establish the validity of parametric testing assumptions. Once the assumptions of normality have been established, tests were performed to compare execution times before and after the code changes. Independent samples tests assess the comparison between single-execution and concurrent execution scenarios.

3.3.3. Key Performance Indicators

Key performance indicators integrate information from multiple sources to create reliable metrics. The average pipeline completion time quantifies overall efficiency for different workloads. The execution times for each step help identify inefficiencies so that optimizations can be targeted. A coefficient of variation for pipeline execution time quantifies consistency for productive planning.

The overhead percentage for concurrent execution defines scalability measures by evaluating the ratio of average execution time for concurrent execution to single execution time. Patterns of utilization for resources use measures peak usage or average use of CPU, memory and throughput for input–output processes. Security testing-effectiveness measures include vulnerability detection rate fail-safe, activation reliability, and false-positive features. Time to detection measures elapsed time from commit to vulnerability detection. Costs include cost of infrastructure for each pipeline run and cost projections per month based on number of expected commits.

4. Results

4.1. Pipeline Efficiency Baseline Results

The baseline efficiency measure based on 20 successive pipeline runs demonstrates very stable and reliable performance behavior. The average value of total execution time for all runs amounts to 122.08 s, with a standard deviation of 1.69 s, which results in a coefficient of variation of 1.38%. The median value of execution time of 122.08 s corresponds exactly to the average value and thus represents symmetry and no distinct outliers. The execution time varies from minimum to maximum values of 120.08 to 125.31 s, entailing a very small performance variation of 4.35%. The recorded 1.38% coefficient of variation (CV) indicates exceptional operational stability. In public cloud environments [19], performance variance often ranges between 5% and 10% due to multi-tenancy noise; thus, a CV below 2% confirms that the proxy pipeline’s execution time is highly predictable and reliable for CI/CD integration.

The individual stage timing breakdown reveals that security testing stages take up about 41.82% of the overall execution time; code analysis stages occupy 23.78%; compilation and build stages require 15.91%; deployment stages use up 11.04% of time; and other stages, including checkout and database operations, make up 7.45% of overall pipeline time. The security testing stage is the individual stage which takes the maximum execution time of 51.03 s to complete. The reason for this encompasses not only security scanning but also the PHP security code checker and PHP antimalware scanner services involving 15 tools.

Analysis of convergence over time shows that there is immediate stabilization in execution time values, with very little variation apparent from the first iteration to subsequent ones. The value of 1.38% for the coefficient of variation over all 20 iterations shows very little variation and no need to wait for warm-up time to elapse. The immediate stabilization here shows that infrastructure as code obviates first runtime overhead.

After introduction of code modification via new functionality implementation, the average execution time for subsequent 20 trials recorded 126.24 s, with a standard deviation of 2.14 s, registering an average increase of 3.41% from baseline performance. The result of an independent samples t-test for the significance of differences in execution time of baseline and post-code modification scenarios registered a t-statistic of 8.47, with a p-value less than 0.001, registering the significance of differences in execution time at alpha level 0.05. Nevertheless, the value of Cohen’s d statistic registering effect size in these experiments registers 2.13, even though values differ significantly from the baseline; the absolute value of 4.16 s registers minimal significance from a practical perspective. Analysis of resource utilization helps in understanding distinct patterns of execution in the pipeline processes. CPU utilization reaches peak points in compilation and security scan processes and reaches its maximum utilization level to about 60–70% in development instances running Static Application Security Testing tools. However, memory utilization shows a peak of usage in tasks related to Database Operations. Disk I/O throughput shows higher usage in code checkout and deployment stages.

4.2. Dynamic Scaling Evaluation Results

The results from running multiple pipelines together have shown excellent performance of the system to deal with several commits from different developers simultaneously without significantly affecting its performance. The average time it took to run three pipelines together had a standard deviation of 2.27 s and averaged 128.24 s, meaning it performs just 5.04% above the single-processing result of 122.08 s.

Individual concurrent pipeline evaluation shows very little variation in performance distribution. The time taken to complete all three concurrent execution processes fell into remarkably small-time intervals, with less than 3% variation between the fastest and slowest times of concurrent execution. Despite concurrent execution processes occurring simultaneously, all three execution processes remained under acceptable time limits despite occurring simultaneously.

Analysis involving stage-to-stage comparisons for single execution baseline and concurrent execution scenarios identifies that security testing and compilation stages have the highest percentage increases, about 6.1%, due to concurrent execution. The stages involving code checkout and deployment have minimal percentage increases, about 2.6%, which indicate minimal I/O involvement due to network I/O. The unit test stage shows a percentage increase of about 4.2%, which aligns with CPU utilization.

The results for resource contention from our native script metrics indicate predictable behavior. The CPU utilization of development and production machines rose to 75–85% from 60–70% CPU utilization for single execution. The CPU utilization of the Jenkins orchestration environment rose to 45% from 25% baseline CPU utilization, indicating increased overhead of pipeline orchestration for every additional execution but not resulting in any scalability issues.

The average memory usage results differed little in single versus concurrent execution scenarios, averaging 2.9 GB in concurrent execution, as opposed to 2.8 GB in baseline. The peak utilization also rose to 3.6 GB but remained within the available 4 GB capacity. The trend here supports, once again, that memory is not a bottleneck for concurrent execution of pipeline processing. When conducted by independent samples t-test for comparative statistical analyses of concurrent execution versus basic single execution performance times, results showed values of 11.23 for “t” and p ¡ 0.001 for “p-value.” Both values were significantly lower than alpha level 0.05; hence, differences were deemed statistically significant. The effect size measure of 2.88 was large according to Cohen’s d test. Nevertheless, average percentage increments of 5.04% were acceptable, given additional costs of 6.16 s added to total execution times below two minutes.

4.3. Fail-Safe Mechanism Validation Results

The built-in security feature has proven to be strong by detecting and preventing vulnerabilities intentionally added to the source code. In several test cases involving the injection of security issues into the source code, it confirmed a 100% activation rate of security measures to prevent execution at production time. The 100% activation rate confirms the operational reliability of the fail-safe trigger; this demonstrates that the pipeline correctly enforces the security gate when a defined vulnerability is detected.

An example of a fix would be one where two security bugs were introduced simultaneously into the source code. In this case, it took PHP Security Scanner only 0.58 s to detect the two security bugs inserted during the security testing phase. The first security bug concerned the use of the eval function. The scanner identified it as problematic code responsible for remote code execution. The other security flaw concerned hard-coded password values. The scanner identified it as an exposure of sensitive data.

In these complex scenarios related to three vulnerabilities, issues like eval usage related to RCE vulnerability were detected, which, though not exploitable, remained reported, besides identifying issues related to the hard-coded password. The time for completion of these scenarios took about 0.56 s and resulted in identifying three issues.

In another test scenario, the pipeline’s SQL injection vulnerability detection capabilities were evaluated. When code involving SQL concatenation in SQL statements was applied to the application code, it identified potential SQL injections, where the construction of SQL queries involved SQL concatenation instead of parameterized queries. In addition, SQL injections via sprintf functions were detected in the source code.

The scanner also detected cross-site scripting vulnerability issues by identifying the use of the eval function, allowing remote code execution, and weak escape routines, where htmlentities functions can potentially bypass XSS be-cause of the incorrect encoding.

A scrutiny of the results of fail-safe responses shows full implementation of security gates. The pipeline directly labeled the build result as failed, meaning none of the deployment steps would proceed. The vulnerability reports from Jenkins logs were very detailed and even had references to vulnerability texts such as “don’t use eval,” “avoid hard-coding sensitive values,” etc.

The fail-safe component effectively ensured none of the vulnerable codes proceeded past the development stage. A history examination of the Jenkins build verifies that no deployment stages were performed after detection of vulnerability. The deployment stage, database migration stage, and all subsequent stages have a status marked as “skipped” in build logs to represent correct execution of fail-fast functionality to save resources and prevent propagation of vulnerability.

Analysis of pipeline actions related to fail-safe startup validates resource cleanup and decommissioning processes. The Terraform destroy processes in all three test scenarios were successfully completed via Jenkins post-build actions, even though all three pipeline tests were prematurely terminated. Verification from the AWS console confirmed successful termination of all three EC2 instances after failing their respective pipeline actions to avoid wastage of resources and related costs. The uniformity of responses in all test repetitions ensures reliability in the security gate deployment. In all test scenarios related to vulnerability injections, it can be seen that security issues had been properly detected, along with respective failure responses implemented by the pipeline, to ensure a 100% activation rate as part of fail-safe results with no occurrence of false negatives. The 100% detection success rate related to known vulnerability expressions re-emphasizes confidence in the security enforcement capabilities of the pipeline.

4.4. Security Detection Effectiveness Results

A systematic evaluation of security detection performance via multiple pipeline runs allows for quantitative evaluation of the accuracy and reliability of Static Application Security Testing tool suite performance. The pipeline showed reliable performance for vulnerability detection. The security test suite effectively identified several types of vulnerabilities, such as eval function-related remote code execution risks; SQL injection-related risks occurring via concatenation, as well as sprintf functions; cross-site scripting risks caused by improper output escaping; sensitive-data exposure issues due to hardcoded credentials; and improperly implemented security features via inadequate encoding approaches. The vulnerability types have been covered under the most critical areas of the OWASP Top 10 for PHP applications [20].

Analysis of tool contributions helps to conclude that the PHP Security Scanner contributes to finding the greatest number of distinct securities vulnerability reports. The PHP Security Scanner applies its rules to search for security risks such as obvious and subtle vulnerability expressions like the use of eval, SQL query builders that allow SQL injections to occur, and improper management of user-supplied data. Other tools from SAST tools like PHP Code Analyzer, PHPStan, and PHP Mess Detector add quality to PHP source code that improves security by detecting complexity in PHP code sources.

The result of false-positive analysis shows critical operational characteristics. In standard code scans of the baseline application without intentionally incorporated vulnerabilities, security warnings were prompted by security scanner features whose evaluation requires context. One such example would be within the hardcoded password false-positive issue where security alerts were prompted for “$password = ‘SuperSecret123!’;” regarding sensitive-data exposure. However, this specific example would be classified as a false positive considering it is written in example code instead of actual security features. The estimated false-positive rate would be about 10 to 15% [20] based on manual evaluation of security alerts.

Analyzing the false positives in detail shows that these come from conservative detection rules where security, over precision, stands out as a major factor. In particular, if “eval” usage accompanies the warning, “guidance like,” scanners generally raise flags for any “eval()” is given, instead of flagging only “eval() calls.” Likewise, hardcoded strings patterned like passwords issue alerts despite their eventual context of use. Though these false positives cause investigating burdens, conservatism correlates to “shift-left” security strategies, where identifying suspicious elements early poses greater value than overlooked security holes.

Analysis for detection time shows that detection of vulnerabilities happens quickly in the security testing phase. The average time it takes from the start of a stage to the first vulnerability detected was estimated to be 0.56 to 0.58 s depending on scenarios of execution time, and it generally completes its security scan in 51 s. The quick feedback allows for security to be remediated instantly post-commit instead of discovering it days or weeks later via security checks. The complete vulnerability of reporting allows for remediation advice to be followed. In terms of eval vulnerability, remediation advice from the scanner reads, “Don’t use eval Ever.” For SQL Injection vulnerability issues, remediation advice from the scanner to client reads “Possible SQL Injection: query built by string concatenation or Possible SQL Injection: sprintf used to build SQL query.” In case of hardcoded sensitive values issues, remediation advice from the scanner to client reads, “avoid hard-coding sensitive values (e.g., ‘username’, ‘password’, etc.).”

4.5. Cost Analysis Results

Infrastructure cost analysis helps organizations make decisions about implementing pipeline adoption. Every execution of the pipeline results in costs associated with three EC2 instances running for the average execution time. According to present EC2 pricing offered by Amazon Web Services pricing website for pricing in the us-east-1 region, Development and Production EC2 instances of type “t2.medium” cost $0.0464/hour, and Jenkins EC2 instance of type “t2.micro” costs $0.0116/hour.

For baseline execution of the pipeline with an average time of 122.08 s (0.0339 h), the cost of infrastructure for baseline execution is $0.00470. The cost breakdown is based on on-demand pricing and can be calculated as follows:

(2 × $0.0464 ∗ 0.0339) + ($0.0116 ∗ 0.0339) = $0.00315 + $0.00039 = $0.00354.

For an average development team making 20 commits per day involving 3–5 team members, the cost of infrastructure incurred on a daily basis would be approximately $0.094. The cost incurred for 22 working days in a month would be approximately $2.07. The cost incurred annually would be approximately $24.80.

Cost-saving options are available via the pricing options offered by Amazon Web Services. The pricing for one-year committed utilization of reserved instances would result in saving about 35% of costs; hence, costs would be lowered to about $16.12 annually. The three-year committed utilization of reserved instances would aid in saving about 53% of costs; hence, costs would be lowered to about $11.65 annually. The cost-saving would be about 60–70% via spot pricing for non-critical pipeline execution; hence, costs would be lowered to about $7.44–$9.92 annually.

Cost-effectiveness augments to justify competition in cost estimation by contrasting it with manually factorized security testing costs. Manual security testing related to traditional security evaluation incurs escalated costs to dedicate security team members. The market rate of security consultants stands around $150–$250 per hour. A security test would take security consultants 4–8 h to complete for every application release. In other words, it amounts to $600–$2000 for manually conducted security evaluations. The cost of security validation performed by the pipeline continuously amounts to $0.0047 per execution; it shows about 127,000-times lower cost reduction for a single security test execution compared to manual methods.

Despite the requirement for quarterly manual security checks to augment automatic security testing, cost-saving advantages are quite apparent. Assuming a $1000 quarterly expense for manual security checking done once per quarter by an organization to test security manually, annual expenses for such security checks would be $4000. Adding these to automatic pipeline costs, constituting $24.80 annually to continuously test 4400 commits in a year, makes total security testing expenses $4024.80 every year. Manual security checking for all commits would require about $2.64 million annually, assuming 20 commits in a day and 1 h costs $150 per hour.

The benefits of reduced vulnerability remediation costs are related to early vulnerability detection because of the pipeline. According to Synopsys and IBM Security data from the application security market, it costs about 5–10 times less to remediate security vulnerability issues if dealt with during development versus remediation of the same issues if they occur in production. The critical part here regarding remediation costs for this paper would be to estimate average costs related to remediation of security issues in production. This will be assumed to be about $5000 for this research. Detection of just five security vulnerability issues would translate to savings of about $25,000 to $50,000. Time-saving opportunities provide yet another critical dimension of value. The full security validation process via the automatic pipeline takes about 122 s versus hours and even days needed to accomplish security evaluation manually. The faster cycle time allows several deployment rounds every day, allowing for vastly increased development speed without compromising security requirements. In firms focusing on quick functionality turn-around to meet market demands and keep their competitive edge, time saving alone justifies expenditures related to implementing these security evaluation pipelines in terms of their market value. Some 4400 commits saving 4 h of security evaluations via automatic testing translates to about 17,600 h saved pertaining to $50 hourly development time costs, amounting to $880,000. Compared to a standard 1 h manual peer security review (industry average cost of ~$50/hour), the automated proxy run ($0.0047) provides a 10,000× cost reduction per commit, allowing for the frequency required by DevSecOps.

5. Discussion

5.1. Interpretation of Pipeline Efficiency Results

The empirical results prove the “proxy” DevSecOps pipeline to be very viable for organizations who target security validation automation but not necessarily complete pipeline complexities. The uniform execution time values and their coefficient of variation of 1.38% ensure excellent, predictable performance requirements necessary for production-level deployment planning. The performance level exceeds several other commercial tools like Jenkins, TeamCity, and other competitive tools and demonstrates perfect adherence to infrastructure-as-code principles for reproducible test environments.

The presence of immediate temporal stability without any warm-up runs makes this implementation different from conventional CI/CD solutions, wherein performance issues have been noticed in first-run scenarios. The lack of overhead related to first-run performance makes it seem like infrastructure-as-code provisioning by Terraform and management of dependencies to mitigate performance bottlenecks. Expectations related to first-run performance of the pipeline in organizations would be met.

The result of observing a statistic significantly different from zero for the 3.41% increment in pipeline execution time caused by code changes effectively resolves the issue of unpredictability associated with development delays caused by code changes affecting pipeline execution time. Though the test performed confirms the result to be statistically significant (p ≈ 0.001), it must be accepted that the absolute value of 4.16 s added to pipeline execution time poses little problem in practice. The result means that development teams do not have to think about unpredictable delays to development processes caused by code commits.

The stage-specific timing breakdown showing security testing to consume 41.82% of overall execution time emphasizes not only the completeness of security validation work but also its optimality from the implementation perspective. Note that it takes only 51 s to complete security testing because it combines 15 different security tools running simultaneously whenever possible. A shorter feedback cycle may be achieved by running security tools depending on changes in source code, but an overall execution time of 122 s allows for very fast development cycle execution. The resource utilization trend indicating peak CPU utilization of 60–70% and headroom to 75–85% for concurrent execution shows that cost efficiency and performance capabilities of the infrastructure are appropriately matched. CPU usage could perfectly support peak loads. Nevertheless, if organizations must migrate to more than three concurrent development environments, CPU utilization trend monitoring should be performed to determine when it is time to proceed with new infrastructure deployment.

While the proxy pipeline provides the technical framework for security, successful adoption is fundamentally tied to organizational culture [3]. According to Rajapakse et al. [3], “human-centric” challenges such as developer resistance and lack of specialized skills are the primary barriers to DevSecOps maturity. Our model serves as a socio-technical bridge by providing non-intrusive feedback, thus fostering trust between security and development teams.

5.2. Scalability

The results from dynamic scaling experiments, showing just 5.04% execution time overhead for three concurrent pipelines, form substantial evidence about scalability. The negligible overhead in performance shows optimal allocation of resources to deal with multiple workloads concurrently. It justifies creating separate development and production environment instances. A firm with about three to five development team members can safely use this architecture to scale without advancing additional baseline configuration scaling.

The uniformity in performance across concurrent runs, fluctuating below 3% variance from fastest to slowest concurrent pipes, implies resource contention remains low even at this level of concurrency. The proportional increments in each stage (6–8% for CPU-intensive and 2–3% for I/O-intensive stages) imply there is relative equality in resource utilization and no stage-level bottlenecks. Such equality makes scaling easier and implies scalability would be feasible via horizontal scaling of infrastructure to support scaling across large teams.

The slight spike in Jenkins’ orchestration overhead from 25% to 45% CPU utilization during concurrent execution deserves special attention for organizations engaging in major scaling activities. Although the overhead is not problematic at present, organizations accommodating 10 or more concurrent developers may choose to have separate Jenkins infrastructures for build agents to avoid creating bottlenecks in orchestration. The scale-up behavior of Jenkins’ overhead is linear.

The verification of negligible changes in memory usage during concurrent execution justifies the present allocation of 4 Gb of memory. Memory is not considered to be a bottleneck in such volumes; thus, organizations can concentrate their efforts related to optimization of their infrastructures solely on CPU allocation and network bandwidth. It makes planning easier and cuts expenditures related to additional allocation of memory.

The statistical significance of the performance overhead of 5.04% (p ¡ 0.001, Cohen’s d value of 2.88) and the absolute effect of 6.16 s demonstrates that it is critical to note that just because there is a level of statistical significance to something in DevSecOps assessment, it does not necessarily translate to practical significance. A finding may be very significantly reliable from a statistician perspective but have very little material effect from a practical perspective.

5.3. Security Aspect

The reliability of the fail-safe mechanism to activate in all test situations at 100% shows excellent ability to ensure code vulnerability prevention from reaching the production environment [21]. The full activation rate in controlled testing environment situations provides very compelling verification of correct fulfillment of primary security enforcement goals by the pipeline. The reproducibility of results from diversified vulnerability types and numbers strengthens pipeline implementation quality.

The average time for vulnerability detection of 0.56–0.58 s from the time of security stage initiation shows how efficiently the PHP Security Scanner performs. Quick feedback to developers helps them grasp security issues based on new changes applied to their code to ensure guaranteed solutions. The advantage in time efficiency compared to human security audit processes (measured in hours/days to mere seconds) signifies revolutionary performance in security feedback.

The detailed vulnerability reporting regarding file paths, line numbers, types of vulnerability, and specific actions to take to remediate these issues helps to promote the “shift left” security concept by allowing self-service of security issues to be accomplished by the development community. Rather than security specialists needing to be involved to remediate all issues identified by analyses, many issues can be remediated by the development community based on detailed information presented.

Nevertheless, to appreciate the 100% detection rate result, it should be considered from the perspective of the experiment’s ability to effectively represent common vulnerability types in such a way that it limits their complexity level. More complex scenarios involving vulnerability obfuscation methods to target subtle functionality misunderstandings and less common attacker paths may be missed even by the State-of-the-Art SAST suite used in this research. The result of this perfect detection rate must not be misconstrued to represent comprehensive security; it only represents effectiveness in common vulnerability models.

The correct cleanup of the infrastructure after the activation of the fail-safe shows the level of operational maturity that sometimes is not considered in research and academia. The pipeline failures that result in orphaned infrastructure generate unnecessary cost and resource wastage. The Terraform destroy steps performed in Jenkins post-build workflows ensure failed builds do not introduce technical debt and reflect production-grade implementation quality.

5.4. Security Detection Accuracy Analysis

The fact that the vulnerability scan performed was broad and covered by a variety of security categories shows the high value added by the SAST toolset used. Its effectiveness in spotting potential risks related to remote code execution, SQL injections, cross-site scripting, exposure of sensitive information, and lack of proper security setup is a clear indicator that the tool setup is aimed at the most vulnerable categories covered in the OWASP Top 10 related to PHP applications.

A false-positive rate of 10% to 15% is deemed a fair trade-off for the purposes of security analysis within the developer stage of the SDLC. Though false positives incur an investigation cost on the developer community, this value is well within the acceptable thresholds defined by industry standards for SAST scans. The conservative detection strategy will fit within the concept of shift-left security because it emphasizes the detection of potential risks over those risks ultimately being left in the environment.

It is up to the organizations implementing this tool stack to create specific procedures concerning the prioritization of warnings related to security concerns in order to reduce the problem of warning fatigue. The specific example of a false positive concerning a hardcoded password is an example of the need for contextual evaluations. It is indeed true that a line of code containing the setting of a password, similar to “$password = ‘SuperSecret123!’” is a potential problem concerning protections, but it is acceptable in comments within example code projects.

The dominance of PHP Security Scanner tools in vulnerability scans indicates areas where optimization of the toolset is required. Scanners with few exclusive detections may be considered for removal from the toolset to optimize the process flow without hampering the security-scan capabilities of the toolset. However, firms must ascertain whether tools deemed redundant add value in terms of increased confidence levels regarding vulnerability detections. When the tools in a group of tools point toward the same vulnerability, they enhance the confidence level in the vulnerability’s existence rather than decreasing the scan times.

The degree of code analysis performed in under one second lends strong support for the concept of shift-left security because it makes its full execution possible. In effect, a positive response regarding code security is given to the developer in a matter of seconds after committing the code rather than after a period of days or weeks during a follow-up security audit. The ability for the scanner to provide specific and detailed remediation advice is an important factor for implementing DevSecOps successfully. A generic message including “security issue detected” without providing specific details is bound to involve a skilled security professional, leading to bottlenecks, and thus defeating the purpose of a shift-left strategy. This is because a detailed message including “Possible SQL Injection query built by string concatenation” with specific line numbers helps the developer understand and take corrective actions without involving skilled security professionals.

5.5. Cost–Benefit Evaluation

A cost of infrastructure of $0.0047 for each execution of the pipelines, with estimated costs of annual execution being $24.80, is an indicator of a very cost-effective strategy for security validation. This fact alone is an indicator of a huge cost saving of approximately 127,000 times what would be required in a manual process of security validation. Even with the need for historical testing and security reviews in a manual process, the costs would be orders-of-magnitude smaller than those of a totally manual process for security validation.

The potential indirect cost benefits of vulnerability discovery may be orders of magnitude larger than the direct cost benefits related to infrastructure-protection costs. Based on an estimated annual cost savings of $25,000–50,000 derived from the prevention of five production security incidents, the cost of investment is approximately 1000–2000 times the cost of infrastructure of $24.80 per year. This is a conservative estimate because it does not take into consideration other costs related to a production security incident, including reputation loss, customer-notification needs, and so on.

Productivity gains for the developer save about $880,000 per year, which is the greatest economic value derived from the elimination of the need for a manual security review process. While the cost-savings analysis makes numerous estimated assumptions about the requirements of a manual security review process, even a conservative estimate of 30 min for a commit saves the organization.

However, the cost of implementation needs to be taken into consideration by organizations, in addition to the cost of infrastructure, in a full-fledged cost–benefit analysis exercise. This is because the total amount of initial investment required is approximately 200–300 h, which includes spending on Terraform infrastructure setup (approximately 40–60 h), setting up and incorporating with Jenkins (approximately 60–80 h), incorporating SAST tools and testing of the same (approximately 80–120 h), and documentation and training exercises (approximately 20–40 h). With a fully loaded cost of $100 an hour, the total cost of setup would be in the range of $20,000–$30,000.

A continuous process of maintaining the tool will involve updating the tools every quarter, and this will take an estimated 4–8 h per quarter. There will be a need to tune the configuration according to false positives, and this will take 2–4 h per month. There will be a need for infrastructure updates, which will take 4–8 h quarterly. Developer training will take 4 h per new employee. A five-year full cost–benefit analysis shows a strong return on investment. A 5-year ROI analysis considers an ongoing maintenance effort of 48 h per year (4 h/month). This bandwidth is dedicated to tuning SAST rules to reduce false positives and updating Terraform providers. Despite these recurring efforts, the automation remains 98% more cost-effective than periodic manual security assessments over the same period.

5.6. Comparison with Existing DevSecOps Frameworks

The empirical results greatly correspond with established DevSecOps benchmark frameworks, most notably with the Framework of Business Index Concerning Security (FOBICS) proposed by Caniglia et al. [12] in 2025. The Performance Security Index succeeds due to information about execution times (average 122 s) and cost-effectiveness ($0.0047), proving, in effect, that an increase in security is not a roadblock in terms of performance. The Security Coverage Index is validated given the deployment of SAST tools related to remote code execution, SQL injection, cross-site scripting, exposure of sensitive data, and weak security installations, which correspond with the most pressing vulnerability types involving PHP applications.

The Early Security Index reflects a successful execution of the shift-left strategy with a seamless integration of security within a few seconds of code commit phases of the development life cycle. The average time taken to identify first vulnerability (0.56–0.58 s) and total pipeline runtime of 122 s positions the security validation stage at the earliest technically viable stage of the development life cycle, making the shift-left concept a reality rather than just a theoretical one.

However, some areas of the FOBICS categories, about the present implementation, show some weaknesses. The area of the Training Security Index is not entirely taken care of by the automated process, which means that additional organization-driven actions with regard to both security training and awareness need to be taken. Even if the process provides a remediation strategy with a level of detail that indirectly teaches developers about security aspects, the need for structured security training is definitely an organizational issue, rather than an area within the scope of the process itself.

The Collaboration DevSec Index includes a level of observation concerning teamwork and communication styles, going beyond pure process aspects.

The Robustness Index, an indicator of tool evolution throughout the project’s life cycle, is not captured within the scope of the present evaluation period. Although the pipeline shows stable performance throughout the experiment period, the characteristics of stability over longer periods require observation of update rates, breaking changes in tool APIs, and config drift over a period of a few years in an organization’s deployment.

Comparison with general DevOps performance data from Amaro et al. [10] shows that the proxy pipeline is tackling many of the existing DevOps issues. This is because the deployment frequency is restricted only by the change management within the organization and takes only 122 s for execution, so deployment can be done within an hour if needed. But the lead time for changes is always predictable in 2 min increments from the stage of commits to deployment readiness, which helps in proper release planning. The failure rate of changes related to security vulnerability is close to zero due to full SAST checks and 100% fail-safe activation, but other failure types can occur. The MSD areas detected by the study carried out by Zhao et al. [1] reveal potential areas for exploration by future work. Toward this objective, the current work will be restricted mostly within technical aspects related to performance and DevSecOps metrics related to execution times, resource consumption, cost of execution, vulnerability rates, and fail-safe reliability. There is negligible discussion about the dimensions related to organizations, humans, and culture, which is already a limitation accepted by many researchers. A DevSecOps assessment needs a multidimensional study within the key areas of effectiveness, readiness, collaboration, and cultural aspects related to DevSecOps adoption by organizations.

5.7. Practical Implementation Recommendations

On the basis of empirical evidence, there are a number of recommendations for organizations considering implementing a proxy pipeline. Organizations should design for immediate pipeline robustness rather than waiting for performance improvement in early runs. The value of 1.38% for the CoV in the initial realization tends to verify that Infrastructure Code abandons any need for warming-up phases before deployment in production if infrastructure code passes verification tests successfully.

Second, processes need to be set up for triaging security warnings before deploying the pipeline. The reported false-positive rate of 10 to 15% requires system-level analysis to identify true vulnerabilities and acceptable patterns of code to prevent false positives. Suggestions for improvement would involve appointing security champions for triaging purposes among development teams to offer expert insights into specific code patterns perceived as false positives, and regular reviews of tool setup to lower continuously recurring false positives when using security tools. Ignoring false positives can cause developers to lose focus on security alerts with time, rendering pipelines useless in their original purpose; that is, ensuring code security. In small development teams, the “Security Champion” role is typically assumed by a Lead Developer rather than a new hire. This individual dedicates approximately 10% of their bandwidth to triaging security reports and advocating for “secure-by-design” practices, ensuring that the proxy pipeline results are integrated into the daily development workflow.

Thirdly, it is important for organizations to adopt pipeline prioritization techniques regardless of team sizes to achieve optimal resource allocation. While the overhead cost of concurrent processing of 5.04% still remains low with three developers running together, a simple form of prioritization helps avoid resource conflicts when there is occasional surge activity. The solution would mean reserving immediate processing for critical branches (main, release, and hotfix), setting up queues with a maximum persistence of 5 to 10 min for feature branches when more developers are active simultaneously, and ensuring developers get adequate feedback on their position within the queues.

Fourthly, efforts need to be put into complementary security efforts other than those found in SAST-based proxy pipelines. The witnessed 100% fail-safe activation rate at carefully controlled test environments cannot create complacency about overall security assurance. Suggested complementary security efforts would entail Dynamic Application Security Tests at production-like environments for scanning runtime-level vulnerabilities; bi-yearly penetration tests at production environments with security experts to evaluate intricate attack paths; code-level security reviews related to authentication, authorization, and cryptography best practices; and security-awareness training programs targeting awareness creation at developer teams.

Fifthly, it is important to keep track of pipeline metrics with the intention of detecting trends that would require scaling or optimizations for infrastructure growth. Some of these tasks to keep track of would include mean execution time with notifications for persistent growth above 10%, evaluation of the 95th percentile of execution times for occasional inconsistencies in times, tracking overheads of concurrent execution times for scaling plans, and evaluation of false-positive rates for optimal tuning of tools.

Sixthly, there should be investment in educating developers about what pipelines can and cannot do. Developers need to know that just because pipelines run successfully, it does not mean that the code is production-ready; also, just because security validation passes does not mean that all vulnerabilities are checked, and that while pipelines can efficiently cover popular vulnerabilities, human security checks are really required.

5.8. Study Limitations

Many limitations exist, and they are related to areas for future study. Firstly, this evaluation was only done on PHP-based applications using a particular set of technologies: CentOS 7, PHP 7.0, MySQL databases, Nginx servers, and related tools. Directly applying these findings to other programming languages like Java, Python, JavaScript, or compiled languages would need verification. However, the concepts of implementing program-level proxies using pipeline architecture and infrastructure-as-code approaches and integrating SAST tools would easily apply to other sets of technologies with appropriate substitutions based on specific programming languages used.

These experimental scenarios were set up under carefully controlled circumstances with infrastructure cycled for every experiment. There would be integration of existing code, management of dependencies, skill differences among developers, and so on introduced into production scenarios that would increase technical debt with time. Although such experiments could isolate characteristics of pipeline speed, they would not necessarily reflect production scenarios with complexities introduced with time. Cross-sectional studies would demonstrate production-level characteristics over periods of extended development cycles.

Because of the vulnerability injection method employed to judge the effectiveness of security detection, more complex vulnerabilities with hidden semantic errors or obfuscation techniques would potentially go undetected using State-of-the-Art SAST solutions. The finding of 100% fail-safe activation rate should not be taken to imply perfect coverage of security features but rather with this specific set of vulnerabilities that were injected into it. Future research efforts would benefit greatly from testing these security features with more comprehensive vulnerability databases, like OWASP Benchmark, or real-world vulnerability databases.

Technical pipeline functionality was assessed without considering more organizational and cultural considerations related to adoption and success. Developers’ satisfaction with pipeline functionality related to their workflows, satisfaction with security team collaboration patterns, organizational processes for change management, or their organization’s general readiness for the cultural shift required by DevSecOps can greatly impact real-world success beyond pure technical capabilities. Qualitative research techniques like semi-structured interviews with developers and security engineers, team satisfaction and security awareness studies using online or offline questionnaires, ethnographic studies of developer workflows, or organizational case studies could enrich research with human insights.

The cost analysis was focused on the infrastructure costs of AWS and assumed savings in developer time and not taken into account other expenses related to cost of ownership. These unaccounted expenses would relate to opportunity costs incurred because of pipeline delays caused by unsuccessful builds, analysis times related to false positives within development teams, expenditures related to security incidents occurring undetected because of SAST tools, and costs related to tooling subscriptions and upgrades over multi-year engagements. There would be cost of ownership if measured over multi-year engagement periods.

The test with three developers performing concurrent compilation and program execution comes under small-team scenarios, which cannot necessarily apply at an organization level with more than three developers. Although there is an indication of possible scaling with an overhead of 5.04%, run-time scaling with more developers, like ten developers, twenty developers, or fifty developers, cannot yet be confirmed directly because resource competition patterns could demonstrate non-linear scaling at larger scales. While the pipeline scales effectively for three concurrent developers, these results serve as a preliminary baseline. Future studies should evaluate resource contention in larger organizational settings.

While evaluation timeframes of several weeks capture shorter-term behavior of Security Performance Characteristics (SPCs) well but not their longer-term developments, pipeline performances could degrade with code bases’ increase and breaking changes brought about by updates of dependencies because of tooling misconfigurations and infrastructure aging. Long-term studies of multiple years would provide valuable insights into SPCs’ attainability of stability and evolution patterns directly useful for total cost of ownership analysis.

The findings of this empirical evaluation are specific to the PHP ecosystem. The observed false-positive rate of 10–15% is consistent with industry benchmarks for SAST tools [20]. While the proxy logic is language-agnostic, the detection rules are currently optimized for PHP-based multi-tier architectures [20].

A 10–15% false-positive rate is consistent with high-sensitivity SAST tools. To manage alert fatigue, we suggest a triage process where developers focus on “high” severity alerts first, as recommended in empirical security studies [20].

5.9. Generalizability and Transferability

Although inherent limitations exist within this study, there are several findings supporting generalization beyond this experimental setup. The primary assumption that benefits in cost savings exist when automating security testing compared with manual processes, with cost savings measured at several orders of magnitude, holds true independent of specific technologies and environments. Although specific multipliers differ according to labor and infrastructure costs, basic economic principles under which automating offers value apply universally.

The finding that pipelining with multiple concurrent processes entails a moderate level of performance overhead scaling directly with concurrency can easily be extended to other implementations of CI/CD with resource sharing for computation. The specific value of 5.04% with three concurrent processes considers resource allocation specific to this implementation; however, it can reliably be expected that similar scaling trends would exist when implementing different architectures with sufficient resource allocation.

The result that security detection accuracy necessarily entails trade-offs between true positives and false positives applies universally to security testing tools that can be automated. It becomes necessary for an organization to gauge the sensitivity of even different security tools depending on risk tolerance and investigation ability. The concept of the detection paradigm that favors security over accuracy becomes an important strategic aspect applicable to different SAST tools.

The concept of defense in depth, which implies more than one complementary measure for security, applies not only to SAST-based pipelines but to overall security programs, too. No security solution can offer foolproof security; therefore, holistic security plans need to combine Static Analysis, Dynamic Testing, Manual Code Checks, Penetration Tests, and Security Training. It can be applied regardless of specific technologies used for implementation.

The infrastructure-as-code model, which allows for reproducible and reliable infrastructure creation, can now be applied more broadly to other types of cloud infrastructures like Azure or Google Cloud Platform infrastructure, or even to traditional infrastructure with tools like Ansible. The advantages of automating infrastructure management, irrespective of technologies chosen, were always independent of those technologies.

It would be easy to adapt these patterns to different technology stacks because tools can easily be replaced systematically. For Java-based applications, replace PHP tools with SpotBugs, PMD, Find Security Bugs, and OWASP Dependency Check. For applications using Python, Bandit, Pylint, Safety, and Semgrep can replace PHP tools. For applications using JavaScript code, tools like ESLint with security plugins, npm audit, and Snyk can replace PHP tools easily because six-step pipeline architecture designs, safety features, and infrastructure-as-code concepts can easily be applied. The research design wherein efficiency measurement, scalability analysis, fail-safe checks, and accuracy of failure identification can be included offers a template that can be replicated regardless of different implementations of DevSecOps processes. These can be applied to different processes with adjustment of parameters like the number of iterations or the number of concurrent processes depending on different scenarios.

6. Conclusions

This study presents one of the first comprehensive empirical evaluations of a proxy-based DevSecOps proxy pipeline developed for multi-tier PHP web applications on 40 experiment cycles (20 before and 20 after modification). The pipeline shows high robustness, with a coefficient of variation of 1.38%, average running time of 122 s, and concurrent execution ability to handle up to three tasks simultaneously with only 5.04% performance loss. The fail-safe and secure techniques deployed result in a 100% success rate, with a detection time of 0.56 to 0.58 s to discover injected vulnerabilities (RCE, SQL, XSS, and data exposure), although with 10–15% false positives. Cost–benefit analysis suggests an execution cost of $0.0047 and annual infrastructure cost of $24.80, which translates to approximately 127,000 times more efficient than human-conducted security assessment. With a five-year timeframe, it gives 46 times return on investment due to increased productivity of developers (approx. $880,000 annual value) and cost to prevent incidents between $25,000 and $50,000 per annum.

The most important contribution of this work is the creation of rare, measurable baselines on which the efficiency of DevSecOps operations is assessed. Moreover, it proposes a simplified proxy architecture, which proves the efficacy of DevSecOps on security, reducing the complexity associated with the entire tool chain, and therefore increasing the ease of adoption of DevSecOps within SMEs by a capital outlay of less than $25 annually. The constraints could be restricted to PHP applications and test setup and assessment. Future work could involve studying more programming paradigms, incorporating dynamic application security assessment, exploring the utilization of machine learning techniques to assign importance to warnings, and studying organizational factors impacting the usage of DevSecOps pipeline.

Future extensions of this proxy pipeline could involve exploring how this pipeline might utilize new distributed security frameworks to increase integrity levels of security test results for deployment scenarios with very high threat levels as BrokerAS [22]. This would be a problem if security tools themselves are compromised and produce false-negative results. Again, however, this comes at a cost of a 15–20% increase in latency and a much higher infrastructure cost, which may not be appropriate for small-team PHP development scenarios such as the one we targeted. Future research should investigate how to determine what level of distributed security enhancements warrant the added complexity of such a system.