Secure Programming and Secure Design in DevSecOps: A Literature-Based Conceptual Synthesis

Abstract

Secure programming and secure design are often managed as separate activities, leaving a gap between architectural intent and the implementation that reaches production. This paper presents a structured conceptual synthesis of twenty core publications, supplemented by standards and recent work on AI-assisted development. It makes three contributions. First, it frames secure programming as the implementation-facing realization of secure design within a closed feedback loop. Second, it uses an explicit 0–5 rubric to produce an illustrative comparison of Waterfall, Iterative, Spiral, and Agile with DevSecOps across six security-integration dimensions. These profiles are structured author judgments, not empirical measurements of security effectiveness. Third, it proposes an operational Secure SDLC–DevSecOps framework that links six stages through named artifacts, accountable roles, traceability rules, release gates, exceptions, and outcome measures. A comparison with NIST SSDF, OWASP SAMM, Microsoft SDL, ISO/IEC 27034, and OWASP implementation guidance shows that the individual practices are established; the framework’s intended contribution is the project-level control loop that connects design decisions to pipeline evidence and production feedback. The illustrative profiles place Spiral and Agile with DevSecOps close together under the baseline weights, while sensitivity scenarios show that their ordering depends on whether design-time risk analysis or delivery-time verification is emphasized. The synthesis therefore supports contextual tailoring rather than a universal ranking.

1. Introduction

Secure design is a foundation for secure programming. Exploitable weaknesses may arise from individual coding errors, but they also originate in earlier decisions about trust, privilege, data flows, dependencies, and failure behavior. Secure programming therefore requires a lifecycle perspective in which security is specified, designed, implemented, and tested as a system property rather than added as a compliance exercise or post hoc patch. Security requirements, architecture models, and threat models must remain available to developers and must evolve with implementation decisions. Otherwise, the intended design and the delivered system can diverge without a reliable way to detect the difference.

This concern has become more important as software engineering has moved toward short release cycles and Continuous Integration/Continuous Deployment (CI/CD). Every commit can alter the attack surface, invalidate assumptions, or introduce new trust relationships; consequently, one-time security reviews can quickly become outdated. DevSecOps seeks to close this gap by integrating automated security controls into delivery pipelines so that security verification can occur alongside development [1,2]. Recent research also shows that DevSecOps adoption involves organizational as well as technical challenges. Although automation enables continuous verification, organizations frequently encounter weak security culture, limited developer knowledge, unclear responsibility, and poor tool integration. DevSecOps should therefore be treated as a socio-technical practice requiring collaboration among development, operations, and security specialists [3,4]. Conceptual models of continuous security represent assurance controls as repeatable pipeline activities that produce security indicators over time. Automation alone, however, cannot provide complete assurance: tools may produce noisy or context-poor results, and checks that are disconnected from design requirements may overlook system-level weaknesses or encourage superficial compliance [5,6].

Security requirements engineering is a principal point of connection between secure design and secure programming. Without clear security requirements, developers may implement functional behavior correctly while leaving important threats or residual risks unaddressed. Security requirements specify the assets to be protected, the relevant threat assumptions, and the acceptable level of residual risk. Comparative studies indicate that the selected requirements-analysis methodology affects how security issues are identified, traced, and specified, particularly in regulated or high-assurance domains. Recent work argues that security requirements should also be compatible with agile delivery by limiting incremental cost and coordinating their adoption with iteration-level decisions and artifacts [7]. Security requirements should therefore be managed as evolving engineering assets rather than documents produced only at the beginning of development. Systematic identification, prioritization, and traceability can improve alignment between architectural decisions and implementation practices, while maturity models provide structured mechanisms for improving requirements-management capability [8,9]. In global or distributed development, organizational enablers such as awareness, training, and stakeholder alignment influence whether security requirements are translated into implementation outcomes [6,10].

Threat modeling (TM) operationalizes secure design by relating architecture to adversarial capabilities and abuse paths. Systematic reviews describe a broad range of techniques, including STRIDE, attack trees, and risk-driven methods, but also identify a recurring weakness: a workshop performed once cannot remain accurate as the system changes. Continuous approaches seek to recompute design-level risk when code, dependencies, configurations, or deployment assumptions change [11,12]. Tool evaluations therefore consider automation coverage, scriptability, machine-readable models, and adaptable threat and countermeasure catalogs [11,13]. Model fidelity remains critical. If the model no longer represents the deployed system, continuous analysis can create misplaced confidence or remediation work that developers cannot use. Instance-centric models address part of this problem by representing deployed instances and architecture-specific properties rather than only abstract component types [11,12,14].

Prioritization is also important to the practical value of threat modeling. Industrial case studies suggest that threat-modeling techniques are most useful when they direct teams toward high-impact, context-relevant threats within available time and resource constraints. Risk-first variants of established workflows can focus effort on high-severity risks without necessarily increasing total analysis time. These findings support a central principle of secure programming and design: security activities should provide developers with concrete guidance early enough to influence implementation decisions, rather than only after development is complete [5,10].

Design-time analysis reduces some vulnerabilities but cannot prevent implementation defects, vulnerable dependencies, or deployment errors. Static and dynamic testing in CI/CD therefore form an important part of DevSecOps. Implementation studies show that SAST and DAST can be integrated into pipelines, but they also expose practical constraints: scanners require maintenance, test environments are difficult to reproduce, and coverage must be balanced against pipeline latency [2,15]. Security gates that are slow, noisy, or detached from stated risks are likely to be bypassed. Sustainable automation must give developers timely, actionable findings while reserving blocking decisions for risks that exceed a declared quality bar [6,15].

The issues are compounded by domain pressures, and the ineffectiveness of generic prescriptions becomes evident. The requirements of automotive cybersecurity software should be repeatedly superimposed on the changing elements of architecture and should be open to verification with system models, driving structures that interconnect engineering models and security knowledge bases, to maintain the design and implementation at the same stage. In ML-based IoT development, practitioners report concerns including model theft, reverse engineering, resource constraints, and trade-offs between security investment and business needs; these findings motivate domain-specific mitigation and testing guidance [16]. The space missions are high-assurance environments that require secure systems engineering frameworks that are co-located with model-based engineering artifacts and mission lifecycles and are more aligned with the design assurance and implementation-governance focus than most enterprise software environments. The common need in all these environments is the need to be flexible: security processes need to be instantiated and context-specific, and yet robust enough to guarantee the intent of the design in implementation and use, and deployment as well [17,18,19].

Secure design and programming must also be measured rather than merely asserted. Realist evaluation treats the effect of an intervention as dependent on context, adoption mechanisms, and feedback, which means that process activity should be connected to outcomes over time [6,20]. A systematic mapping of lifecycle security metrics identifies many proposed measures but limited validation for a substantial portion of them [21]. Continuous threat analysis and pipeline testing make longitudinal observation possible, including mitigation completion, vulnerability trends, and changes in residual risk across commits and releases [1,12,15]. These signals are useful only when organizations address socio-technical constraints such as skills, incentives, and ownership, as well as technical constraints such as model drift, catalog maintenance, and tool interoperability.

