Pith. sign in

REVIEW 4 major objections 7 minor 61 references

Incorporating Verification Standards for Security Requirements Generation from Functional Specifications

T0 review · 4 major / 7 minor · reviewed 2026-08-15 · deepseek-v4-flash

Pith's one-line read F2SRD generates security requirements by first retrieving the most relevant OWASP ASVS verification checks and then prompting GPT-4 with them, beating standalone GPT-4 and RelGAN on inspiration, diversity, and specificity.

desk verdict A useful, honest pipeline for LLM-based security requirement generation whose headline comparison leaves the role of relevant retrieval unproven. read the letter →

arxiv 2505.11857 v1 pith:I33IAZ66 submitted 2025-05-17 cs.SE

classification cs.SE
keywords securityrequirementsgenerationfunctionalOWASPASVSverificationretrievalretrieval-augmentedColBERTv2largelanguagemodelsengineering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Security requirements are often written late and incompletely because engineers lack security expertise. F2SRD is a two-phase method that turns functional requirements (FRs) into security requirements (SRs) without that expertise: a retriever trained on synthetic FR-verification-requirement (VR) pairs selects the most relevant OWASP ASVS verification checks for a given FR, and those VRs are placed into structured prompts that direct GPT-4 to write concrete SRs, or to decline when the VR does not apply. The authors report that F2SRD outperforms standalone GPT-4 and RelGAN on inspiration, diversity, and specificity across all three project datasets, and that human raters score its SRs as more specific and more inspiring. The practical claim is that anchoring generation to standard verification checks is what turns generic security advice into actionable requirements.

What carries the argument

The load-bearing component is the weighted late-interaction retriever. An FR and a VR are encoded as token-level vectors by shared encoders; a learnable weight embedding layer assigns each VR token a weight initialized from TF-IDF; and the final similarity score is computed as $$\mathrm{Sim}_{FR,VR} = \sum_{i \in m} \max_{j \in n} \left( W_{VR} \cdot \mathrm{CosSim}(E_{FR}, E_{VR}) \right).$$ This lets a single meaningful token, such as "registration," drive a match even when the FR and VR share little overall wording. In the generation phase the retrieved VRs become the steering content of the GPT-4 prompt, which also contains worked positive and negative examples and an instruction to emit no SR when the VR is irrelevant.

What would settle it

Randomize the VR condition: feed GPT-4 randomly selected ASVS verification requirements instead of the retriever's top-five for the same functional requirements; if the inspiration, diversity, and specificity scores stay at F2SRD levels, the claimed benefit comes from adding standard text rather than from retrieving the relevant checks.

Watch

Extended reading notes

Core claim

The paper's central claim is that relevant security verification standards are the key conditioning signal for generating high-quality security requirements. F2SRD learns to match functional requirements to verification requirements from the OWASP ASVS using a ColBERTv2-style late-interaction retriever augmented with a learnable token-weighting layer initialized from TF-IDF statistics over the ASVS corpus; after GPT-4-synthesized pairs are filtered by a zero-shot retriever, 1,536 FR-VR pairs form the training set. At inference the retriever recommends five VRs per FR, and GPT-4 is instructed to judge whether the FR truly needs verification by that VR and, when it does, to write a targeted SR. The paper reports retriever accuracy of 80.4% against consensus human labels, with human labelers reaching 85.1% agreement with the consensus, and both quantitative metrics and human-subject ratings in which F2SRD scores above RelGAN and standalone GPT-4 on inspiration, diversity, and specificity.

Load-bearing premise

The approach stands on the assumption that the GPT-4-synthesized functional-requirement/verification-requirement pairs used to train the retriever encode genuine relevance rather than prompt-template artifacts, and that the consensus labels used as ground truth are trustworthy despite annotators' initial inter-rater reliability of only 0.47.

Editorial extensions

