Maureen Doyle

Security of open source web applications

In an empirical study of fourteen widely used open source PHP web applications, we found that the vulnerability density of the aggregate code base decreased from 8.88 vulnerabilities/KLOC to 3.30 from Summer 2006 to Summer 2008. Individual web applications varied widely, with vulnerability densities ranging from 0 to 121.4 at the beginning of the study. While the total number of security problems decreased, vulnerability density increased in eight of the fourteen applications over the analysis period. We developed a security resources indicator metric, which we found to be strongly correlated (ρ =0.67,p < 0.05) with change in vulnerability density over time. Traditional software metrics, such as code size, cyclomatic complexity, nesting complexity, and churn, had significant (p < 0.05) but much smaller correlations (ρ = 0.31 at best) with vulnerability density. Vulnerability density was measured using the Fortify Source Code Analyzer static analysis tool.

SAVI: Static-Analysis Vulnerability Indicator

Open source software presents new opportunities for software acquisition but introduces risks. The selection of open source applications should take into account both features and security risks. Risks include security vulnerabilities, of which published vulnerabilities are only the tip of the iceberg. Having an applications source code lets us look deeper at its security. SAVI (Static-Analysis Vulnerability Indicator) is a metric for assessing risks of using software built by external developers. It combines several types of static-analysis data to rank application vulnerability.

Idea: java vs. PHP: security implications of language choice for web applications

While Java and PHP are two of the most popular languages for open source web applications found at freshmeat.net, Java has had a much better security reputation than PHP. In this paper, we examine whether that reputation is deserved. We studied whether the variation in vulnerability density is greater between languages or between different applications written in a single language by comparing eleven open source web applications written in Java with fourteen such applications written in PHP. To compare the languages, we created a Common Vulnerability Metric (CVM), which is the count of four vulnerability types common to both languages. Common Vulnerability Density (CVD) is CVM normalized by code size. We measured CVD for two revisions of each project, one from 2006 and the other from 2008. CVD values were higher for the aggregate PHP code base than the Java code base, but PHP had a better rate of improvement, with a decline from 6.25 to 2.36 vulnerabilities/KLOC compared to 1.15 to 0.63 in Java. These changes arose from an increase in code size in both languages and a decrease in vulnerabilities in PHP. The variation between projects was greater than the variation between languages, ranging from 0.52 to 14.39 for Java and 0.03 to 121.36 in PHP for 2006. We used security and software metrics to examine the sources of difference between projects.

Agile software development in practice

Agile software development methods have been around since the mid 1990s. Over these years, teams have evolved the specific software development practices used. Aims: The goal of this paper is to provide a view of the agile practices used by new teams, and the relationship between the practices used, project outcomes, and the agile principles. Method: This paper provides a summary and analysis of 2,229 Comparative Agility™ (CA) assessment surveys completed between March 2011 and October 2012 by agile developers who knew about the survey. The CA tool assesses a teams agility and project outcomes using a 65-statement Likert survey. Results: The agile principle of respect for individuals occurs the most frequently, while simplicity occurs least. Progress/Planning is correlated strongly to nine principles. Conclusion: Subject to sampling issues, successful teams report more positive results for agile practices with the most important practice being teams knowing their velocity.

Retention of STEM majors using early undergraduate researchexperiences

An early undergraduate research program for rising sophomores and juniors at risk of leaving STEM degree programs is described. Students are paid a stipend to work part-time, at a maximum of twenty hours per week, as part of a research team. Faculty researchers are not financially compensated for working with students. The program successfully brings together STEM departments to target students who are at risk of leaving their major. Initial results demonstrate a positive influence of undergraduate research in retaining STEM majors and improvements in Student Assessment of Learning Gains. Future work, including institutionalization of the project, is discussed.

An informatics perspective on computational thinking

