2009 International Conference on Computational Science and Engineering
Activity and Artifact Views of a Secure Software Development Process
Muhammad Umair Ahmed Khan and Mohammad Zulkernine
School of Computing, Queen’s University, Kingston, Ontario, Canada, K7L3N6
{umair, mzulker}@cs.queensu.ca
Abstract
The number of security errors and vulnerabilities
can be reduced if a secure software development
process (SSDP) is followed. Such a SSDP must cater
for security aspects during each phase of development.
In this paper, we present a new process that provides
ways of addressing security concerns and
incorporating security decisions throughout the
software development process. Our process has two
views: activity and artifact. The activity view presents
development activities performed during requirements
engineering, design, implementation, and assurance
phases. The artifact view, on the other hand, identifies
the relationships among the various SSDP artifacts
that are produced during development.
1. Introduction
Within current software security practice, during the
final stages of development (assurance or testing),
various techniques (e.g., penetration testing) are used
to reveal any security vulnerabilities that the software
might have. The identified security vulnerabilities are
removed by revisiting and correcting requirements,
design, and code. If the software is already released or
deployed, a patch is developed [1]. Moreover, security
requirements are usually kept separate and are not
interweaved with the functional requirements and
design. This leads to inconsistencies and ambiguities.
Given that, it is essential that the software is developed
in a secure fashion from the beginning. Hence, it is
required to have a repeatable secure software
development process (SSDP) which addresses security
aspects during each phase of software development.
Most of the SSDPs proposed in the literature do not
include adequate secure software development
activities. Therefore, in this paper, we propose a new
SSDP that includes necessary secure software
development activities that are essential to achieve
more secure software. Existing SSDPs focus on the
development activities that need to be performed and
978-0-7695-3823-5/09 $26.00 © 2009 IEEE
DOI 10.1109/CSE.2009.383
their sequence of execution (referred to here as activity
view). However, an activity view may not capture
many important aspects of the process, e.g., activities
may not be directly dependent on other activities for
their execution. In fact, activities depend on artifacts
that are produced or modified by other activities.
Moreover, some artifacts depend on other artifacts. To
represent these dependencies, we introduce the concept
of an artifact view. An artifact view of a SSDP
elaborates on the artifact-artifact and activity-artifact
relationships.
Our SSDP has both the activity and artifact views
and covers the requirements engineering, design,
implementation, and assurance phases. Each of the
phases in our SSDP has a set of development activities
that ought to be performed in the specified sequence
(activity view). The artifact-artifact and artifact-
activity relationships of the artifacts resulting from
these activities are presented in the artifact view. Our
proposed SSDP provides guidance in finding errors
that may lead to security vulnerabilities and helps to
identify security requirements to remove these errors.
The rest of this paper is organized as follows.
Section 2 defines some of the terms related to software
security. Section 3 provides the related work. Section 4
elaborates the activity view, while Section 5 presents
the artifact view of our proposed SSDP. Section 6
concludes this paper by summarizing the work.
2. Preliminaries
Many terms used in software security are also
employed in other fields of software engineering with
varying meanings. Here, we explain some of these
terms used in this paper.
Software security error: The term error has been
very rarely used in software security literature. Most of
the authors use the term vulnerability and do not
distinguish between vulnerability and error. Sometimes
the term flaw is also used instead of error [2]. A
software security error is a tangible manifestation of a
mistake in any of the software development life cycle
(SDLC) artifacts (requirement specifications, design,
399
or source code) of a piece of software that leads to a
vulnerability [2-4]. A software security error can be
one of the following if it is related to security threats:
(1) a requirement specification error (an incorrect or
missing requirement in the requirement specifications
due to a mistake made in the requirement engineering
phase of the SDLC), (2) a design error (an incorrect
logical decision, the decision itself or the
representation of a decision, in the design due to a
mistake made in the design phase of the SDLC), or (3)
a source code error (an incorrect representation of the
design decisions in the source code due to a mistake
made in the implementation phase of the SDLC).
Software error: A software error is a superset of
software security error. The only difference is that
while a software security error leads to a vulnerability,
a software error results in undesired functional
behavior which may not be related to security.
Software security vulnerability: A software
security vulnerability is the result of a software
security error [3].
Software security requirement: A software
security requirement [4], sometimes also referred to as
a countermeasure or safeguard [5-7], can be defined as
a requirement needed to avoid a specific software
security error during development. A software security
requirement can be specified for any SSDP artifact [4].
Consequently, a security requirement can be a
requirement specified during the requirements phase or
a design decision made during the design phase. For
the implementation phase, the security requirements
would be the secure coding standards and guidelines.
3. Related work
The seven touch points identified in McGraw’s
software development lifecycle process [8] are
different from our process in that they do not include
threat modeling in any phase. Moreover, security
requirements (and mechanisms) are not incorporated
from the beginning and are specified based on the
results of the assurance phase. McGraw also does not
specify the use of security specification languages,
secure design patterns, or secure coding standards.
McGraw’s touch points are similar to our process with
respect to the assurance phase (both advocate
performing static analysis and penetration testing). Our
process has specification-based security testing as
compared to risk-based security testing in McGraw’s
touch points. Moreover, we both propose performing
risk analysis multiple times.
Trustworthy Computing Security Development
Life Cycle or Microsoft Software Development Life
Cycle (MS SDL) [9] does not perform formal threat
400
modeling during the requirements engineering phase.
Risk analysis is performed on informally identified
risks/threats. MS SDL also does not suggest the use of
security specification languages to represent security
requirements and secure design decisions. Moreover,
for the requirements engineering and design phases,
MS SDL does not endeavor to identify security errors
and specify security requirements to remove these
errors. MS SDL is similar to our process in many
aspects such as performing risk analysis multiple
times, modeling threats during design, specifying
security mechanisms during the requirements
engineering phase, following secure design guidelines
and secure coding standards, and performing multiple
assurance activities.
Comprehensive, Lightweight Application Security
Process (CLASP) [10] is different from our process as
it does not perform any activity to identify software
security errors during requirements engineering and
design phases. Consequently, it does not specify
security requirements to remove such errors. CLASP
also does not suggest using security specification
languages to represent security requirements and
secure design decisions. CLASP proposes annotating
only the class diagram with security information. It is
similar to our SSDP in the following ways. It
advocates performing risk analysis and threat modeling
during both requirements engineering and design
phases. CLASP also specifies security mechanisms
early in the requirements engineering phase. It suggests
that secure design guidelines and secure coding
standards be followed. In the assurance phase, CLASP
proposes to perform inspections, static code analysis,
and security testing. CLASP is the only existing
process that has multiple views. The activity-
assessment and activity-implementation views, when
combined, are similar to the activity view suggested in
this paper (and other SSDPs). While the rest of the
CLASP views are important, none of them is
comparable to the artifact view presented here as part
of our SSDP.
The major distinction between Appropriate and
Effective Guidance for Information Security (AEGIS)
[11] and our process is that AEGIS only focuses on the
requirements and design phases and does not specify
any secure development activity for the other phases.
Moreover, it does not propose the use of security
specification languages and secure design guidelines.
Similar to our process, AEGIS suggests identifying
security vulnerabilities (not errors) and threats. How
threats should be identified is not mentioned. Risk
analysis is carried out multiple times and security
requirements to remove the identified vulnerabilities
are also specified.
Phase
R1.Specification of functional requirements
Requirements
Engineering R9.Security assessment of the requirements specifications
If the security index If the security index is less than the threshold
is greater than or
equal to the threshold R10.Specification of low-level security requirements
R11.Prioritization and inclusion of low-level security requirements
D1.Specification of the functional design
Design
D8.Security assessment of the design
If the security index If the security index is less than the threshold
is greater than or
equal to the threshold
D9.Specification of low-level security requirements
D10.Prioritization and inclusion of low-level security requirements
Implementation I1.Selecting a secure programming language
I2.Following secure coding standards and guidelines
I3.Unit testing
Assurance A1.Code inspections and static analysis
A2.Generating test cases
A3.Integration, acceptance, and penetration testing
Figure 1. Activity view of the SSDP
Secure Software Development Model (SSDM) [12]
focuses mainly on the requirements engineering phase.
It does not propose any design or implementation
phase activity. The only activity for assurance is
penetration testing. SSDM is similar to our process
only with respect to modeling during the requirements
engineering phase.
Secure Software Development Process Model
(S2D-ProM) [13] is a strategy-based SSDP. For
advancing from one development phase to the next,
S2D-ProM proposes multiple alternate strategies.
These strategies are very high-level, e.g., use of
personal experience.
None of the existing SSDPs presents an artifact
view. A comparative study of many existing SSDPs is
presented in [14].
4. Activity view of the SSDP
The SSDP addresses requirements engineering,
design, implementation, and assurance phases. This
process can be used as a sequential (waterfall) or an
iterative (spiral) process for development. Moreover, it
contains both functional and secure software
development activities (e.g., specification of use cases
vs. specification of abuse cases). The activity view
presents the development activities for each of the
phases and the sequences in which they should be
performed (Fig. 1). In the following subsections, we
elaborate on these activities.
401
R2.Conducting inspections to identify software errors
If required
R3.Conducting threat modeling
R4.Risk analysis on threats
R5.Specification of high-level security requirements
R6.Selection and specification of security mechanims
R7.Propritization of security requirements
R8.Conducting inspections from a security perspective
D2.Conducting inspections to identify software errors
If required
D3.Enhancing the threat model
D4.Risk analysis on threats
D5.Design decisions to mitigate threats
D6.Propritization of design decisions
D7.Conducting inspections from a security perspective
4.1. Requirements engineering phase
It has been estimated that an error introduced in the
requirements engineering phase, if not removed
immediately, can cost up to 200 times more to correct
in later stages of development [15]. It can be assumed
that correcting a software security error will be equally
expensive. Hence, this phase must receive special
attention and have the following activities to derive
complete functional and security requirements.
R1. The behavior and deployment environment of
the software should be specified using use cases along
with detailed functional requirements (diagrams/text).
R2. The requirements specifications ought to be
inspected (multiple times, if required) for identifying
and removing software errors.
R3. Abuse cases should be specified. Information
about software assets, attackers, attackers’ interests,
attackers’ resources, attack surfaces, and threats to
existing software of the same domain must be
collected. A threat model can be developed in light of
the aforementioned information.
R4. Risk analysis should be performed on the
identified threats to calculate the collective potential
damage that each of them can cause to different assets
[4]. This information can be used to prioritize threats.
R5. High-level security requirements such as
preservation of confidentiality, integrity, and
availability should be specified to mitigate identified
threats. Specification languages that can represent
security requirements (e.g., UMLsec [1]) may be used
to specify these security requirements.
R6. It may be possible that more than one security
mechanisms is able to fulfill a security requirement.
Moreover, different security mechanisms can offer
varying levels of assurances. The implementation and
social cost (e.g., usability) of a security mechanism
might also be different. An appropriate security
mechanism should be selected by considering the
above mentioned issues. Detailed functional
requirements (e.g., strength of the password) must also
be specified. The selection procedure should involve
all stakeholders.
R7. High-level security requirements can be
prioritized by performing a cost benefit analysis.
Security mechanism with higher priority should be
implemented first if there are budgetary constraints.
R8. Software security errors and already specified
low-level security requirements may be identified
through inspections. Security errors or vulnerabilities
reported in existing similar software can be used as a
checklist for inspections.
R9. A threshold of acceptable security can be
defined by using, e.g., security index [4] which
provides a measure of the current security state of an
SDLC artifact. Security index of the requirements
specification should be within the threshold. If a weak
security mechanism is selected to mitigate a threat,
then its weakness may be treated as a vulnerability
while calculating the security index.
R10. If the calculated security index is less than the
threshold, then security requirements to remove the
identified errors should be specified.
R11. The newly specified security requirements can
be prioritized based on cost benefit analysis. High
priority security requirements should be included.
4.2. Design phase
Design is the representation of decisions taken to
fulfill requirements. Design specifies two aspects of
the software: static structure and dynamic behavior.
The design phase in the SSDP has the following steps.
D1. Detailed functional design (including design
of security mechanisms) should be specified in a
secure manner by following secure design patterns and
secure design guidelines. A secure design language
such as UMLsec may be used.
D2. The design must be inspected (multiple times,
if required) for identifying/nd removing software
errors.
D3. The threat model developed during the
requirements engineering phase should be enhanced.
402
D4. Risk analysis should be performed on the
identified threats to calculate the potential damage that
each of the threats can cause.
D5. Security requirements (secure design
decisions) must be identified for threats that violate
any of the high-level security requirements. There
could be multiple design decisions to mitigate any
threat (similar to Step R5). Moreover, further security
mechanisms could also be incorporated.
D6. Secure design decisions to remove threats can
be prioritized based on a cost/benefit analysis.
D7. Software security errors and previously
specified secure design decisions should be identified
through inspections. Security errors or vulnerabilities
reported in the existing similar software can be used as
a checklist.
D8. A threshold of acceptable security needs to be
defined using, e.g., security index [4]. Security index
of the design must be within the threshold.
D9. If the calculated security index is less than the
threshold, then secure design decisions to remove the
errors should be specified.
D10. The newly specified secure design decisions
can be prioritized based on cost benefit analysis. High
priority design decisions should be included.
4.3. Implementation phase
Design is translated into code during
implementation. Following are the activities that need
to be performed during implementation to achieve
secure code.
I1. Higher-level programming languages offer
fewer prospects of insecure code being written.
However, sometimes it is necessary to use a low-level
language to gain direct access to the hardware level. A
language must be selected that is as high-level as
possible while keeping in view the programming
requirements of the software under development.
I2. Secure coding standards and guidelines
should be followed to avoid source code errors.
I3. Unit testing needs to be performed with
security concerns in mind. Security errors reported in
similar software should be used as a reference.
4.4. Assurance phase
During the assurance phase, the software is checked
to find if it meets the requirements. Following activities
should be performed during this phase.
A1. Code must be inspected (based on the
checklists of the previously reported errors) to identify
software and security errors. Moreover, static analysis
tools should be used to find errors. The discovered err-
Requirements Engineering Table 1. Artifact view of SSDP: activity-artifact
Information about assets and attackers relationship
Activities Input Artifacts Output Artifact
R1 None Functional requirements.
Threat model R2 Functional requirements. Functional requirements.
Functional requirements
R3 Information about assets and attackers. Threat model.
R4 Threat model. Threat model.
High-level security requirements
R5 Threat model. High-level security
requirements.
Security mechanisms to be included R6 High-level security requirements. Security mechanisms to
be included. Functional
requirements with
Functional requirements with specifications of security
specifications of security mechanisms Security errors mechanisms.
R7 High-level security requirements. High-level security
requirements.
Final requirements Low-level security R8 Functional requirements with Security errors.
requirements specification of security mechanisms.
Design Checklist of existing security errors.
R9 Functional requirements with Security index.
Functional design Enhanced threat model
specification of security mechanisms.
R10 Security errors. Low-level security
Functional design with secure design Secure design decisions requirements.
decisions R11 Functional requirements with Final requirements.
Security errors specification of security mechanisms.
Low-level security requirements.
Final design Low-level security D1 Final requirements. Functional design.
requirements D2 Functional design. Functional design.
Implementation D3 Functional design. Enhanced threat model.
Threat model.
Code D4 Enhanced threat model. Enhanced threat model.
Assurance D5 Enhanced threat model. Secure design decisions.
Test cases and checklists for D6 Secure design decisions. Secure design decisions.
Final code inspections and static code D7 Functional design with secure design Security errors.
analysis decisions.
Figure 2. Artifact view of SSDP: artifact-artifact D8 Functional design with secure design Security index.
decisions.
relationship D9 Security errors. Low-level security
requirements.
ors must be removed through rework. D10 Functional design with secure design Final design
A2. Test cases should be developed based on decisions. Low-level security
requirements.
functional and security requirements. I1 None None
A3. Integration and acceptance testing needs to be I2 None Code
performed based on the security requirements. I3 Code Code
Penetration testing should be performed based on the A1 Code. Checklists for inspections and Code
static code analysis.
known vulnerabilities and the potential attacks that the A2 Final requirements. Final design. Low- Test cases.
software may encounter. Any security errors found level security requirements.
must be removed. A3 Code. Test cases. Final code.