If this is right

  • If the reported results hold, requirements engineers can draft security requirements immediately from functional specifications, with the retriever surfacing the ASVS checks most likely to apply and the LLM turning them into concrete statements.
  • The generated SRs remain traceable to a recognized verification standard, so the same pipeline can double as an early ASVS compliance check rather than producing free-floating security advice.
  • The retriever's 80.4% accuracy indicates that automated FR-to-VR mapping is close to human-level on these projects, meaning the main bottleneck shifts from finding relevant checks to judging whether an SR is actually implementable.
  • Because the method is built on a generic retrieve-then-prompt recipe, the same design can in principle be retargeted to other security standards once a retriever is trained on the corresponding VR corpus.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The retriever was trained on GPT-4-generated FRs, so the reported gains may depend on how closely real-world FRs resemble the prompting style used to create the synthetic pairs; this can be checked by testing on human-written FRs from other domains.
  • A control experiment that feeds GPT-4 randomly chosen VRs rather than retrieved ones would isolate whether the quality gain comes from retrieval relevance or merely from adding standard-sounding text to the prompt; the paper does not run this control.
  • The human evaluation only compared F2SRD with GPT-4, so the apparent superiority over RelGAN rests on quantitative metrics; a head-to-head human reading of RelGAN outputs after filtering could give a fuller picture.
  • Since the pipeline is standard-agnostic at the architecture level, adapting it to ISO/IEC 15408 or FIPS 200 would test whether verification standards generalize as generation guidance, a step the paper leaves for future work.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. This paper proposes F2SRD, a two-phase approach that generates security requirements (SRs) from functional requirements (FRs) by first retrieving relevant verification requirements (VRs) from the OWASP ASVS standard and then prompting GPT-4 with the FR plus the top-5 VRs. Phase I synthesizes FR-VR pairs with GPT-4, filters them with ColBERTv2, and trains a ColBERTv2-based retriever augmented with a learnable token-weight embedding initialized from TF-IDF. Phase II uses the retriever to select the top-5 VRs for each FR and asks GPT-4 to generate an SR when the VR is deemed relevant. The authors evaluate the retriever on three RE'17 datasets (ePurse, CPN, GPS), report 80.4% accuracy against a human-consensus gold standard, and compare the generated SRs against RelGAN and a standalone GPT-4 baseline on self-information, self-BLEU, vocabulary size, and human-rated inspiration and specificity. The central claim is that retrieval of relevant ASVS VRs, rather than generic prompting, is what makes the generated SRs more inspired, diverse, and specific.

Significance. If the central claim holds, the paper makes a useful contribution: it demonstrates a concrete way to ground LLM-based security requirements generation in established verification standards, with an evaluation framework that combines quantitative metrics, human scoring, and public artifacts. The RE'17 benchmark datasets are external, the human evaluation for SR quality shows strong inter-rater reliability (ICC=0.82), and the reported differences versus both baselines are substantial and statistically significant. The authors also make data and scripts publicly available via figshare, which aids replication. However, the evaluation does not currently isolate the effect of relevant retrieval from the effect of simply providing any ASVS-style context, and the retriever's training data and gold standard are acknowledged to be weakly validated. These issues are fixable and do not undermine the value of the framework, but they must be addressed before the causal claim about relevance can be accepted.