Overall, secure programming can be considered an implementation-oriented manifestation of secure design that is supported by an intricate system of Secure SDLC/DevSecOps. The most general thread of research throughout the available literature is to (i) encode security requirement and design assumptions into actionable developer advice, (ii) operationalize threat modeling as an activity that can be used with CI/CD and continuously updated risk activity, and (iii) test implementations using automated security testing that is delivery-conscious and yet with meaningful coverage [5,11,12,15]. It is on these bases that this paper presents secure programming and design as a closed-loop engineering problem: requirements drive design choices, threat models quantify and rank risk, implementation and testing provide evidence, and measurable signals drive continuous and constant improvement in the conditions of delivery in the real world.

Against this backdrop, the paper makes three bounded contributions. First, it frames secure programming as the implementation-facing realization of secure design within a closed engineering feedback loop. Second, it provides a traceable, rubric-based comparison of four lifecycle configurations and tests the sensitivity of the resulting profiles to alternative weights. Third, it specifies a project-level Secure SDLC–DevSecOps overlay with required artifact classes, roles, gates, exceptions, and measures. The comparison is explanatory rather than empirical, and the proposed framework remains a candidate for industrial validation.

Related Secure-Development Frameworks and Positioning

The six activities in the proposed cycle are not claimed as newly invented security practices. NIST SSDF organizes secure development into preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities; its practices are outcome-oriented and intended to be tailored to organizational risk and resources [22]. OWASP SAMM provides a maturity model spanning governance, design, implementation, verification, and operations, with defined practices and maturity levels [23]. Microsoft SDL similarly connects training, requirements, design, implementation, verification, release, and response through mandatory checks and approvals [24]. ISO/IEC 27034 provides application-security concepts and organizational processes that apply to internally developed, acquired, and outsourced applications [25]. OWASP Secure Coding Practices supplies an implementation-oriented checklist, while the OWASP Top 10 is primarily an awareness and prioritization document rather than a lifecycle model [26,27].

The proposed framework differs in level and purpose rather than in its inventory of practices. SSDF and ISO/IEC 27034 establish broad outcome and governance expectations; SAMM assesses organizational capability; Microsoft SDL defines a mature vendor’s required practices; and OWASP guidance supplies control- and weakness-oriented implementation advice. The framework in this paper is a project-level orchestration model. Its distinctive unit is a traceable change: a requirement or threat is linked to a design decision, implementation task, verification result, release decision, and operational observation. Feedback is considered closed only when operational evidence changes an upstream artifact or an explicitly accepted risk. Table 1 makes this positioning explicit.

Table 1. Comparison with established secure-development frameworks.

Framework	Primary Unit	Artifacts and Roles	Feedback or Measurement	Relationship to This Paper
NIST SSDF	Outcome-based practices and tasks	Organizational roles, requirements, provenance, test and vulnerability records	Gap assessment and vulnerability response	Supplies the governance and outcome baseline; the proposed cycle adds project-level trace links and gates [22]
OWASP SAMM	Organizational maturity across five business functions	Practice streams, activities, quality criteria, and maturity assessments	Repeated maturity assessment and improvement targets	Provides a stronger maturity model; the proposed cycle is an execution overlay rather than a competing maturity scale [23]
Microsoft SDL	Required lifecycle practices	Security requirements, threat models, approved tools, test evidence, release and response plans	Quality bars, approvals, and incident response	Closest process analog; the proposed cycle makes cross-artifact traceability and operational reopening rules explicit [24]
ISO/IEC 27034	Application-security management process	Organizational normative framework and application-security controls	Governance and application-security assurance	Provides a standards-level management context within which the proposed project cycle can be instantiated [25]
OWASP SCP/Top 10	Coding checklist and risk-awareness categories	Developer checklist and common web-risk taxonomy	Checklist evidence and periodic category updates	Supplies implementation content but does not itself connect design artifacts, pipeline gates, and production feedback [26,27]
MetaSEnD	Security-enabled lifecycle meta-model	Security activities integrated into lifecycle modeling	Model-level process integration	Offers broader lifecycle modeling; the present framework emphasizes operational evidence and the closure of feedback at project level [17]
Proposed framework	Traceable project change and its assurance case	Six required artifact classes, accountable roles, gates, exceptions, and metrics	Operational evidence must update an upstream artifact or accepted risk	Synthesis and execution overlay; it does not replace SSDF, SAMM, SDL, or applicable standards

2. Materials and Methods

2.1. Study Design

This manuscript is a structured conceptual review. It asks how secure-design intent can remain connected to implementation and assurance evidence as software changes. It reports no experiment, deployment, or observed project outcome. The analysis combines work on secure lifecycles, DevSecOps automation, threat analysis, requirements engineering, agile security, and domain-specific systems engineering [17,20]. Standards and guidance are examined separately because a normative framework and an empirical study answer different questions and should not be treated as equivalent evidence.

2.2. Review Corpus

The comparative synthesis uses a purposively assembled core corpus of 20 references. It includes conceptual lifecycle and DevSecOps models [1,17]; standards-oriented and governance work [18,28]; CI/CD security-testing studies [2,15]; threat-modeling reviews, tools, and case studies [5,11,12,13,14,29]; empirical studies of agile or industrial practice [6,7,10,16]; security-requirements studies [19,30,31]; and an interpretive evaluation perspective [20]. References [3,4,8,9,21,32,33,34,35,36] and the standards in References [22,23,24,25,26,27] provide contextual evidence but were not used to assign the original rubric ratings. Because contextual sources do support substantive discussion, the paper now distinguishes the rating corpus (References [1,2,5,6,7,10,11,12,13,14,15,16,17,18,19,20,28,29,30,31]) from the wider interpretive corpus (all cited sources). This boundary prevents later sources from being described as evidentially irrelevant while still making clear that they did not determine the ratings.

2.3. Inclusion Logic

No new database search was conducted for the original synthesis; it used a pre-assembled bibliography. A source entered the rating corpus if it addressed secure lifecycles, security governance, pipeline automation, threat modeling, security requirements, agile security, or secure engineering in critical domains. Sources were excluded from rating when they served only as background, were published after the original analysis, or described guidance without evidence that could discriminate among the four lifecycle configurations. This procedure is reproducible at the level of the disclosed corpus, but it is not a systematic search and provides no coverage guarantee. In particular, there is no defensible PRISMA flow, duplicate-removal count, or database search string to report retrospectively. The resulting selection bias limits the analysis to an explanatory synthesis of these sources and rules out claims about the complete Secure SDLC literature.

2.4. Analytical Categories

We categorized the 20 core papers.

The first category covers Secure SDLC and governance models: lifecycle structures, maturity-oriented development models, and standards-based secure-engineering processes [17,18,28].

The second covers DevSecOps and continuous security automation, including security controls embedded in CI/CD and automated checks intended to narrow the gap between development and assurance [1,2,15].

The third covers threat modeling and continuous threat analysis. It includes systematic reviews, tool comparisons, pipeline-based analysis, continuous threat-management tools, industrial prioritization studies, and case-based risk modeling [5,11,12,13,14,29].

The fourth covers security requirements engineering, including requirements practice, methodology-specific support, and model-based requirements management [19,30,31].

The fifth covers agile adoption and industrial practice, including empirical studies and frameworks for integrating security into agile, SME, and industrial settings [6,7,10,16].

