@article{oyetoyan_morrison_2021, title={An improved text classification modelling approach to identify security messages in heterogeneous projects}, ISSN={["1573-1367"]}, DOI={10.1007/s11219-020-09546-7}, abstractNote={Abstract}, journal={SOFTWARE QUALITY JOURNAL}, author={Oyetoyan, Tosin Daniel and Morrison, Patrick}, year={2021}, month={May} }
 @article{morrison_pandita_xiao_chillarege_williams_2018, title={Are Vulnerabilities Discovered and Resolved like Other Defects?}, DOI={10.1145/3180155.3182553}, abstractNote={Context: Software defect data has long been used to drive software development process improvement. If security defects (i.e.,vulnerabilities) are discovered and resolved by different software development practices than non-security defects, the knowledge of that distinction could be applied to drive process improvement.}, journal={PROCEEDINGS 2018 IEEE/ACM 40TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE)}, author={Morrison, Patrick J. and Pandita, Rahul and Xiao, Xusheng and Chillarege, Ram and Williams, Laurie}, year={2018}, pages={498–498} }
 @article{morrison_oyetoyan_williams_2018, title={Identifying Security Issues in Software Development: Are Keywords Enough?}, ISSN={["2574-1926"]}, DOI={10.1145/3183440.3195040}, abstractNote={Identifying security issues before attackers do has become a critical concern for software development teams and software users. One approach to identifying security issues in software development artifacts is to use lists of security-related keywords to build classifiers for detecting security issues. However, generic keyword lists may miss project-specific vocabulary. The goal of this research is to support researchers and practitioners in identifying security issues in software development project artifacts by defining and evaluating a systematic scheme for identifying project-specific security vocabularies that can be used for keyword-based classification. We sampled and manually classified 5400 messages from the Apache Derby, Apache Camel, and Dolibarr projects to form an oracle. In addition, we collected each project's publicly disclosed vulnerability data from the CVE and mapped them to the project's dataset to create a CVE-labelled data. We extracted project-specific vocabulary from each project and built classifiers to predict security-related issues in both the oracle and CVE dataset. In our data, we found that the vocabularies of each project included project-specific terms in addition to generic security keywords. Classifiers based on the project-specific security vocabularies increased recall performance by at least double (at varying costs to precision) compared with the previous published keyword lists we evaluated.}, journal={PROCEEDINGS 2018 IEEE/ACM 40TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING - COMPANION (ICSE-COMPANION}, author={Morrison, Patrick and Oyetoyan, Tosin Daniel and Williams, Laurie}, year={2018}, pages={426–427} }
 @article{morrison_moye_pandita_williams_2018, title={Mapping the field of software life cycle security metrics}, volume={102}, ISSN={["1873-6025"]}, DOI={10.1016/j.infsof.2018.05.011}, abstractNote={Context: Practitioners establish a piece of software’s security objectives during the software development process. To support control and assessment, practitioners and researchers seek to measure security risks and mitigations during software development projects. Metrics provide one means for assessing whether software security objectives have been achieved. A catalog of security metrics for the software development life cycle could assist practitioners in choosing appropriate metrics, and researchers in identifying opportunities for refinement of security measurement. Objective: The goal of this research is to support practitioner and researcher use of security measurement in the software life cycle by cataloging security metrics presented in the literature, their validation, and the subjects they measure. Method: We conducted a systematic mapping study, beginning with 4818 papers and narrowing down to 71 papers reporting on 324 unique security metrics. For each metric, we identified the subject being measured, how the metric has been validated, and how the metric is used. We categorized the metrics, and give examples of metrics for each category. Results: In our data, 85% of security metrics have been proposed and evaluated solely by their authors, leaving room for replication and confirmation through field studies. Approximately 60% of the metrics have been empirically evaluated, by their authors or by others. The available metrics are weighted heavily toward the implementation and operations phases, with relatively few metrics for requirements, design, and testing phases of software development. Some artifacts and processes remain unmeasured. Measured by phase, Testing received the least attention, with 1.5% of the metrics. Conclusions: At present, the primary application of security metrics to the software development life cycle in the literature is to study the relationship between properties of source code and reported vulnerabilities. The most-cited and most used metric, vulnerability count, has multiple definitions and operationalizations. We suggest that researchers must check vulnerability count definitions when making comparisons between papers. In addition to refining vulnerability measurement, we see research opportunities for greater attention to metrics for the requirement, design, and testing phases of development. We conjecture from our data that the field of software life cycle security metrics has yet to converge on an accepted set of metrics.}, journal={INFORMATION AND SOFTWARE TECHNOLOGY}, author={Morrison, Patrick and Moye, David and Pandita, Rahul and Williams, Laurie}, year={2018}, month={Oct}, pages={146–159} }
 @article{rahman_partho_morrison_williams_2018, title={What Questions Do Programmers Ask About Configuration as Code?}, DOI={10.1145/3194760.3194769}, abstractNote={Configuration as code (CaC) tools, such as Ansible and Puppet, help software teams to implement continuous deployment and deploy software changes rapidly. CaC tools are growing in popularity, yet what challenges programmers encounter about CaC tools, have not been characterized. A systematic investigation on what questions are asked by programmers, can help us identify potential technical challenges about CaC, and can aid in successful use of CaC tools. The goal of this paper is to help current and potential configuration as code (CaC) adoptees in identifying the challenges related to CaC through an analysis of questions asked by programmers on a major question and answer website. We extract 2,758 Puppet-related questions asked by programmers from January 2010 to December 2016, posted on Stack Overflow. We apply qualitative analysis to identify the questions programmers ask about Puppet. We also investigate the trends in questions with unsatisfactory answers, and changes in question categories over time. From our empirical study, we synthesize 16 major categories of questions. The three most common question categories are: (i) syntax errors, (ii) provisioning instances; and (iii) assessing Puppet's feasibility to accomplish certain tasks. Three categories of questions that yield the most unsatisfactory answers are (i) installation, (ii) security, and (iii) data separation.}, journal={PROCEEDINGS 2018 IEEE/ACM 4TH INTERNATIONAL WORKSHOP ON RAPID CONTINUOUS SOFTWARE ENGINEERING (RCOSE)}, author={Rahman, Akond and Partho, Asif and Morrison, Patrick and Williams, Laurie}, year={2018}, pages={16–22} }
 @inproceedings{morrison_pandita_murphy-hill_mclaughlin_2016, title={Veteran developers' contributions and motivations: an open source perspective}, DOI={10.1109/vlhcc.2016.7739681}, abstractNote={Decades of psychology and sociology research demonstrate that humans change cognitively and socially as they age, so it stands to reason that software developers likewise undergo changes that may affect their work. In this paper, we investigate age-related differences in software developers through the lens of open source software, which is built in communities that tend not to include older software developers. We report on the results of a qualitative panel discussion, then quantitatively analyze such veteran developers' activities on StackOverflow, to understand why few veteran software developers' participate in open source, and how their contributions to software development differ from their younger peers. Our results suggest that veterans' are less motivated by social interactions than their younger peers. Our results also suggest that veterans could contribute a broader knowledge of software development than their younger peers, as well as knowledge of old technologies that can be applied to newer technologies.}, booktitle={2016 ieee symposium on visual languages and human-centric computing (vl/hcc)}, author={Morrison, P. and Pandita, R. and Murphy-Hill, E. and McLaughlin, A.}, year={2016}, pages={171–179} }
 @article{morrison_2015, title={A Security Practices Evaluation Framework}, DOI={10.1109/icse.2015.296}, abstractNote={Software development teams need guidance on choosing security practices so they can develop code securely. The academic and practitioner literature on software development security practices is large, and expanding. However, published empirical evidence for security practice use in software development is limited and fragmented, making choosing appropriate practices difficult. Measurement frameworks offer a tool for collecting and comparing software engineering data. The goal of this work is to aid software practitioners in evaluating security practice use in the development process by defining and validating a measurement framework for software development security practice use and outcomes. We define the Security Practices Evaluation Framework (SP-EF), a measurement framework for software development security practices. SP-EF supports evidence-based practice selection. To enable comparison of practices across publications and projects, we define an ontology of software development security practices. We evaluate the framework and ontology on historical data and industrial projects.}, journal={2015 IEEE/ACM 37TH IEEE INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, VOL 2}, author={Morrison, Patrick}, year={2015}, pages={935–938} }
 @article{morrison_holmgreen_massey_williams_2013, title={Proposing Regulatory-Driven Automated Test Suites}, DOI={10.1109/agile.2013.8}, abstractNote={In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, the same regulations apply for all systems. As a result, efficiencies could be gained if the commonalities between systems could be captured in public, shared, test suites for regulations. We propose the use of Behavior-Driven-Development (BDD) technology to create these test suites. With BDD, desired system behavior with respect to regulatory requirements can be captured as constrained natural language 'scenarios'. The scenarios can then be automated through system-specific test drivers. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our approach, we developed seven scenarios based on the HITECH Act Meaningful Use (MU) regulations for healthcare. We then created system-specific code for three open-source electronic health record systems. We found that it was possible to create scenarios and system-specific code supporting scenario execution on three systems, that iTrust can be shown to be noncompliant, and that emergency access procedures are not defined clearly enough by the regulation to determine compliance or non-compliance.}, journal={2013 AGILE CONFERENCE (AGILE)}, author={Morrison, Patrick and Holmgreen, Casper and Massey, Aaron and Williams, Laurie}, year={2013}, pages={11–21} }
 @inproceedings{morrison_holmgreen_massey_williams_2013, title={Proposing regulatory-driven automated test suites for electronic health record systems}, DOI={10.1109/sehc.2013.6602477}, abstractNote={In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, regulations apply across organizations. We propose the use of Behavior-Driven-Development (BDD) scenarios as the basis of an automated compliance test suite for standards such as regulation and interoperability. Such test suites could become a shared asset for use by all systems subject to these regulations and standards. Each system, then, need only create their own system-specific test driver code to automate their compliance checks. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our proposal, we developed an abbreviated HIPAA test suite and applied it to three open-source electronic health record systems. The scenarios covered all security behavior defined by the selected regulation. The system-specific test driver code covered all security behavior defined in the scenarios, and identified where the tested system lacked such behavior.}, booktitle={2013 5th international workshop on software engineering in health care (sehc)}, author={Morrison, P. and Holmgreen, C. and Massey, A. and Williams, L.}, year={2013}, pages={46–49} }