major comments (4)
  1. [Section 4.3.2, Tables 4 and 6] The central claim that relevant VR retrieval is the cause of the quality gains is not tested. The F2SRD prompt in Fig. 5 includes the FR, five ASVS VRs, and two worked examples, while the GPT-4 baseline prompt (Fig. 10 in the replication package) contains no VR context. The comparison therefore varies at least three factors—presence of standard-derived domain vocabulary, prompt length, and example count—in addition to VR relevance. The qualitative examples in Fig. 7 are consistent with any injection of ASVS-specific context (e.g., subdomain takeover, DNS expiry, LFI/RFI). A random-VR ablation, in which the same prompt template is used with randomly selected ASVS VRs, is necessary to attribute the gains in Table 4 and Table 6 to relevant retrieval. Without it, the abstract's claim that relevant VRs are what make the SRs 'more focused' is not supported by the data.
  2. [Section 3, Step 1 and Section 5 (Construct Validity)] The paper acknowledges in Section 5 that 'We did not assess the quality of this synthetically generated data.' This is load-bearing: the 1,536 synthetic FR-VR pairs are the only training data for the retriever, and the retriever's accuracy in Table 2 is measured on FRs from the same source type. If GPT-4's synthetic FRs share template-specific patterns with the prompts used to create them, the retriever may learn those patterns rather than genuine FR-VR relevance. The filtering by zero-shot ColBERTv2 (top-30% threshold) mitigates but does not eliminate this risk, because the filter is itself an automatic model with no human validation. Please add a sample-based human quality assessment of the synthesized pairs, or validate the retriever on independently labeled FR-VR pairs.
  3. [Section 4.2] The gold standard for retriever evaluation is a consensus derived from annotators whose independent agreement was only ICC(2,k)=0.47, which is generally considered moderate. The consensus procedure may improve label quality, but the low initial agreement shows that the relevance construct is difficult even for humans; the reported accuracy rates (80.4% vs 85.1%) should therefore be interpreted with caution. Please report per-annotator accuracy or expert-validated labels, and report an agreement measure on the final consensus labels (e.g., Cohen's kappa for the two-raters-after-discussion step). This matters because RQ1's conclusion about the retriever's utility rests entirely on this gold standard.
  4. [Section 4.3.4, Eq. (5)] The self-information metric as defined is not normalized for sequence length. If p(SR) is the joint probability of the SR under Davinci-002, longer SRs will tend to have lower p and hence higher SI, independent of 'unexpectedness.' Since F2SRD's SRs are visibly longer and more detailed (e.g., Fig. 7), the SI advantage in Table 4 may partly reflect verbosity rather than inspiration. Please report a length-normalized variant (e.g., average per-token negative log-likelihood) or include SR length as a covariate/an effect-size control. This does not undermine the human inspiration results in Table 6, but it is needed for the quantitative claim.
minor comments (7)
  1. [Section 4.2, paragraph after Table 2] The phrase 'achieved average accuracy gains of 34.45% and 8.94%, respectively' is inconsistent with the preceding sentence; these are relative improvements when the steps are included, not gains when they are removed.
  2. [Figure 6 caption] The caption contains a duplicated word: 'Relevance Between Between FR and VR.'
  3. [Section 4.3.6] The sentence beginning 'The higher Self-Information exception in CPN, as observed with GPT-4' is confusing because in Table 4 the CPN exception is RelGAN's higher self-information (160.70 vs GPT-4's 141.17), not GPT-4's; please rephrase.
  4. [Equations (5) and (6)] Please specify the exact computation of p(SR) from Davinci-002 (e.g., joint token probability, temperature, decoding parameters) and the tokenization/BLEU settings used for Self-BLEU.
  5. [Section 4.3.4] The text 'does not make any sence' should read 'does not make any sense.'
  6. [Section 4.3.2] The description 'the dialogue interface of GPT-4' should identify the model version and sampling parameters (temperature, max tokens) for reproducibility; the same applies to the GPT-4 calls used for F2SRD and for synthetic data generation.
  7. [References] References [24] and [25] are the same ICSE 2023 paper and should be consolidated.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: F2SRD's derivation and evaluation are self-contained, resting on external benchmarks, human judgment, and an independent scorer; the only self-citation is non-load-bearing.

full rationale

F2SRD's derivation chain is: GPT-4 synthesizes FR-VR pairs (Step 1); a ColBERTv2-backbone retriever with a learnable token-weight layer is trained on those pairs (Step 2); the retriever selects top-5 VRs for each real RE'17 FR, and GPT-4 generates SRs from the FR-VR prompt (Step 3); SRs are scored by self-information from Davinci-002, self-BLEU, vocabulary size, and source-blinded human raters (Section 4.3). No output is defined as its own input. The retriever is validated against human consensus on authentic FRs (Section 4.2), not against the synthetic training labels, so its reported accuracy is not the fitted objective renamed as a prediction. The SR quality metrics are external to the fitted retriever: Davinci-002 provides the probability model for self-information, and the human study is blinded to source. The only author-overlapping citations ([55,56]) support an analogy about good/bad prompt examples in code repair; the central claim is justified by external ASVS, ColBERTv2, and GPT-4 plus the Table 2 ablations and human study, so the self-citation is not load-bearing. The manuscript's admitted limitations - Section 5: 'We did not assess the quality of this synthetically generated data,' and the internal-validity discussion of possible ColBERTv2 filtering bias - are construct/design threats, not circular reductions. The missing random-VR ablation is an attribution gap (any ASVS context might explain the gains), and the early ICC of 0.47 bears on annotation reliability; neither makes an equation reduce to its input. Hence no circular step is identified.

Assumptions & free parameters 4 free parameters · 5 assumptions · 1 invented entities