In this paper, we examine computational thinking and its connections to critical thinking from the perspective of in- formatics. We developed an introductory course for students in our College of Informatics, which includes majors rang- ing from journalism to computer science. The course cov- ered a set of principles of informatics, using both lectures and active learning sessions designed to develop informat- ics and computational thinking skills. The set of principles was drawn from a wide set of sources, and included broad principles like those of Denning and Loidl, as well as more limited principles related to topics like universal computa- tion and undecidability. We evaluated the change in both computational and critical thinking skills over the course of the semester, using a well-known validated critical thinking test and a computational thinking test of our own devising.

Impact of plugins on the security of web applications

Many web applications have evolved into complex software ecosystems, consisting of a core maintained by a set of long term developers and a range of plugins developed by third parties. The security of such applications depends as much on vulnerabilities found in plugins as it does in vulnerabilities in the application core. In this paper, we present a study of vulnerabilities in twelve open source web applications and 13,778 plugins for those applications. We used automated static analysis tools to count vulnerabilities. Plugins made up 93% of the aggregate code base of 10.2 MLOC and contained 92% of the 125,110 vulnerabilities found. Comparing the aggregate plugin source code of each project with its code, we found that four projects had more secure core code than plugin code, as measured by vulnerability density (vulnerabilities per thousand lines of code), while eight projects had plugin code that was more secure than core code. Vulnerability density was significantly correlated with code size for both core code and plugins. We also analyzed the density of individual vulnerability categories, finding plugins to have many more cross-site vulnerabilities and fewer injection vulnerabilities than core code.

Trace Matrix Analyzer (TMA)

A Trace Matrix (TM) represents the relationship between software engineering artifacts and is foundational for many software assurance techniques such as criticality analysis. In a large project, a TM might represent the relationships between thousands of elements of dozens of artifacts (for example, between design elements and code elements, between requirements and test cases). In mission- and safety-critical systems, a third party agent may be given the job to assess a TM prepared by the developer. Due to the size and complexity of the task, automated techniques are needed. We have developed a technique for analyzing a TM, called Trace Matrix Analyzer (TMA), so that third party agents can perform their work faster and more effectively. To validate, we applied TMA to two TMs with known problems and golden answersets: MoonLander and MODIS. We also asked an experienced software engineer to manually review the TM. We found that TMA properly identified TM issues and was much faster than manual review, but also falsely identified issues for one dataset. This work addresses the Trusted Grand Challenge, research projects 3, 5, and 6.

Computer Science and Computer Information Technology majors together: Analyzing factors impacting students' success in introductory programming

In 2004 Northern Kentucky University began offering a Bachelor of Science degree in Computer Information Technology. As these new majors began to enroll alongside Computer Science majors in the required and standard Computer Science 1 (CS 1) course, the context of CS 1 shifted. Accordingly, we made curriculum changes to adapt the introductory programming sequence to this new context. These changes included: creating a “CS 0.5” preparatory programming course taught in a variety of languages; allowing the scheduled laboratory component of CS 1 to be optional; and lowering the mathematics prerequisite for CS 1 from Pre-Calculus to College Algebra. We have studied the impact of these changes on student success. Because many Computer Science Departments in the U.S. began offering Information Technology degrees since 2000, in part to offset the downturn in CS enrollment, our results may be of broader interest. We found that gender, major, the programming language used in CS 0.5 and student attitudes toward technology (as revealed by surveys) did not affect student success in CS 1. Factors that were positively correlated with CS 1 success included mathematics ACT score, completing CS 0.5, and enrolling in the optional CS 1 laboratory section.

SIGCSE symposium history

The first SIGCSE Technical Symposium was held 45 years ago on November 16, 1970 at the Astrodome in Houston, Texas. SIGCSE 1970 co-chairs were Dr. Peter Calingaert, at the time teaching for the University of North Carolina at Chapel Hill, and Dr. Edward A. Feustel from Rice University. Peter was responsible for the technical content, and Dr. Robert M. Aiken, from the University of Tennessee, served as Editor of the Proceedings. Over 40 papers were submitted; 18 were accepted.