The final category provides interpretive support. The realist perspective in Reference [20] was used to distinguish an intervention from the context and mechanisms that influence its outcome.

2.5. Data Extraction

We extracted the papers using a template. We extracted the research questions, the software development phase that was emphasized, the most frequent security mechanism provided, the level of automation, the contribution of the study, and the constraints of the study as described by the authors. We also wanted to know if the study viewed security as a design and requirements issue [19,30,31], a threat analysis and risk prioritisation issue [5,11,12,13,29], a CI/CD automation and verification issue [1,2,15] or a general engineering and governance issue [17,18,28]. We also noted the practical constraints, such as domain knowledge, time, tools, and the above-mentioned constraints for SME [6,7,16].

Table 2 reports the extraction used in the synthesis. “Limitation” denotes the constraint on using a source for the present comparison, not a retrospective quality score.

Table 2. Evidence-extraction matrix for the 20-source rating corpus.

Ref.	Design/Context	Lifecycle Emphasis	Contribution Used in This Synthesis	Limitation for Comparative Claims
[17]	Lifecycle meta-model	Whole lifecycle	Security-enabled lifecycle structure and traceability	Conceptual model; no comparative outcome estimate
[28]	Standards survey and comparison	Governance/process	Common secure-development standards and documented controls	Compares normative material rather than project outcomes
[1]	Conceptual DevSecOps model	CI/CD/feedback	Continuous automated controls and longitudinal indicators	Conceptual relationships require operational validation
[2]	Pipeline implementation study	Build and test	Feasibility of combining static and dynamic testing in CI/CD	Toolchain- and environment-specific evidence
[13]	Systematic literature review	Threat modeling	Threat-modeling concepts and technique diversity	Heterogeneous primary studies; not an SDLC comparison
[11]	Comparative tool evaluation	Threat analysis/CI/CD	Automation, scriptability, and model-readiness criteria	Tool capabilities do not establish organizational effectiveness
[12]	Pipeline architecture/automation	Continuous threat analysis	Re-computation of threats as development artifacts change	Demonstrates technical integration, not lifecycle superiority
[29]	Tool description	Continuous threat management	Operational support for maintaining threat information	Tool-focused evidence with limited outcome validation
[5]	Industrial case studies	Threat prioritization	Importance of context-relevant, high-impact threat selection	Small number of settings limits transferability
[6]	Practitioner survey	Agile security	Adoption, skills, responsibility, and process constraints	Self-reported practice does not measure vulnerability reduction
[30]	Requirements-practice evaluation	Global software development	Security-requirements practices and organizational enablers	Context-specific evaluation; limited lifecycle comparison
[31]	Methodology comparison	Requirements analysis	Differences among security-requirements approaches	Focuses on requirements rather than end-to-end delivery
[7]	Strategy analysis	Agile development	Incremental integration of security practices	Strategy evidence does not validate a complete framework
[10]	Proposed HSScrum framework	Agile/Scrum	Security activities embedded in Scrum roles and events	Framework proposal with limited independent validation
[14]	Risk-modeling research	Deployed system instances	Instance-centric fidelity in threat and risk assessment	Specialized modeling contribution, not a general SDLC study
[15]	CI/CD case study	Dynamic security testing	Test planning, isolation, coverage, and pipeline-latency trade-offs	Results depend on selected tools and application context
[19]	Domain framework	Automotive requirements	Model-based requirements traceability in a regulated domain	Domain constraints limit direct generalization
[16]	Empirical ML-IoT study	Development practice	Security concerns, resource trade-offs, and practitioner needs	Emerging domain with context- and sample-dependent findings
[18]	Systems-engineering framework	Space missions	High-assurance governance linked to engineering artifacts	Mission assurance differs from ordinary software delivery
[20]	Interpretive evaluation perspective	Evaluation/context	Attention to mechanisms, context, and outcome interpretation	Does not supply secure-development effectiveness data

2.6. Comparative Procedure

We used thematic rather than statistical synthesis because the corpus mixes reviews, surveys, conceptual frameworks, tool comparisons, implementation studies, and domain-specific engineering reports. These designs were not pooled as if they supplied commensurable effect estimates. The comparison was organized around four questions: (1) how is security intent represented in requirements and design; (2) how is that intent translated into developer work; (3) how is implementation checked within delivery rather than only at audit time; and (4) what technical and organizational conditions obstruct adoption? The synthesis records convergence, disagreement, and missing evidence rather than treating publication frequency as proof of effectiveness.

2.7. Conceptual Synthesis

The final part of the analysis was conceptual synthesis. We consider the 20 studies in an integrated manner in that we do not consider secure programming as a process, but as a result of secure requirements engineering, risk-aware design and development, risk analysis, automated testing, and operational feedback. This connects our study of practices to requirements engineering, as the identification of security and risk requirements and acceptable residual risk [19,30,31]; threat modeling and threat analysis, as means to identify and update risks at design time [5,13,14]; DevSecOps practices, as the operationalization of verification as part of the deliver processes [1,2,15]; agile and industry studies, which show the evidence of the problems of adoption of such practices [6,7,10,16]. We also consider traceability and assurance from systems and standards engineering [17,18,28]. The realist perspective also allows us to consider such research as practices [20].

2.8. Methodological Limitations

The method has four material limitations. First, purposive selection may omit contrary findings, older foundational work, and relevant 2025–2026 research. Second, the source types have different evidential strength; a conceptual model, practitioner survey, tool experiment, and standard cannot validate the same claim in the same way. Third, no formal study-quality instrument was applied, so the extraction matrix reports design and limitations instead of producing a quality-weighted effect. Fourth, the framework and rubric have not been validated against industrial outcomes. The synthesis can therefore organize concepts and expose testable propositions, but it cannot establish that one lifecycle causes better security outcomes. A future systematic review should search IEEE Xplore, Scopus, Web of Science, ACM Digital Library, and relevant standards repositories using dated search strings, dual screening, duplicate removal, study-type-specific quality appraisal, and a documented selection flow.

3. Results

3.1. Security in the SDLC Models

The analysis indicates that Waterfall, Iterative, Spiral, and Agile lifecycles provide different levels and forms of support for security requirements, threat modeling, secure coding, testing, and late lifecycle changes. This distinction matters because vulnerabilities may be introduced early but detected only after implementation, when remediation is generally more disruptive and expensive. Security should therefore be integrated throughout the lifecycle rather than added as an isolated activity constrained by scope, time, and budget. A multivocal review of secure software development methodologies similarly maps technical and non-technical security practices across SDLC stages and identifies limited evidence about the effectiveness of many methodologies [35]. These findings support movement from a separate security phase toward integrated Secure SDLC and DevSecOps practices.

Waterfall provides explicit phases for requirements, design, implementation, testing, and deployment, which can support documentation and formal approval. Its security performance depends heavily on the completeness of early requirements and design decisions. Requirements discovered after those phases may require extensive rework, particularly when they alter trust boundaries, privileges, or data flows.

Iterative development allows requirements, threat models, implementation, and tests to be refined across cycles. It can therefore absorb newly discovered security needs earlier than a strictly sequential process. Iteration is not itself a security control, however. If security work is omitted from routine planning and review, the same weakness can persist or expand across increments.