The central method relies on several unproven background assumptions: the synthetic FR-VR pairs capture true relevance, ASVS VRs are an appropriate guide for these domains, the proxy metrics define inspiration and diversity, and the consensus annotations provide a reliable gold standard despite low initial agreement. These are stated in Section 5 as threats to validity.

free parameters (4)
  • Number of synthesized FRs per VR = 10
    Step 1 of Section 3 generates ten functional requirements for each of 241 VRs; this count is chosen without sensitivity analysis.
  • Relevance filtering cutoff = Top 30% of ColBERTv2 retrieval
    Synthetic FR-VR pairs are kept only if the paired VR ranks in the top 30%; the paper cites prior work for this choice and shows an ablation 'w/o data filtering' that changes retriever accuracy by about 8.94%.
  • Number of retrieved VRs per FR = 5
    Phase II retrieves the top five VRs per FR for SR generation; no ablation on K is reported.
  • Learning rates for retriever = 3e-5 and 6e-7
    Listed in Section 4.3.2; the weight layer uses 6e-7 while the ColBERTv2 backbone uses 3e-5.
assumptions (5)
  • domain assumption GPT-4-synthesized FRs, after ColBERTv2 filtering, are valid relevance labels for training the VR retriever.
    Section 3 Step 1 uses these pairs as training data; Section 5 admits their quality was not independently assessed.
  • domain assumption OWASP ASVS verification requirements are an appropriate and sufficiently complete guide for generating security requirements in the ePurse, CPN, and GPS domains.
    The paper selects ASVS 4.0.3 as a de facto standard (Section 2.1) without validating coverage for the three test datasets.
  • domain assumption Self-information and Self-BLEU/vocabulary size measure the inspiration and diversity of security requirements.
    Section 4.3.4 defines these proxies; the paper does not show that high unexpectedness or lexical diversity corresponds to higher-quality SRs.
  • domain assumption Welch's t-test treats individual generated SRs as independent samples.
    Multiple SRs can derive from the same FR-VR pair; the test in Section 4.3.6 does not account for within-FR correlation.
  • domain assumption Consensus annotations after discussion are a reliable gold standard for FR-VR relevance despite low initial ICC (0.47).
    Section 4.2 uses the consensus as gold standard for retriever accuracy; initial inter-rater agreement was only moderate.
invented entities (1)
  • Learnable weight embedding layer initialized with TF-IDF token weights
    purpose: Assigns variable importance to VR tokens during token-level cosine similarity (Eq. 2 and 3).
    The paper does not isolate this layer in an ablation; the 'w/o training' variant removes all training, so the layer's individual contribution has no independent evidence.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Incorporating Verification Standards for Security Requirements Generation from Functional Specifications." pith.science (2026). https://pith.science/paper/I33IAZ66

@misc{pith2026250511857,
  author       = {Pith},
  title        = {Pith review of: Incorporating Verification Standards for Security Requirements Generation from Functional Specifications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/I33IAZ66}},
  note         = {Machine review of arXiv:2505.11857}
}
read the original abstract

In the current software driven era, ensuring privacy and security is critical. Despite this, the specification of security requirements for software is still largely a manual and labor intensive process. Engineers are tasked with analyzing potential security threats based on functional requirements (FRs), a procedure prone to omissions and errors due to the expertise gap between cybersecurity experts and software engineers. To bridge this gap, we introduce F2SRD (Function to Security Requirements Derivation), an automated approach that proactively derives security requirements (SRs) from functional specifications under the guidance of relevant security verification requirements (VRs) drawn from the well recognized OWASP Application Security Verification Standard (ASVS). F2SRD operates in two main phases: Initially, we develop a VR retriever trained on a custom database of FR and VR pairs, enabling it to adeptly select applicable VRs from ASVS. This targeted retrieval informs the precise and actionable formulation of SRs. Subsequently, these VRs are used to construct structured prompts that direct GPT4 in generating SRs. Our comparative analysis against two established models demonstrates F2SRD's enhanced performance in producing SRs that excel in inspiration, diversity, and specificity essential attributes for effective security requirement generation. By leveraging security verification standards, we believe that the generated SRs are not only more focused but also resonate stronger with the needs of engineers.

Figures

Figures reproduced from arXiv: 2505.11857 by the authors.

