Software engineering for security: a roadmap

By Premkumar T. Devanbu, Stuart G. Stubblebine. International Conference on Software Engineering, 2000

511 citations recorded by the source corpus.

Is there such a thing anymore as a software system that doesn’t need to be secure? Almost every softwarecontrolled system faces threats from potential adversaries, from Internet-aware client applications running on PCs, to complex telecommunications and power systems accessible over the Internet, to commodity software with copy protection mechanisms. Software engineers must be cognizant of these threats and engineer systems with credible defenses, while still delivering value to customers. In this paper, we present our perspectives on the research issues that arise in the interactions between software engineering and security.

Subfields: Artificial Intelligence, Information Systems, Signal Processing

View Paper: https://www.semanticscholar.org/paper/37b7f67b3a71d144ea1f0295a8899f75146255a5

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Artificial Intelligence

In Information Systems

In Signal Processing

Citations in the corpus

UMLsec: Extending UML for Secure Systems Development (2002, methodology): “To support using UML for secure systems development, we give an extension, UMLsec, of the UML, following a suggestion in [DS00].”
Recovering clear, natural identifiers from obfuscated JS names (2017, background): “Code obfuscation is a general topic, spanning a wide range of goals: in addition to intellectual property protection [15], applications include inter alia, tamper-resistance [4, 44], and water-marking [12].”
Eliciting security requirements with misuse cases (2000, methodology): “This is a potential problem in security engineering, where formal methods are recommended [33].”
Security Requirements Engineering: A Framework for Representation and Analysis (2008, background): “Security requirements have traditionally been considered to be “nonfunctional” or “quality” requirements ([15], [23], [27], [30], and many others).”
Secure Tropos: a Security-Oriented Extension of the Tropos Methodology (2007, background): “This argument is also supported in the literature [12, 26, 41].”
Testing: a roadmap (2000, result): “Other reports in this volume (e.g., [ 12 , 17, 25, 30, 31]) provide additional information about verification.”