Spiral development places risk analysis within each cycle of planning, engineering, and evaluation. This structure is compatible with threat analysis and risk treatment in critical or high-assurance systems. Its repeated analysis also requires specialist effort, disciplined planning, and resources that may be disproportionate for smaller or lower-risk projects.

Agile methods accommodate changing requirements and frequent feedback, which is useful when threats and deployment conditions evolve. Security can nevertheless disappear behind functional priorities unless it is represented in backlog items, acceptance criteria, architectural work, reviews, and the definition of done. DevSecOps practices can reinforce this integration through automated verification and continuous feedback, but they do not remove the need for design analysis or accountable risk decisions.

3.2. Security Requirements Integration

Security requirements integration was examined based on how each model documents, manages, and tracks security requirements. The analysis considered confidentiality, integrity, availability, authentication, authorization, accountability, and PCI-DSS compliance.

Waterfall is strong in documenting requirements and is useful for regulatory compliance. For example, in an e-commerce website that processes payments and must comply with PCI-DSS, requirements for encryption, access control, logging, and credit-card-data protection can be specified before development begins. However, security requirements are difficult to change in Waterfall after the requirements and design phases have been completed.

In the Iterative model, security requirements can be developed progressively. In the first iteration, the team may define high-level security requirements such as secure payments and account protection. In the second iteration, specific controls such as input sanitization, session timeout, token security, role-based access control, and logging may be added. Therefore, the Iterative model is more flexible than Waterfall.

Spiral gives security requirements a recurring connection to risk analysis. Requirements can be prioritized using threat likelihood, impact, asset value, and business consequences. This is useful in high-risk systems because the requirements remain part of risk treatment rather than serving only as documentation.

Agile can enhance security requirements when they are written as security user stories, misuse cases, abuse cases, and secure acceptance criteria. For example, a user story such as “As a customer, I want to log in securely so that my payment details are safe” could include acceptance criteria related to password policy, multi-factor authentication, account lockout, and secure session management. However, Agile teams may overlook security requirements if they are not explicitly included in the backlog and sprint planning activities.

Table 3 summarizes the security characteristics of the SDLC models.

Table 3. SDLC models and security.

SDLC Model	Advantages	Disadvantages	Suitability for Security
Waterfall	Good up-front documentation; suitable for stable compliance requirements	Not flexible when security requirements change late	Suitable when requirements are stable and compliance-driven
Iterative	Security requirements can evolve across iterations	Good security practices are required in every iteration	Suitable for medium-complexity systems
Spiral	Strong risk-analysis-based prioritization of requirements	Complex; requires time, planning, and security expertise	Suitable for high-assurance and high-risk systems
Agile	Strong support for changing requirements	Security may not be prioritized unless included in the backlog and acceptance tests	Suitable when combined with DevSecOps

3.3. Threat Modeling and Risk Management

The four configurations differ in when and how they revisit threats. In Waterfall, threat modeling is usually concentrated in design. This can be workable when architecture and assumptions remain stable, but the model may become stale when technologies, integrations, or deployment environments change after design approval.

Iterative development allows the threat model to be revised with each increment. For example, an e-commerce service may initially support browsing and registration, then add ordering, payments, and external APIs. Each capability introduces assets, trust relationships, and abuse paths that were absent from the earlier increment.

Threat modeling fits naturally within Spiral because risk analysis is repeated in every cycle. Techniques such as STRIDE, attack trees, and risk matrices can help analysts prioritize threats according to technical severity and business consequence. This makes Spiral a plausible host for security work where economic loss, safety, or regulatory exposure is substantial.

Agile teams can distribute threat modeling across architecture work, backlog refinement, sprint planning, and release planning. A large workshop for every change is rarely practical. Teams instead need a proportionate trigger for revisiting threats, reusable threat knowledge, and automation where the model and delivery system permit it. Threat modeling then becomes a maintained engineering activity rather than a single design event.

3.4. Development Phase Security

Development-phase security includes secure coding guidance, peer review, developer training, secrets detection, dependency analysis, and static application security testing (SAST). These practices are not inherent properties of a lifecycle label. They must be selected, maintained, and integrated into daily development work.

In Waterfall, implementation normally follows design approval. Secure coding requirements can be specified in advance, but feedback from executable tests may arrive late. Defects that expose an architectural weakness can therefore be expensive to correct.

Iterative development permits coding practices and controls to be refined using evidence from earlier increments. Findings from peer review, SAST, dependency analysis, and vulnerability tests can inform the next cycle, provided that unresolved security work remains visible and owned.

In Spiral development, risk analysis can guide implementation priorities. If injection, weak authentication, unsafe input handling, and unrestricted file upload are ranked as material risks, the engineering cycle can require parameterized queries, appropriate identity controls, input validation, and constrained file processing. The risk register thereby becomes a source of implementation obligations rather than a separate analytical document.

In Agile delivery, security criteria can be included in the definition of done. A change may require peer review, static analysis, dependency analysis, and relevant security tests before completion. DevSecOps can apply selected checks at commit, build, or deployment time. These controls remain vulnerable to schedule pressure, weak configuration, and superficial compliance if teams value delivery speed without considering the quality of the evidence.

3.5. Testing and Validation

Testing and validation include security test cases, dynamic testing, penetration testing, vulnerability analysis, configuration review, and release approval. SAST and DAST are important DevSecOps controls, but scanner runtime, system complexity, build duration, and test-environment configuration affect their practical use. Continuous testing must therefore balance coverage with delivery performance, while organizational capability and tool integration remain material adoption constraints [3,4,15,34].

Waterfall can support formal security testing at a defined verification stage, but late discovery increases remediation risk. In a payment system, for example, weak authentication, injection-prone data access, or inadequate protection of payment data may require changes that cross design, implementation, and compliance evidence. Testing at the end cannot cheaply recover an unsuitable architecture.

In Iterative development, security testing can be performed after each increment. Findings can therefore be corrected and retested before the final release instead of accumulating until the end of the project.

In Spiral, verification can be selected according to the current risk analysis. If an attack tree identifies fraud or privilege escalation, tests can target authentication, authorization, transaction integrity, and audit behavior. Test results then provide evidence for the next risk review.

Agile delivery can support continuous testing through SAST, DAST, software composition analysis, container scanning, infrastructure-as-code analysis, and secrets detection. Teams must tune these controls, assign ownership, and define risk-based gates so that false positives and latency do not make the pipeline unusable.

3.6. Flexibility and Security Repair Cost

Flexibility affects the cost of correcting a security decision. In Waterfall, a late requirement may require coordinated changes to requirements, architecture, code, and tests, increasing both time and cost.

Iterative development can incorporate requirements missed in early cycles. Its flexibility is not unlimited: architecture-wide changes may still be costly when the affected assumptions have already propagated through several increments.

Spiral is risk-adaptive because each cycle reassesses uncertainty and treatment priorities. That adaptability carries a recurring cost in planning, analysis, and specialist review.

Agile teams can place newly identified risks in the backlog and address them in subsequent sprints. This flexibility can still produce weak decisions when architectural guidance, automation, ownership, or risk governance is missing.

Table 4 summarizes their flexibility and security repair cost.

Table 4. SDLC flexibility and cost.