Figure 1
Figure 1. Examples of GPT-4 Generating Generic Security Requirements for Diverse Functional Requirements. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. An Example Demonstrating How the Paired VR Specifies Verification Criteria for the Given FR. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. The Overview of F2SRD. You are a requirements engineer. Now you are deriving functional requirements that correspond to specific security verification requirements. The resulting functional requirements should include the functionalities that will be assessed by the given verification criteria. Below are three instructive examples. Each example includes a targeted security verification requirement, an exemplar of a … view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Data Synthesis Prompt Template Used in Step 1 of F2SRD. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: SR Generation Prompt Used in Step 3 of F2SRD. [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: An Example of Indirect Yet Important Relevance Between Between FR and VR. [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: Three Examples showing the Generation of GPT-4 and our [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: A Failure Case Illustrating An Incorrect VR Recommendation Leads to Inappropriate SR Generation. [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]
Figure 9
Figure 9. Figure 9: A Failure Case Illustrating some SRs for different FRs can be merged. [PITH_FULL_IMAGE:figures/full_fig_p019_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 32 canonical work pages

  1. [1]

    ISO/IEC/IEEE Draft International Standard - Systems and Software Engineering – Life Cycle Processes – Requirements Engineering.ISO/IEC/IEEE P29148_FDIS, September 2018(2018), 1–104

    2018. ISO/IEC/IEEE Draft International Standard - Systems and Software Engineering – Life Cycle Processes – Requirements Engineering.ISO/IEC/IEEE P29148_FDIS, September 2018(2018), 1–104

  2. [2]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report.arXiv preprint arXiv:2303.08774 (2023)

  3. [3]

    Javed Ahmad, Chaudhary Wali Mohammad, and Mohd Sadiq. 2021. Identification of Security Requirements from the Selected Set of Requirements under Fuzzy Environment. In2021 International Conference on Computing, Communication, and Intelligent Systems (ICCCIS). 58–63. https://doi.org/10.1109/ICCCIS51004.2021.9397153

  4. [4]

    2018.Risks, security, and privacy for HIV/AIDS data: Big data perspective

    Md Tarique Ansari and Dhirendra Pandey. 2018.Risks, security, and privacy for HIV/AIDS data: Big data perspective. 117–139. https://doi.org/10.4018/978-1-5225-3203-3.ch005

  5. [5]

    Md Tarique Jamal Ansari, Dhirendra Pandey, and Mamdouh Alenezi. 2022. STORE: Security Threat Oriented Require- ments Engineering Methodology.Journal of King Saud University - Computer and Information Sciences34, 2 (2022), 191–203. https://doi.org/10.1016/j.jksuci.2018.12.005

  6. [6]

    Tianshu Bao, Jing Yang, Yilong Yang, and Yongfeng Yin. 2022. RM2Doc: A Tool for Automatic Generation of Require- ments Documents from Requirements Models. In2022 IEEE/ACM 44th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). 188–192. https://doi.org/10.1145/3510454.3516850

  7. [7]

    Brian Berenbach. 2003. The Automated Extraction of Requirements from UML Models. In11th IEEE International Conference on Requirements Engineering (RE 2003), 8-12 September 2003, Monterey Bay, CA, USA. IEEE Computer Society, 287

  8. [8]

    Luiz Bonifacio, Hugo Abonizio, Marzieh Fadaee, and Rodrigo Nogueira. 2022. Inpars: Data augmentation for information retrieval using large language models.arXiv preprint arXiv:2202.05144(2022)

Show all 61 references
  1. [9]

    Sravani Teja Bulusu, Romain Laborde, Ahmad Samer Wazan, François Barrère, and Abdelmalek Benzekri. 2017. Towards the weaving of the characteristics of good security requirements. InRisks and Security of Internet and Systems: 11th International Conference, CRiSIS 2016, Roscoff,...

  2. [10]

    Bleistein, and June M

    Karl Cox, Keith Phalp, Steven J. Bleistein, and June M. Verner. 2005. Deriving requirements from process models via the problem frames approach.Inf. Softw. Technol.47, 5 (2005), 319–337

  3. [11]

    Zhuyun Dai, Vincent Y Zhao, Ji Ma, Yi Luan, Jianmo Ni, Jing Lu, Anton Bakalov, Kelvin Guu, Keith B Hall, and Ming-Wei Chang. 2022. PROMPTAGATOR: FEW-SHOT DENSE RETRIEVAL FROM 8 EXAMPLES.arXiv preprint arXiv:2209.11755(2022)

  4. [12]

    Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. 2024. The llama 3 herd of models.arXiv preprint arXiv:2407.21783 (2024)

  5. [13]

    Sarah Elder, Nusrat Zahan, Valeri Kozarev, Rui Shu, Tim Menzies, and Laurie Williams. 2021. Structuring a Comprehen- sive Software Security Course Around the OWASP Application Security Verification Standard. In2021 IEEE/ACM 43rd International Conference on Software Engineering...

  6. [14]

    Méndez Fernández, S

    D. Méndez Fernández, S. Wagner, M. Kalinowski, M. Felderer, P. Mafra, A. Vetrò, T. Conte, M. T. Christiansson, D. Greer, C. Lassenius, T. Männistö, M. Nayabi, M. Oivo, B. Penzenstadler, D. Pfahl, R. Prikladnicki, G. Ruhe, A. Schekelmann, S. Sen, R. Spinola, A. Tuzcu, J. L. De ...

  7. [15]

    R. A. Fisher. 1992.Statistical Methods for Research Workers. Springer New York, New York, NY, 66–70. https: //doi.org/10.1007/978-1-4612-4380-9_6

  8. [16]

    2018.Software requirements classification using word embeddings and convolutional neural networks

    Vivian Fong. 2018.Software requirements classification using word embeddings and convolutional neural networks. Master’s thesis. California Polytechnic State University

  9. [17]

    Hemanth Gudaparthi, Nan Niu, Boyang Wang, Tanmay Bhowmik, Hui Liu, Jianzhang Zhang, Juha Savolainen, Glen Horton, Sean Crowe, Thomas Scherz, and Lisa Haitz. 2023. Prompting Creative Requirements via Traceable and Adversarial Examples in Deep Learning. In2023 IEEE 31st Internat...

  10. [18]

    Siv Hilde Houmb, Shareeful Islam, Eric Knauss, Jan Jürjens, and Kurt Schneider. 2010. Eliciting security requirements and tracing them to design: an integration of Common Criteria, heuristics, and UMLsec.Requirements Engineering15 (2010), 63–93

  11. [19]

    IEC ISO. 2011. Ieee: Iso/iec/ieee 29148, systems and software engineering, life cycle processes.Requirements engineering 600 (2011)

  12. [20]

    Vitor Jeronymo, Luiz Bonifacio, Hugo Abonizio, Marzieh Fadaee, Roberto Lotufo, Jakub Zavrel, and Rodrigo Nogueira

  13. [21]

    Gyula Katona and O Nemetz. 1976. Huffman codes and self-information.IEEE Transactions on Information Theory22, 3 (1976), 337–340

  14. [22]

    Eric Knauss, Siv Houmb, Kurt Schneider, Shareeful Islam, and Jan Jürjens. 2011. Supporting Requirements Engineers in Recognising Security Issues. InRequirements Engineering: Foundation for Software Quality, Daniel Berry and Xavier Franch (Eds.). Springer Berlin Heidelberg, Ber...

  15. [23]

    Terry K Koo and Mae Y Li. 2016. A Guideline of Selecting and Reporting Intraclass Correlation Coefficients for Reliability Research.Journal of chiropractic medicine15 (2016), 155–163. Issue 2

  16. [24]

    Viktoria Koscinski, Sara Hashemi, and Mehdi Mirakhorli. 2023. On-demand security requirements synthesis with relational generative adversarial networks. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1609–1621

  17. [25]

    Viktoria Koscinski, Sara Hashemi, and Mehdi Mirakhorli. 2023. On-Demand Security Requirements Synthesis with Relational Generative Adversarial Networks. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 1609–1621. https://doi.org/10.1109/ICSE48619.2...

  18. [26]

    2021.The Cost of Poor Software Quality in the US: A 2020 Report

    Kerb Krasner. 2021.The Cost of Poor Software Quality in the US: A 2020 Report. Technical Report. CISQ

  19. [27]

    2009.Requirements engineering: from system goals to UML models to software specifications

    A van Lamsweerde. 2009.Requirements engineering: from system goals to UML models to software specifications. John Wiley & Sons, Ltd

  20. [28]

    Renaud De Landtsheer, Emmanuel Letier, and Axel van Lamsweerde. 2004. Deriving tabular event-based specifications from goal-oriented requirements models.Requir. Eng.9, 2 (2004), 104–120

  21. [29]

    2021.Software Architecture in Practice, 4th Edition

    Rick Kazman Len Bass, Paul Clements. 2021.Software Architecture in Practice, 4th Edition. Addison-Wesley Professional

  22. [30]

    Emmanuel Letier and Axel van Lamsweerde. 2002. Deriving operational software specifications from system goals. InProceedings of the Tenth ACM SIGSOFT Symposium on Foundations of Software Engineering 2002, Charleston, South Carolina, USA, November 18-22, 2002. ACM, 119–128

  23. [31]

    Hongbo Li, Xiaohong Li, Jianye Hao, Guangquan Xu, Zhiyong Feng, and Xiaofei Xie. 2017. FESR: A Framework for Eliciting Security Requirements Based on Integration of Common Criteria and Weakness Detection Formal Model. In2017 IEEE International Conference on Software Quality, R...

  24. [32]

    Neil A. M. Maiden, Sharon Manning, Sara Jones, and John Greenwood. 2005. Generating requirements from systems models using patterns: a case study.Requir. Eng.10, 4 (2005), 276–288

  25. [33]

    George Markowsky. 2024. Information Theory. https://www.britannica.com/science/information-theory.Encyclopedia Britannica(2024)

  26. [34]

    Mead and Ted Stehney

    Nancy R. Mead and Ted Stehney. 2005. Security quality requirements engineering (SQUARE) methodology.SIGSOFT Softw. Eng. Notes30, 4 (may 2005), 1–7. https://doi.org/10.1145/1082983.1083214

  27. [35]

    Farid Meziane, Nikos Athanasakis, and Sophia Ananiadou. 2008. Generating Natural Language specifications from UML class diagrams.Requir. Eng.13, 1 (2008), 1–18

  28. [36]

    Venia Noella Nanisura Damanik and Septia Ulfa Sunaringtyas. 2020. Secure Code Recommendation Based on Code Review Result Using OWASP Code Review Guide. In2020 International Workshop on Big Data and Information Security (IWBIS). 153–158. https://doi.org/10.1109/IWBIS50925.2020.9255559

  29. [37]

    Weili Nie, Nina Narodytska, and Ankit Patel. 2019. RelGAN: Relational Generative Adversarial Networks for Text Generation. InInternational Conference on Learning Representations. https://openreview.net/forum?id=rJedV3R5tm

  30. [38]

    Maria Riaz, Jason King, John Slankas, and Laurie Williams. 2014. Hidden in plain sight: Automatically identifying security requirements from natural language artifacts. In2014 IEEE 22nd International Requirements Engineering Conference (RE). 183–192. https://doi.org/10.1109/RE...

  31. [39]

    Jon Saad-Falcon, Omar Khattab, Keshav Santhanam, Radu Florian, Martin Franz, Salim Roukos, Avirup Sil, Md Sultan, and Christopher Potts. 2023. UDAPDR: Unsupervised Domain Adaptation via LLM Prompting and Distillation of Rerankers. InProceedings of the 2023 Conference on Empiri...

  32. [40]

    Keshav Santhanam, Omar Khattab, Jon Saad-Falcon, Christopher Potts, and Matei Zaharia. 2021. Colbertv2: Effective and efficient retrieval via lightweight late interaction.arXiv preprint arXiv:2112.01488(2021). Proc. ACM Softw. Eng., Vol. 2, No. FSE, Article FSE077. Publication...

  33. [41]

    Khattab, Jon Saad-Falcon, Christopher Potts, and Matei A

    Keshav Santhanam, O. Khattab, Jon Saad-Falcon, Christopher Potts, and Matei A. Zaharia. 2021. ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction. InNorth American Chapter of the Association for Computational Linguistics. https://api.semanticscholar.o...

  34. [42]

    Contrast Security. 2020. 2020 Application Security Observability Report. https://www.contrastsecurity.com/hubfs/2020- Contrast-Labs-Application-Security-Observability_Annual_Report_07152020.pdf

  35. [43]

    C. E. Shannon. 1948. A mathematical theory of communication.The Bell System Technical Journal27, 3 (1948), 379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

  36. [44]

    Amina Souag, Raúl Mazo, Camille Salinesi, and Isabelle Comyn-Wattiau. 2018. Using the AMAN-DA Method to Generate Security Requirements: A Case Study in the Maritime Domain.Requir. Eng.23, 4 (nov 2018), 557–580. https://doi.org/10.1007/s00766-017-0279-5

  37. [45]

    Amina Souag, Raúl Mazo, Camille Salinesi, and Isabelle Comyn-Wattiau. 2018. Using the AMAN-DA method to generate security requirements: a case study in the maritime domain.Requirements Engineering23 (2018), 557–580

  38. [46]

    Jessica Steinmann and Omar Ochoa. 2022. Supporting Security Requirements Engineering through the Development of The Secure Development Ontology. In2022 IEEE 16th International Conference on Semantic Computing (ICSC). 151–158. https://doi.org/10.1109/ICSC52841.2022.00031

  39. [47]

    The OWASP®Foundation. 2008. OWASP Application Security Verification Standard (ASVS). Accessed August 26,

  40. [48]

    Oktay Türetken, Onur Su, and Onur Demirörs. 2004. Automating software requirements generation from business process models. In1st Conf. on the Principles of Software Eng.(PRISE’04), Buenos Aires, Argentina

  41. [49]

    Nasser Vali and Nasser Modiri. [n. d.]. ISO/IEC 15408. ([n. d.])

  42. [50]

    Axel Van Lamsweerde. 2004. Goal-oriented requirements enginering: a roundtrip from research to practice [enginering read engineering]. InProceedings. 12th IEEE International Requirements Engineering Conference, 2004.IEEE, 4–7

  43. [51]

    Axel van Lamsweerde and Laurent Willemet. 1998. Inferring Declarative Requirements Specifications from Operational Scenarios.IEEE Trans. Software Eng.24, 12 (1998), 1089–1114

  44. [52]

    B L Welch. 1947. The generalization of Student’s problem when several different population variances are involved. Biometrika34, 1-2 (1947), 28–35

  45. [53]

    Junjie Ye, Xuanting Chen, Nuo Xu, Can Zu, Zekai Shao, Shichun Liu, Yuhan Cui, Zeyang Zhou, Chao Gong, Yang Shen, et al. 2023. A comprehensive capability analysis of gpt-3 and gpt-3.5 series models.arXiv preprint arXiv:2303.10420 (2023)

  46. [54]

    Eric S. K. Yu, Philippe Du Bois, Eric Dubois, and John Mylopoulos. 1995. From Organization Models to System Requirements: A ’Cooperating Agents’ Approach. InProceedings of the Third International Conference on Cooperative Information Systems (CoopIS-95), May 9-12. 194–204

  47. [55]

    Jiuang Zhao, Donghao Yang, Li Zhang, Xiaoli Lian, and Zitian Yang. 2024. Enhancing LLM-Based Automated Program Repair with Design Rationales. arXiv:2408.12056 [cs.SE] https://arxiv.org/abs/2408.12056

  48. [56]

    Jiuang Zhao, Zitian Yang, Li Zhang, Xiaoli Lian, and Donghao Yang. 2024. A Novel Approach for Automated Design Information Mining from Issue Logs. arXiv:2405.19623 [cs.SE] https://arxiv.org/abs/2405.19623

  49. [57]

    Ziyan Zhao, Li Zhang, Xiaoli Lian, Xiaoyun Gao, Heyang Lv, and Lin Shi. 2023. ReqGen: Keywords-Driven Software Requirements Generation.Mathematics11 (01 2023), 332. https://doi.org/10.3390/math11020332

  50. [58]

    Yaoming Zhu, Sidi Lu, Lei Zheng, Jiaxian Guo, Weinan Zhang, Jun Wang, and Yong Yu. 2018. Texygen: A benchmarking platform for text generation models. InThe 41st international ACM SIGIR conference on research & development in information retrieval. 1097–1100

  51. [59]

    Katarzyna Łukasiewicz and Sara Cygańska. 2019. Security-oriented agile approach with AgileSafe and OWASP ASVS. In2019 Federated Conference on Computer Science and Information Systems (FedCSIS). 875–878. https://doi.org/10. 15439/2019F213 Received 2024-09-12; accepted 2025-04-0...

  52. [2023]

    Inpars-v2: Large language models as efficient dataset generators for information retrieval.arXiv preprint arXiv:2301.01820(2023)

  53. [2024]

    https://owasp.org/www-project-application-security-verification-standard/

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.