5. Artifact view of the SSDP
The information in the current artifacts are used to
develop further artifacts. Moreover, each development
activity in the SSDP either results in a new artifact or
enhances an already existing one. This artifact
evolution can be represented using artifact-artifact and
activity-artifact relationships, respectively. This
evolution needs to be explicitly defined to guide
software developers. For the artifact-artifact
relationship, we use “ Æ ” to represent that the target
artifact is produced by taking the source artifact(s) as
input(s). Figure 2 presents these relationships.
Initially, Information about assets and attackers and
Functional requirements are produced which in turn a-
re used to develop the Threat model. High-level
security requirements and Security mechanisms to
fulfill them are specified. The specifications of security
mechanisms are incorporated in the functional
requirements. The resulting artifact, Functional
requirements with specifications of security
mechanisms, is inspected and Security errors are
identified. Security errors are used to specify Low-level
security requirements. Functional requirements with
specifications of security mechanisms are enhanced
with Low-level security requirements to develop Final
requirements. Functional design is developed based on
Final requirements. Threat model is enhanced based
on functional design. Secure design decisions, that can
mitigate the threats in the Enhanced threat model, are
incorporated in the Functional design. Security errors

403
are identified by inspecting the Functional design with
secure design decisions. Low-level security
requirements to remove these errors are developed.
These low-level security requirements (including
already existing ones) are integrated in Functional
design to develop Final design. Final design is used to
develop the code of the software, while Final
requirements, Final design, and Low-level security
requirements identified during the requirements
engineering and design phases are used to generate
security test cases and checklists for inspections and
static code analysis. The tested code, after rework,
results in Final code.
We show the activity-artifact relationships with the
help of Table 1. The first column lists the activities in
the SSDP. The second and third columns identify the
corresponding input and output artifacts, respectively.
6. Summary and conclusions
A secure software development process is required
to incorporate security throughout software
development. We have proposed such a process in this
paper. Our SSDP has two views: (1) activity view
which presents the development activities and their
sequence of execution and (2) artifact view that
illustrates the artifact-artifact and activity-artifact
relationships. Both views are important to provide the
developers with clear guidance.
The SSDP places emphasis on requirements and
design phases. We propose that a threat model is built
during the requirements phase and enhanced during the
design phase. Similarly, risk and cost benefit analysis
should also be performed in both phases. We have
identified inspection as an important error discovering
activity which must be part of requirements, design,
and assurance phases. During the implementation
phase, the selection of an appropriate (secure)
programming language is important. Following secure
coding standards and guidelines is also necessary to
avoid any previously reported security errors. During
the assurance phase, we suggest that inspections and
static code analysis should be performed before testing.
As the security requirements (and secure design
decisions) have been finalized after cost/benefit
analysis during the requirements engineering and
design phases, we propose that all the identified
security errors that violate these requirements must be
removed. Integration and acceptance testing should be
performed while keeping security in mind. Finally,
penetration testing ought to be carried out based on
potential attacks that the software may encounter when
deployed.
404
Acknowledgement
This research is partially funded by the Natural
Sciences and Engineering Research Council of Canada
(NSERC).
References
[1] J. Juerjens, Secure Systems Development with UML,
Springer, 2005.
[2] C.E. Landwehr, A.R. Bull, J.P. McDermott, and W.S.
Choi, “Taxonomy of Computer Program Security Flaws,”
ACM Computing Surveys, 1994, vol. 16, no. 3, pp. 211-254.
[3] I.V. Krsul, “Software Vulnerability Analysis,”
Doctoral dissertation, Department of Computer Sciences,
Purdue University, Indiana, USA, 1998.
[4] M.U.A. Khan and M. Zulkernine, “Quantifying
Security in Secure Software Development Phases,” In Proc.
of the 2nd IEEE International Workshop on Secure Software
Engineering (IWSSE’08), Turku, Finland, 2008, IEEE CS
Press, pp. 955-960, 2008.
[5] A. Jaquith, Security Metrics, Addison Wesley, 2007.
[6] D. Verdon and G. McGraw, “Risk Analysis in
Software Design,” IEEE Security and Privacy, IEEE CS
Press, 2004, vol. 2, no. 4, pp. 79-84.
[7] R. Kissel, “Glossary of Key Information Security
Terms,” National Institute of Standards and Technology,
NISTIR-7298, 2006.
[8] G. McGraw, Software Security: Building Security In,
Addison Wesley, 2006.
[9] S. Lipner, “The Trustworthy Computing Security
Development Lifecycle,” In Proc. of the 20th Annual
Computer Security Applications Conference (ACSAC ‘04),
CA, USA, 2004, IEEE CS Press, pp. 2-13.
[10] OWASP CLASP Project, http://www.owasp.org/index.
php/Category:OWASP_CLASP_Project. Visited May 2009.
[11] I. Flechais, C. Mascolo, and M.A. Sasse, “Integrating
Security and Usability into the Requirements and Design
Process,” International Journal of Electronic Security and
Digital Forensics, Inderscience Publishers, Geneva,
Switzerland, 2007, vol. 1, no. 1, pp. 12-26.
[12] A.S. Sodiya, S.A. Onashoga, and O.B. Ajayi, “Towards
Building Secure Software Systems,” Issues in Informing
Science and Information Technology, Informing Science
Institute, California, USA, 2006, vol. 3, pp. 635-646.
[13] M. Essafi, L. Labed, and H.B. Ghezala, “S2D-ProM: A
Strategy Oriented Process Model for Secure Software
Development,” In Proc. of the 2nd International Conference
on Software Engineering Advances (ICSEA’07), Cap Esterel,
French Riviera, France, 2007, p. 24.
[14] M.U.A. Khan and M. Zulkernine, “On Selecting
Appropriate Development Processes and Requirement
Engineering Methods for Secure Software,” In Proc. of the
4th IEEE International Workshop on Security, Trust, and
Privacy for Software Applications (STPSA 2009), Seattle,
WA, USA, IEEE CS Press, 2009, to appear.
[15] B.W. Boehm and P.N. Papaccio, "Understanding and
Controlling Software Costs," IEEE Transactions on Software
Engineering, 1988, vol. 14, no. 10, pp. 1462-1477.