SDLC Model	Late Security Cost	Adaptability to Missed Security Requirements	Primary Security Concern
Waterfall	High	Low	Late discovery of security bugs
Iterative	Moderate	Moderate to high	Security may be inconsistent across iterations
Spiral	Moderate	High	Expertise and resources are required
Agile	Low to moderate	High	Security may be compromised if speed is prioritized

3.7. Weighted Evaluation of SDLC Models

The six-element rubric was used to construct illustrative security-integration profiles. The dimensions were security requirements integration, threat and risk management, development-phase security, testing and validation, adaptability and flexibility, and cost-effectiveness. Mapping the profile to a 100-point scale improves readability but does not convert ordinal author judgments into validated measurements.

3.7.1. Scoring Methodology and Anchored Rubric

To make the comparison transparent and traceable, we define an explicit two-step procedure that links every cell to the rating corpus. The exercise compares four configurations, not four equivalent objects: Waterfall, Iterative, and Spiral name lifecycle structures, whereas Agile with DevSecOps combines a lifecycle family with a security-process overlay. The ratings must therefore be read as scenarios under the stated security practices. DevSecOps controls could also be layered onto Waterfall, Iterative, or Spiral delivery, and doing so would change their profiles.

First, each SDLC model is rated on a 0–5 ordinal scale against each of the six evaluation dimensions, using the anchored rubric in Table 5, Table 6, Table 7, Table 8, Table 9 and Table 10. Half-point ratings are permitted to capture behaviors that fall between adjacent anchors. Second, each ordinal rating is mapped to the dimension’s weighted maximum through the linear transformation

$$\mathrm{weighted}\mathrm{score}=(\mathrm{rating}/5)\times \mathrm{weight}.$$

Dimension scores are retained to one decimal place. The unrounded dimension scores are summed, and only the displayed composite in Table 11 is rounded to the nearest whole number. This avoids inconsistent treatment of half-point values.

Table 5. Anchored rubric for Security Requirements Integration (weight = 25).

Level	Anchor Description
0	No mechanism for capturing or tracking security requirements; security is implicit or treated as a compliance afterthought.
1	Security requirements captured ad hoc by individual contributors with no traceability to design or implementation.
2	Security requirements captured once during an initial phase; no formal mechanism for revision or traceability afterwards.
3	Security requirements captured in defined phases or cycles and revisable at planned intervals; partial traceability to design artefacts.
4	Security requirements continuously refined alongside functional requirements and traced to design artifacts and acceptance criteria.
5	Security requirements are first-class artifacts, continuously updated as architecture or threat assumptions change, and  verifiable against design and pipeline outputs.

Table 6. Anchored rubric for Threat and Risk Modeling (weight = 25).

Level	Anchor Description
0	No threat modeling performed.
1	One-off, workshop-style threat modeling at project inception that is not revisited as the system evolves.
2	Threat modeling repeated at major milestones but decoupled from day-to-day development.
3	Threat modeling repeated each iteration or cycle with explicit risk prioritization driving design decisions.
4	Continuous threat analysis with risk-based prioritization tightly integrated into backlog planning and pipeline decisions.
5	Continuous threat analysis automated within CI/CD, supporting instance-level model fidelity and re-computation of risk on every relevant change to code, dependencies, or configuration.

Table 7. Anchored rubric for Development-Phase Security (weight = 15).

Level	Anchor Description
0	No secure coding practice; security depends entirely on testing or external review.
1	Ad hoc secure coding by individual developers without organizational guidance.
2	Secure coding guidelines exist but are not consistently enforced or trained.
3	Secure coding guidelines, peer code review, and basic developer security training are in place.
4	Above plus IDE/pre-commit security checks, dependency management, and secrets management integrated into the developer workflow.
5	Secure-by-default tooling, mandatory security-aware review, continuous developer enablement, and design-derived secure coding patterns embedded in templates and libraries.

Table 8. Anchored rubric for Testing and Validation (weight = 15).

Level	Anchor Description
0	No security testing.
1	Manual security testing performed only at the end of the lifecycle.
2	Periodic security testing aligned to major releases with limited automation.
3	Security testing integrated into each iteration with at least one automated technique (e.g., SAST or DAST).
4	SAST, DAST, and SCA integrated into CI/CD with risk-based gating on critical findings.
5	Full pipeline coverage (SAST, DAST, SCA, container, infrastructure-as-code, and secrets scanning), risk-based release gating, and continuous feedback into the backlog.

Table 9. Anchored rubric for Adaptability and Flexibility (weight = 10).

Level	Anchor Description
0	Cannot accommodate changes to security requirements or threat assumptions after the initial phase.
1	Changes possible only through major rework with substantial cost and delay.
2	Changes accommodated at defined milestones but not within a cycle.
3	Changes accommodated each iteration or cycle, with security work re-prioritized as part of routine planning.
4	Continuous accommodation of evolving threats and requirements with low marginal cost.
5	Fully adaptive: a security backlog, continuous threat analysis, and CI/CD respond within the delivery cycle without materially disrupting delivery.

Table 10. Anchored rubric for Cost-Effectiveness (weight = 10).

Level	Anchor description
0	Prohibitively expensive relative to the security benefit obtained.
1	High overhead with limited automation; security work is a significant fraction of delivery effort.
2	Moderate overhead and limited reuse of security artifacts across projects or cycles.
3	Acceptable overhead with partial automation and partial reuse of security artefacts.
4	Strong automation across testing and verification, reducing per-cycle security cost.
5	High automation, reusable security artifacts (templates, models, policies), and low marginal cost per release.

Table 11. Illustrative weighted security-integration profiles of SDLC models.

Weighted Evaluation Dimension	Weight	Waterfall	Iterative	Spiral	Agile with DevSecOps
Security Requirements Integration	25	3.5/17.5	4.0/20.0	4.5/22.5	4.0/20.0
Threat and Risk Modeling	25	3.0/15.0	3.5/17.5	4.5/22.5	4.0/20.0
Development-Phase Security	15	3.5/10.5	4.0/12.0	4.5/13.5	4.5/13.5
Testing and Validation	15	3.5/10.5	4.0/12.0	4.5/13.5	5.0/15.0
Adaptability and Flexibility	10	1.5/3.0	3.5/7.0	4.0/8.0	5.0/10.0
Cost-Effectiveness	10	2.5/5.0	3.5/7.0	3.0/6.0	4.0/8.0
Total Score	100	62	76	86	87

Note. Each cell reports the rubric rating R on the 0–5 scale followed by the weighted score $W=(R/5)\times \mathrm{weight}$. The final total is the rounded sum of the unrounded dimension scores. No effectiveness classes or empirical cut-offs are assigned.

3.7.2. Weight Justification

The six dimensions and their weights were derived from the recurring concerns in the synthesized corpus. Security Requirements Integration and Threat and Risk Modeling each receive the highest weight (25 points) because the literature consistently identifies them as the design-time activities that most strongly determine downstream security outcomes: requirements engineering studies [19,30,31] show that the quality of upfront security specification bounds what implementation and testing can later recover, and threat modeling reviews and tooling studies [5,11,12,13,14,29] show that risk identification at design time drives the most consequential mitigation. Development-Phase Security and Testing and Validation receive a middle weight (15 points each); they are essential for closing the gap between design and shipped code [1,2,15], but they cannot recover security that was never specified or modeled. Adaptability and Flexibility, and Cost-Effectiveness, each receive 10 points: empirical and industrial studies [6,7,10,16] treat them as enabling rather than primary security properties, but they materially determine whether a model survives contact with real organizations and delivery pressure. The weights sum to 100, allowing the composite to be read as a percentage of the maximum.

