dataesr/scientific-paragraphs-categorization huggingface dataset:
The main innovation in VeriDevOps is the direct use of security requirements written in natural language for security test automation and monitoring. The ability to convert these natural language security requirements into automated testing and monitoring rules enables more seamless and continuous integration of security within the DevOps lifecycle. Finally, using natural language for security requirements fosters continuous feedback and learning opportunities. By observing the outcomes of the automated tests and monitoring, teams can improve and refine their security requirements, leading to a more mature, robust, and secure system over time.
This paper presents a survey on MBST techniques, including security functional testing, model-based fuzzing, risk-and threat-oriented testing, and the use of security test patterns. Granata et al. [6]  address the complexity of software systems due to expanding IT infrastructures and the accompanying challenges in managing software vulnerabilities and cybersecurity issues. Even though security-oriented methodologies like SecDevOps have emerged to identify security problems early in the software development life cycle, their integration into standard or custom software development life cycles, as well as, design evaluation and risk management methodologies, remains difficult. To alleviate this, Granata et al. propose MetaSEnD, a new meta-model that outlines the main activities in a Secure Software Development Life Cycle (SS-DLC), and demonstrate its application in a continuous integration pipeline of a sample microservices application.
These approaches incorporate security principles into software development but leave certain aspects unaddressed. In traditional DevOps practices, there exists a critical disconnect where automation and security are not integral to the DevOps lifecycle -they are often treated as separate processes. This forms a gap that can lead to vulnerabilities in the software system. Furthermore, reliance on manual security testing and monitoring methods can lead to inefficiencies and potentially undetected vulnerabilities, further expanding the gaps. VeriDevOps  [15]  fills these gaps by formalizing security requirements, generating trace monitors, locating root causes of vulnerabilities, and identifying security flaws in code and designs. VeriDevOps focuses on improving automation in DevOps for system protection, offering a more comprehensive approach to building secure, trustworthy systems efficiently and effectively.
VERIDEVOPS METHODOLOGY VeriDevOps is a methodology that combines the principles of De-vOps and early verification, test automation and monitoring to ensure that software systems are secure and reliable. An overview is shown in Figure  1. It aims to provide a systematic approach to software development that ensures that security requirements are met throughout various stages of software development. The methodology involves the use of Natural Language Processing (NLP), specification of security requirements, automatic quality assurance to verify the correctness of software systems and the use of DevOps practices to ensure that software systems are developed and deployed securely and reliably. VeriDevOps automates essential components of software development with security considerations. This includes the specification and analysis of security-related requirements, system testing and monitoring, and the incorporation of these tools and techniques into prevailing VeriDevOps practices in the industry.
This includes identifying invalid states and contradictory security requirements in natural language requirement specifications and using this data to create negative tests. These tests aim to push the system into invalid states, i. e. potentially insecure behavior, thereby uncovering potential vulnerabilities that positive test cases may not detect. One enhancement Lastly, VeriDevOps automates design and code checks according to the specification of security requirements using semi-structured and structured formalisms. These verification activities can be conducted either by simulating the resulting model or by formally verifying a system description. VeriDevOps Methodology contains a set of comprehensive guidelines for the adopters of security verification methods and tools and can also serve as teaching material for IT-oriented universities.
VeriDevOps Architecture The VeriDevOps Methodology groups several interconnected tool sets for Security Requirements Generation, Reactive Protection at Runtime as well as for Prevention at Design and Development (as shown in Figure  2 ). Those tool sets are highly interconnected to achieve the goal of linking security requirements with design analysis, verification at the code level and the runtime analysis of systems. The VeriDevOps tool sets mix concrete tool components provided and developed by VeriDevOps partners. These concrete tools differ in licensing policies and maturity. While there are many mature commercial and open-source tools, others are more experimental. These tools should implement the interfaces and features of the VeriDevOps Methodology and should be interchangeable to a certain extent.
A Selection of Tools for the VeriDevOps Methodology 4. 1. 1 NALABS: Detecting Bad Smells in Security Requirements. Natural language is often used to express requirements and test specifications in large-scale embedded system development. However, in such contexts, requirement review is often done manually, which can be a time-consuming and error-prone process. Poor-quality specifications can have costly consequences on the requirement engineering process, particularly if feedback loops are lengthy, resulting in artifacts that are difficult to maintain, understand, and transfer to other system variants. To address this issue, NALABS  [14]  (NAtural LAnguage Bad Smells) tool utilizes the concept of "smells" to identify bad specifications related to safety and security requirements. By utilizing NALABS, DevOps engineers can improve the quality and maintainability of their natural language specifications, resulting in more efficient and effective requirement engineering processes.
ARQAN: Automated Security Requirements Analysis with NLP. ARQAN  1  is the security analysis tool based on the modern NLP methods such as Large Natural Language Models, Transfer Learning and BERT as exemplified in  [7]. The main tasks for ARQAN are to extract security requirements from texts in Natural Language, classify the requirements as well as semantic search for related recommendations in Security Technology Implementation Guidelines (STIG) database. RQCODE 2  is a novel approach that applies the Seamless Object-Oriented Requirements (SOOR) paradigm to be implemented in Java language. The RQ-CODE approach represents requirements as classes that contain various representations, including the textual one: requirements description in natural language as well as methods for verifying these requirements, such as an acceptance test.
This allows for direct traceability between a requirement and its implementation that can be checked at any time through the execution of the included test. Moreover, object-oriented implementation supports easy reuse of requirements and tests by the standard means, such as inheritance, provided by the language, e. g. , Java. One requirement can be an extension or a specialisation of another one. Each requirement can be considered as a template for requirements of a similar kind, e. g. by initialising a requirement class with different parameters. RQCODE includes specific packages for the baseline concepts and temporal patterns since they represent the foundation for writing requirements using well-known templates. For experimentation purposes, we prototyped examples for Windows 10 and Ubuntu 18 related Security Technology Implementation Guides (STIG)  [12].
Meta-Localizer. is an integrated tool-supported approach consisting of two modules. The first one, MetaTester  [17] , is used for testing systems with a non-explicit test oracle. Metamorphic testing (MT) was introduced as a solution to test systems without explicit specifications of the test oracle. In MT, the behavioral or functional properties of the system are defined by posing a hypothesis about using generic relations known as metamorphic relations (MRs) between different sets of inputs and their expected outputs. An MR is composed of two parts: an input relation and an output relation. An input relation represents the relation between the inputs of the source and follow-up test cases, whereas an output relation represents the relation between the expected outputs of the source and follow-up test cases.
A source test case is the first set of tests performed using seed inputs. The seed inputs are transformed into morphed inputs. The follow-up test cases are performed using these morphed inputs. In addition, an implication between the outputs of the source and follow-up test cases is needed to specify the impact of input transformations on their corresponding outputs. To that extent, the tool uses metamorphic relations (MRs) extracted from security requirements and uses them for assigning test verdicts. The second module, the Localizer, uses the passed and failed tests produced by the MetaTester and identifies the piece of code of the system under test that is more probable to be the source of the vulnerability. [4] : is a method developed for converting PLC (Programmable Logic Controller) programs into Python code.
Illustrative Examples In modern software development practices, requirements are specified in natural language. In DevOps practice, requirements are registered as feature request issues in an issue tracking system. The developer's team analyses the feature requests and schedules them in a backlog -a detailed list of tasks, often with an assignment to a concrete responsible developer. However, manual analysis of requirements may lead to misinterpretation or an assignment to the wrong person or team. The security requirements that come from standards such as IEC 62443, NIST SP 800-53 or even OWASP Application Security Verification Standard may be very generic. This leaves developers without clear guidelines for implementing and verifying security measures. This may lead to inadequate security protection implemented in the IT system.
The system has correctly classified this requirement as related to security and added the corresponding label. Next, a set of relevant Security Implementation Guides (STIGs) was automatically provided with the semantic search method. The recommendation provides practical instructions on testing the security requirement and fixing possible issues. The system also browses the repository of the implemented RQCODE requirements tests for the identified STIGS. It is possible to import the existing RQCODEs to the own repository or to create a feature request for the necessary but missing STIG. In addition, the same requirement for SSH brute force protection can be enforced by deploying and configuring MMT and EARLY for detecting anomalies when the SSH service is accessed, as will be discussed later.
NALABS focuses on utilizing bad smells to identify specification quality defects in industrial settings. NALABS interface (as shown in Figure  6 ) examines the quality of natural language specifications, the creation of smell metrics, and the automated measurement of these smells using specific dictionaries. Key aspects explored include vagueness, referenceability, optionality, subjectivity, weakness, readability, and complexity metrics. These metrics provide insights into issues such as understanding requirements, nesting and referencing in documents, use of optional words, presence of subjective language, the introduction of uncertainty, readability scores, and the size and complexity of requirements. We show in Figure  5  several security requirements. For example, two of the requirements include optionality smells (e.
g. , the use of the "can" and "may" words). The MetaTester tool is used to generate metamorphic tests and verify their conformance with the metamorphic relations. For example, for the security requirement extracted previously: "System should be protected from brute force attack on SSH", we can define a metamorphic relation, such as "Authenticating with wrong credentials should result in the same response. " In this case, tests are generated for different combinations of username and password. Instead of checking the output of each test, we check that all the outputs are equal. In case the latter condition does not hold, it means that a successful authentication has occurred. The MetaTester has also been applied to Load Position System (LPS) module in an industrial case study to test whether the markers of the load are properly identified in the presence of environmental (e.
During the monitoring process, whenever such an attack is detected, an alarm is automatically triggered to deploy countermeasures, e. g. , blocking of the remote host (as shown in Figure  7 ). We show the combination of two techniques, EARS and PyLC, for addressing the challenges of requirement formalization and automated test generation. The EARS approach focuses on formalizing natural language requirements using a semi-structured syntax. At the same time, PyLC is a framework that integrates Pynguin, a search-based testing tool for Python, to generate test cases for PLC programs automatically. Our results demonstrate the applicability of EARS in formalizing security requirements and developing test cases for PLC programs to find vulnerabilities. Furthermore, the generated test cases are executed using CODESYS Test Manager, ensuring consistency between the Python and original PLC environments.
Integrating Security Requirements Analysis and Verification into the Entire DevOps Process: • Use bad smells detectors (e. g. ,  [14] ), NLP and security requirements patterns (e. g. ,  [12] ) to specify and analyze security requirements in short feedback loops. Ensure that security requirements are specified clearly and unambiguously regardless of the formalism used e. g. , natural language, semi-structured patterns, models. • Use automated tools (e. g. , ARQAN, RQCODE) to validate the security models against security requirements. Using Automated Tools to Generate and Select Security Tests: • Integrate security testing into the DevOps pipeline. Several tools for active prevention, such as PyLC  [4] , which have applications ranging from security test generation to combinatorial security testing.
• Adopt different testing techniques, such as metamorphic testing, for systems without an explicit oracle. In our VeriDe-vOps approach, we proposed the use of MetaTester. [17]  Implementing security monitoring systems to detect and respond to security threats: • Monitor all critical components of the DevOps pipeline, including code repositories, build servers, and deployment environments. • Use automated tools (e. g. , EARLY  [2] ) to detect anomalies and security attacks. Regularly review and update the security monitoring system to ensure it remains effective.
CONCLUSIONS In conclusion, security verification, automated testing, and monitoring are essential methods in the DevOps process for ensuring the security and reliability of software applications. By incorporating these methods into VeriDevOps methodology, teams can detect and address security vulnerabilities at every stage, from planning and development to testing and deployment. Security verification enables teams to demonstrate the security of an application through automated verification. Automated testing allows for the quick and efficient detection of security vulnerabilities, saving time and resources. And monitoring enables teams to continuously track an application's behaviour and performance, ensuring that any potential security breaches are detected and addressed in real-time. By utilizing the VeriDevOps methodology, DevOps teams can not only enhance the security of their applications but also improve the overall quality and reliability of their software.
Dataset assembly A dataset of 1,217,174 protein coding genes from a sample of 63 animal species representing all major clades within the animal tree was obtained from the OMA orthology database  (70). Taxa were sampled to capture the known periods of major transition within animal evolution, and species representing all major nodes in the animal tree were included. The quality of data used was of particular importance in this study (given the potential for misidentification of composite genes) therefore taxon sampling was guided by the quality of gene annotation of the available species genomes using two filtering steps of genomes. First, we searched for protein coding genes known to be present across all of Metazoa (412 genes in total)  (71) , ranking genomes as high quality if they possessed >70% of the conserved set, while low quality genomes had less.
We also included an alternative topology for the root position on the animal tree to test if our results are robust to the position of the deepest divergences. Twelve of the species in our dataset were missing from the TimeTree database, and so to place their position and time of divergence, closely related species to these lineages were used as replacements. In most cases, sister species from the same genus were present, and a list of the closely related species used to replace them can be found in (Supplementary Table  S2 ). With other species, such as the case of Ciona savignyi, which was not present in TimeTree, the divergence time between it and its sister lineage Ciona intestinalis was taken as 176 MYA from the literature  (75).
Finding evidence for expression of unique joining-points of composite genes using publicly available transcriptome data We collated a dataset of all available transcriptomes from RNA sequencing studies for each taxon (52 out of 63 taxa had RNAseq data available). This allowed us to assess the putative composite genes at two levels: (i) their validity -making sure we do not report putative composite genes that are misassembly or misannotation artefacts, and (ii) whether they have evidence of expression. RNAseq reads were mapped to the unique joining-point region of the composite genes (i. e. the junction of component genes) using bowtie2  (76). RNAseq datasets were selected based on their robustness (as measured by the number of time points and tissues sampled) and the phylogenetic distribution of composites.
For example, for widely distributed composite families, representative taxa from across the lineages containing the composite family were chosen based on the robustness of their available RNAseq datasets. The representative taxa for each of the Bilaterian clades included humans (Deuterostomia) and fruit-fly (Protostomia). Coverage across the composite joiningpoint was assessed using BEDTools  (77). Evidence for transcription of the composite gene was determined by the coverage of at least one read across the joining-point.
Domain architecture analysis For all of our HG datasets (composite HGs, component HGs, and non-composite associated HGs) we first annotated protein domains from the Pfam database using domain-specific hidden markov models (31), using pfam_scan. pl and parsing using PfamScanner with an e-value threshold of 1e-3. We calculated the proportion of retention and loss during gene fusion for each domain by dividing every time it is present or lost in a composite gene by the number of times it is seen in all component genes (this analysis was carried out on just the domain type architecture of the proteins rather than the full protein architecture which may include repeat domains). No statistically significant correlation is observed between the number of times a domain type is seen in a CHG vs the proportion of time it is present or lost (Supplementary Figure  S1 ).
Similarly, when we annotate the domain by function or size, there does not seem to be a correlation between the presence of a domain and these traits. To assess whether there were any domains enriched in the set of composite genes which were annotated as emerging independently multiple times, we compared domain sets between single event CHGs and convergently formed CHGs. We obtained domain lists and correlating functions for both sets of CHGs and applied the find_enrichment. py script from Goatools (78) setting the full set of domains from all CHGs as the background.
Mapping composite gene gain and loss onto species tree For the taxa in our dataset, most of the branching patterns are well resolved allowing the analysis of the rate of emergence of CHGs on each branch across the tree to determine the patterns of gain and loss. We reconstructed the gain/loss history of the CHGs and used a constrained timetree (53) to determine their rates of gain and loss. The pattern of gains and losses of CHGs across the tree was assessed using one of two models; if CHGs were determined to have been formed in a single event, we used Claddis  (46)  an R package which operates in a maximum likelihood framework to describe characteristics of binary data. Specifically we used the map_dollo_changes. R function, which was developed to generate a stochastic character map for Dollo characters, allowing for a single gain event followed by any number of losses  (47).
Functional annotation of composite genes All proteins used in our starting dataset were functionally annotated using eggNOGmapper (86) v2. 1. 6, employing DIAMOND v2. 0. 11 to align sequences to the eggNOG database v5. 0. 2. Cluster of Orthologous Groups (COG) functional categories were extracted for each sequence, and where required these were used to annotate the representative set of functions per CHG. To first test whether there were differences between the functional groups represented in fusion genes versus genes never associated with CHGs, we compared each COG category for each gene annotated as fusion or annotated as neither fusion or fission, and plotted the relative proportions (i. e. the number of COG categories divided by the number of genes) for each category. Next, to compare proportion of functional categories which emerged on each node of the tree, including major animal nodes, we took the proportions of categories from each CHG, and inferred the overall contribution at each node by dividing all the categories by the number of CHGs gained on the given node.
We mapped the unique "joining-point" in each composite gene to available transcriptome datasets (the "joining-point" is the location within the composite sequence where the contributing component sequences meet). Transcriptome data was available for 52 of the 63 species and 12,048 of the 13,632 CHGs (see Materials and Methods). A total of 7,774 CHGs (65%) had evidence of expression for at least one composite gene member of a given CHG family. The proportion with evidence of expression (i. e. 65%) is what we might expect from large scale RNAseq studies on temporal and spatial variation in expression in animal protein coding genes  (30). The 13,632 CHGs were related to a total of 40,217 component HGs, with the majority of CHGs (i. e. 10,855 (80%)) having just 2 component genes (or parts thereof).
e. those genes that are not composite and not component) (p < 2. 2e-16). Additionally, composite genes tend to have longer protein coding sequences than either component genes (p < 2. 2e-16) or non-composite associated genes (p < 2. 2e-16). On average component genes contribute 100 amino acids during composite formation -corresponding closely to the average length of a domain in all component genes in our dataset (i. e. 118 amino acids). The most common proportion of component gene sequence to be present following a fusion event is 20% or 100%, suggesting that the domain unit places the strongest constraint on the size and architecture of composite genes (Figure  1c ). Comparing domain types between component and composite genes, we find that no domain is significantly over-represented across all CHGs and thus present at a higher rate than others during composite formation  (27).