3.7.3. Anchored Rubric

Table 5, Table 6, Table 7, Table 8, Table 9 and Table 10 present the anchored rubric, one table per evaluation dimension, with the behavior expected at each of the six ordinal levels. Each rubric defines six anchored levels (0—absent, 1—minimal, 2—partial, 3—defined, 4—integrated, 5—fully implemented). A rater selects the level whose description best matches the model’s behavior; a half-point may be used when a model sits between two adjacent anchors.

3.7.4. Scoring Procedure

Two co-authors applied the rubric during manuscript development. The retained analysis does not include the two pre-reconciliation rating sheets, the number or distribution of disagreements, or a rule for differences of exactly one half-point. Consequently, percent agreement and weighted kappa cannot be reconstructed and are not claimed. The final ratings are reported only as reconciled author judgments, with the evidence for each cell shown below. This is a limitation, not a validation procedure. A confirmatory application should preserve both rating sheets, define in advance whether a half-point disagreement is averaged or adjudicated, report weighted kappa and the number of discussed cells, and include at least one independent rater with secure-development and empirical-methods expertise.

3.7.5. Ratings and Weighted Scores

Applying the rubric and linear mapping yields the illustrative ratings (R) and weighted values (W) below.

3.7.6. Per-Cell Evidence Map

The justifications in Table 12 cite the rating corpus ([1,2,5,6,7,10,11,12,13,14,15,16,17,18,19,20,28,29,30,31]) so that every rating in Table 11 is traceable to a specific subset of the synthesized literature.

Table 12. Per-cell evidence map for the weighted evaluation.

Dimension—Model	R/W	Justification with Citations
Security Requirements Integration
Waterfall	3.5/17.5	Strong upfront documentation and explicit requirements phase [17,28,30,31]; lacks mechanisms to update security requirements once the design phase is closed [6,7].
Iterative	4.0/20.0	Allows refinement of security requirements per iteration [7,30,31]; traceability to design artifacts present but not machine-verifiable [19].
Spiral	4.5/22.5	Risk-driven cycles continuously refine security requirements alongside risk analysis [5,13,14,19]; falls short of anchor 5 because it lacks an automated link to pipeline verification [1,2,15].
Agile + DevSecOps	4.0/20.0	Security user stories and acceptance criteria embed requirements in the backlog [6,7,10,16]; upfront capture weaker than Spiral [30,31].
Threat and Risk Modeling
Waterfall	3.0/15.0	Threat modeling possible at design time [11,13] but performed as a one-off workshop with no re-computation as the system evolves [5,12].
Iterative	3.5/17.5	Threat modeling repeatable each cycle [5,13]; risk prioritization improves over time [14,29] but still decoupled from CI/CD evidence [11,12].
Spiral	4.5/22.5	Risk analysis is the defining activity of every Spiral cycle [5,13,14,19]; instance-level model fidelity [11] and CI/CD automation [1,2,15] keep it below anchor 5.
Agile + DevSecOps	4.0/20.0	Continuous threat analysis supported by tooling [11,12,14] and integrated into the pipeline [1,2,15]; instance-level fidelity remains an open challenge [11,12].
Development-Phase Security
Waterfall	3.5/10.5	Documented secure coding standards [17,28]; weak feedback loop to developers when defects are discovered late [6,7].
Iterative	4.0/12.0	Secure coding practices reinforced each cycle, with peer review [7,10,17]; less automation than DevSecOps [1,2].
Spiral	4.5/13.5	Cycles include design-time secure coding patterns and review [17,18,28]; less developer-side automation than DevSecOps.
Agile + DevSecOps	4.5/13.5	Pre-commit checks, dependency and secrets management, continuous developer enablement [1,2,6,7,10,15]; design-derived patterns vary by team maturity [6,16].
Testing and Validation
Waterfall	3.5/10.5	End-of-lifecycle security testing aligned to release [17,28]; limited automation [2,15].
Iterative	4.0/12.0	Security testing repeated each cycle [2,15]; partial automation [1,2].
Spiral	4.5/13.5	Verification embedded in each spiral cycle alongside risk review [5,13,14,18]; CI/CD coverage less extensive than DevSecOps [1,2,15].
Agile + DevSecOps	5.0/15.0	Full SAST/DAST/SCA/IaC/secrets coverage with risk-based gating and continuous backlog feedback [1,2,15]; matches anchor 5.
Adaptability and Flexibility
Waterfall	1.5/3.0	Phase-gate structure resists in-cycle change [6,7,17].
Iterative	3.5/7.0	Changes absorbed each iteration [7,10,16].
Spiral	4.0/8.0	Risk-driven cycles re-plan in response to change [5,13,19]; spiral overhead reduces speed of response [6].
Agile + DevSecOps	5.0/10.0	Backlog re-prioritization and pipeline re-runs absorb change within short feedback cycles [1,2,6,7,10,15,16].
Cost-Effectiveness
Waterfall	2.5/5.0	Low automation; late-stage fixes expensive [6,17].
Iterative	3.5/7.0	Partial automation and incremental reuse of security artifacts [7,10].
Spiral	3.0/6.0	Risk analysis is labor-intensive and requires specialist effort each cycle [5,13,14,19].
Agile + DevSecOps	4.0/8.0	Pipeline automation reduces marginal cost per release [1,2,15]; tool sprawl and noisy findings still impose overhead [6,15].

Note. Every rating in Table 11 is justified by reference to specific entries of the synthesized corpus; bracketed numbers cite the corresponding references in the manuscript bibliography.

Under the baseline assumptions, Spiral and Agile with DevSecOps produce similar profiles, but for different reasons. Spiral receives stronger design-time risk ratings, whereas Agile with DevSecOps receives stronger adaptability and continuous-verification ratings. Iterative development occupies a middle position when security work is repeated consistently. Waterfall benefits from explicit early documentation but is sensitive to late change. These are conditional interpretations of the rubric, not observed differences in vulnerability rates.

3.7.7. Weight Sensitivity

Because the baseline weights were chosen by the authors rather than derived through corpus frequencies, expert elicitation, or an analytic hierarchy process, Table 13 reports three alternative weighting scenarios. Equal weighting removes the stated priority structure. The design-heavy scenario assigns 30 points each to requirements and threat modeling. The delivery-heavy scenario assigns 20 points each to development security and testing, and 15 points each to adaptability and cost. The ordering of Waterfall and Iterative is stable, but the ordering of Spiral and Agile with DevSecOps changes. This is the substantive result of the exercise: the rubric exposes value choices; it does not discover a universally best lifecycle.

Table 13. Sensitivity of illustrative profiles to alternative dimension weights.

Weighting Scenario	Waterfall	Iterative	Spiral	Agile with DevSecOps
Baseline (25/25/15/15/10/10)	61.5	75.5	86.0	86.5
Equal (16.7 per dimension)	58.3	75.0	83.3	88.3
Design-heavy (30/30/10/10/10/10)	61.0	75.0	86.0	85.0
Delivery-heavy (15/15/20/20/15/15)	59.5	75.5	84.0	89.0

4. Discussion

4.1. Worked PCI-DSS E-Commerce Illustration

The following scenario is a worked illustration, not a case study and not evidence that the rubric or framework is effective.

The hypothetical system provides registration, login, product browsing, a shopping cart, payment processing, order confirmation, administration, and audit logging. It is assumed to operate within a PCI-DSS compliance program. Relevant assets include customer credentials, payment data, order records, session tokens, administrator accounts, and audit logs.

The illustrative requirements cover confidentiality, integrity, availability, authentication, authorization, and accountability. Threats considered include injection, cross-site scripting, cross-site request forgery, weak authentication, privilege escalation, insecure direct object references, payment-data exposure, inadequate logging, and production misconfiguration.

The planning of the PCI-DSS requirements, security policies, access control policies, encryption rules, and audit logging rules would be the first action of Waterfall. This would assist in the compliance documentation. However, it would be expensive to correct in case of a serious defect such as poor third-party payment processing, as was discovered in the development.

Iterative delivery would deliver the system in a number of cycles. Registration and login can be done during the first cycle, product search and shopping cart during the second cycle, payment processing during the third cycle, and administration and reporting in the following cycles. Threat modeling and security testing can be performed after each cycle.

In Spiral, risk analysis would be done at each cycle. The areas of risk would be considered to be the processing of payment, administration, and logging. With the assistance of STRIDE and attack trees, spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege may be determined. Design and implementation would then be informed by the countermeasures that have been identified.

In Agile using DevSecOps, security would be modeled in the backlog as security user stories, misuse cases as security user stories, and acceptance criteria. CI/CD would include SAST, DAST, dependency scanning, and configuration scanning. The backlog would introduce security concerns, which would be sorted by risk. This practice is a good combination of flexibility and verification, provided the team is not deficient in terms of security consciousness and discipline.

Table 14 summarizes the artifacts and verification differences in this illustration.

Table 14. Illustrative PCI-DSS e-commerce artifacts and verification differences.

Security Requirement	Waterfall	Iterative	Spiral	Agile with DevSecOps
Confidentiality	Encryption and data-flow specification approved at design gate	Encryption tests and data-flow review repeated per increment	Payment-data exposure ranked in each risk cycle; mitigation tied to risk register	Secrets, SAST/DAST, and configuration evidence attached to each release
Integrity	Transaction-integrity controls fixed in baseline design	Tampering tests expanded with each delivered component	Integrity threats drive control selection and residual-risk acceptance	Signed artifacts, protected builds, and integrity tests enforced by pipeline policy
Availability	Recovery objectives and capacity assumptions approved upfront	Resilience tests added as services become available	Availability scenarios re-ranked by business impact each cycle	Deployment health, rollback, and resilience checks supply release and operational evidence
Authentication	Authentication design and quality bar approved before implementation	Login controls and abuse tests refined in successive increments	Account compromise scenarios prioritized in the risk register	Identity tests and critical findings block release under the defined gate policy
Authorization	Role matrix and privilege boundaries baselined at design	Authorization matrix and tests expanded with new functions	Privilege-escalation paths reviewed during each risk cycle	Policy-as-code and negative authorization tests linked to backlog acceptance criteria
Accountability	Audit events, retention, and review responsibility specified early	Audit coverage reviewed after each increment	Repudiation risk determines logging depth and protection	Telemetry completeness and alert tests checked before release; incidents reopen requirements

4.2. Context-Specific Suitability Matrix

Table 15 illustrates how a team might tailor its host lifecycle according to project size, risk, regulatory obligations, delivery cadence, and security capability. It expresses the paper’s contextual proposition; it is not an empirically validated selection rule.

Table 15. Context-specific suitability matrix.

Project Context	Most Suitable Model	Rationale
Documented and stable requirements with heavy documentation needs	Waterfall	Supports planning, documentation, formal reviews, and compliance evidence
Medium to high complexity with changing requirements	Iterative	Enables repeated refinement and security improvement across cycles
High-risk, safety-critical, or high-assurance systems	Spiral	Supports structured risk analysis and threat modeling
Frequent change and multiple releases	Agile with DevSecOps	Enhances agility, automation, and continuous security feedback
Small teams with limited security maturity	Iterative or Agile with lightweight DevSecOps	Allows gradual integration of security practices
Software-as-a-service with regulatory and requirement changes	Spiral–Agile–DevSecOps hybrid	Combines risk analysis, iterative delivery, and continuous security validation

4.3. Interpretation and Implications

The synthesis supports a distinction that is sometimes lost in practice. Secure software development describes the process capability—the roles, activities, tools, and governance used during delivery. The development of secure software describes the desired product outcome. A mature process can reduce risk, but compliance with a process does not by itself prove that the resulting software is secure. Product claims require evidence such as control traceability, adversarial testing, vulnerability escape rates, and operational performance.

The four configurations expose different process tendencies. Waterfall can make requirements and approvals explicit, yet late changes may require substantial rework. Iterative development creates regular opportunities to revise controls, but only if security work is repeated rather than deferred. Spiral gives risk analysis a central place and is therefore plausible for high-assurance work, although its specialist effort can be costly. Agile with DevSecOps can shorten feedback through automation, but a fast pipeline can still deliver insecure software when architecture, tool findings, or security debt are weakly governed. The sensitivity analysis confirms that the apparent leader depends on which of these properties is valued most.

The statement that there is no universally best lifecycle is therefore a design proposition, not a result established by this corpus. Its empirical test would require comparable projects, explicit implementation-fidelity measures, and observed security outcomes. The same caution applies to other lifecycle families omitted from the rubric. Prototyping changes how early uncertainty is explored; Scrum and Kanban organize work and flow rather than supplying complete security processes; and RUP provides iterative phases and artifacts that could host the same security controls. Expanding the rating table without equivalent evidence would create breadth without validity. These methods are better treated as candidate host lifecycles for a future comparative study.

Implementation fidelity is more consequential than the lifecycle label. A project should be considered to have implemented the proposed framework only when required artifacts exist, trace links can be sampled end to end, release decisions follow declared quality bars, exceptions identify an owner and expiry date, and operational findings demonstrably reopen requirements, threat models, or controls. OWASP checklists can supply individual secure-coding checks, SAMM can assess organizational maturity, and SSDF can define expected outcomes; the proposed framework connects those resources to project evidence rather than replacing them.

Delivery pressure also affects every configuration. Schedule pressure may compress early analysis in Waterfall, reduce the depth of repeated review in Iterative development, narrow risk analysis in Spiral, or push security debt behind visible features in Agile. Governance must therefore protect minimum assurance activities and make residual-risk acceptance visible. The conceptual case for a hybrid is not that combining model names guarantees security, but that teams can deliberately combine stable governance, iterative refinement, risk-driven analysis, automated verification, and operational learning.

4.4. LLM-Assisted Programming, Vibe Coding, and Security

LLM-assisted programming changes both the production and review of code. Program-analysis research now covers LLM support for static, dynamic, and hybrid analysis, but also identifies reliability and evaluation challenges [37]. Industrial reflections on AI-assisted, vibe, and agentic coding report productivity gains alongside a shift in effort toward review, with concerns about maintainability, security, over-reliance, and loss of foundational reasoning [38]. A 2025 survey likewise characterizes LLMs as dual-use across the SDLC: they may assist code generation, vulnerability detection, and threat modeling, while introducing insecure suggestions, privacy leakage, dataset contamination, and governance risks [39].

Recent empirical evidence cautions against treating prompting as a security control. Kharma et al. evaluated five LLMs across C, C++17, Java (OpenJDK 17.0.8), and Python 3.12.3 and found that security-aware prompting changed the distribution of weakness categories but did not produce a statistically significant reduction in overall vulnerability frequency or density [40]. This finding is directly relevant to vibe coding, in which developers may accept broad model-generated changes without understanding each implementation decision. Prompt templates and model confidence cannot substitute for a threat model, code ownership, independent review, or executable verification.

Within the proposed cycle, AI-generated code must be treated as untrusted third-party-like input. Teams should record the model and material generation context when policy permits; prevent secrets, personal data, proprietary code, and regulated information from entering unapproved services; require human ownership of generated changes; scan generated code and dependencies; test security properties derived from requirements; and monitor accepted code after release. AI may also help propose project guidance, but such guidance is a tailored selection of established practices, not evidence of methodological novelty. Its value should be judged by coverage, traceability, false omissions, and observed outcomes against a maintained baseline such as SSDF or SAMM.

5. Proposed Hybrid Secure SDLC–DevSecOps Framework

The proposed framework is an execution overlay for a host lifecycle, not a replacement for SSDF, SAMM, SDL, or ISO/IEC 27034 [25]. It has six connected stages and requires evidence to pass between them. Table 16 defines the minimum artifacts, accountability, and completion conditions. A small team may combine roles, but it should not remove the distinction between producing evidence and accepting residual risk.

Table 16. Operational specification of the proposed framework.

Stage	Required Artifacts	Accountable Role	Entry and Exit Criteria	Traceability and Measurable Output
Security requirements	Asset register, security requirements, regulatory mapping, risk tolerance	Product/risk owner with security lead	Enter with scoped service and stakeholders; exit when requirements are testable, prioritized, and approved	Requirement ID linked to asset, threat, control, owner, and acceptance test; coverage and orphan-requirement rate
Secure design	Architecture and data-flow diagrams, trust boundaries, design decisions, dependency strategy	Architect or senior engineer	Enter with approved requirements; exit after design review and resolution or acceptance of high-risk findings	Design decision linked to requirements and controls; review completion and unresolved high-risk count
Threat modeling	Versioned threat model, abuse cases, risk register, mitigation plan	Security lead with development and operations representatives	Enter on new design or material change; exit when threats are ranked, and each treatment has an owner	Threat-to-control and threat-to-test coverage; residual-risk age and mitigation completion
Secure programming	Reviewed change, coding checklist, dependency/SBOM update, provenance record	Change author and independent reviewer	Enter with design and threat context; exit when review and required local checks pass	Commit/change linked to requirement, design decision, and threat; review coverage and security defect density
Automated verification	SAST, DAST, SCA, secrets, container/IaC, and targeted security-test evidence	Release owner; tool owners maintain rules	Enter with releasable build; exit when quality bars pass or an exception is approved	Finding-to-change trace; escape rate, false-positive burden, pipeline latency, and time to remediate
Operations and feedback	Telemetry, incident and vulnerability records, penetration-test results, lessons learned	Service owner with incident/security roles	Enter at deployment; exit only when material observations are dispositioned upstream	Observation linked to reopened requirement, threat, control, or accepted risk; recurrence and feedback-closure time

Release gates should be defined before testing. A practical baseline is to block release for an exploitable critical finding, an unmitigated high-risk threat, failed mandatory security tests, missing provenance for release artifacts, or an unmet regulatory requirement. Medium and lower findings may enter a time-bounded backlog according to risk tolerance. An exception must identify the affected asset, rationale, compensating control, accountable risk owner, expiry date, and review trigger. Emergency releases may use an expedited gate, but they still require recorded approval and retrospective verification.

Supply-chain and cloud-native evidence is part of the same control loop. Component inventories and SBOMs, package provenance, build-environment protection, container and infrastructure-as-code checks, deployment policy, and supplier risk should be linked to the affected release. OWASP SCVS provides a more detailed supply-chain control structure and staged assurance levels that can be used to populate this part of the framework [41]. AI-generated code follows the additional controls discussed above and is never exempt from ownership, review, testing, or data-handling policy.

Tailoring is explicit. A low-maturity team begins with testable requirements, peer review, dependency inventory, secrets scanning, and a small set of blocking tests, then measures false positives and remediation time before adding gates. A mature or high-assurance team adds independent design review, continuous threat-model updates, signed provenance, policy-as-code, broader pipeline coverage, and formal risk acceptance. The minimum invariant is traceability: a team may simplify an artifact, but it must still be possible to follow a security concern from requirement or threat to implementation evidence and operational disposition.

Figure 1 illustrates the proposed circular Secure SDLC–DevSecOps framework.

Figure 1. The Secure SDLC–DevSecOps cycle showing the continuous relationship among secure requirements, secure design, threat modeling, secure programming, automated security testing, and monitoring with feedback to secure requirements.

6. Conclusions

This paper examined how security intent can remain connected to implementation in changing delivery environments. Its central distinction is between secure software development as a process capability and the development of secure software as an outcome that must be demonstrated. The review links requirements, design, threat analysis, programming, verification, and operations through traceable evidence rather than treating any individual tool or lifecycle label as sufficient.

The weighted profiles are illustrative author judgments. They show why Spiral becomes more attractive when design-time risk analysis is emphasized and why Agile with DevSecOps becomes more attractive when adaptation and continuous verification are emphasized. Sensitivity analysis reverses their ordering under different plausible weights. The comparison therefore does not establish a best model or a universal “no one-size-fits-all” result; it identifies a proposition that should be tested using project context, implementation fidelity, and observed security outcomes.

The framework’s contribution is also deliberately bounded. Its six practices overlap with NIST SSDF, OWASP SAMM, Microsoft SDL, ISO/IEC 27034 [25], MetaSEnD, and OWASP guidance. What it adds is an operational project-level schema: required artifact classes, accountable roles, entry and exit criteria, cross-artifact traceability, release gates, exception rules, maturity tailoring, and feedback measures. Figure 1 summarizes that control loop. The PCI-DSS scenario illustrates its use but provides no validation.

Evaluation now requires real projects. Future studies should preserve independent rubric ratings and report weighted agreement; compare host lifecycles that apply equivalent security overlays; and measure vulnerability escape rate, remediation time, false-positive burden, pipeline latency, requirement-to-control traceability, feedback-closure time, and developer adoption. At least one evaluator should be independent of the framework authors. Studies should also test supply-chain, cloud-native, and AI-assisted development settings. In particular, LLM-generated code should be evaluated as untrusted input whose security depends on human ownership, data governance, traceable requirements, and executable verification rather than prompt wording alone.