Figure 2.10 Chapter 8: Post-Release Support (PRSA1-5): SDL activities and best practices.
Figure 2.9 Chapter 7: Ship (A5): SDL activities and best practices.
50 Core Software Security
Please note that, unlike some of the SDLs you may have seen before,
we include post-release support activities and best practices in our SDL,
as shown in Figure 2.10. We have included this because most software
security teams or their equivalent, especially those in mid-sized or small
companies, do not have the luxury of having an independent Product
Security Incident Response Team (PSIRT), a team dedicated solely to
conduct security M&A assessments, third-party reviews, post-release
certifications, internal reviews for new product combinations of cloud
deployments, or review for legacy software that is still in use or about to
be re-used. It takes some outside-the-box thinking to manage all of this
with a small team. Later in the book we will discuss leveraging seasoned
software security architects, software security champions, specialized soft-
ware, and third-party contractors to accomplish SDL goals and activities.
2.10 Software Development Methodologies
Earlier in the chapter we discussed the various SDLC models and pro-
vided a visual overview of our mapping of our SDL model to a generic
SDLC. It should be noted, however, that multiple software development
methodologies are used within the various SDLC models. Every software
development methodology approach acts as a basis for applying specific
frameworks to develop and maintain software and is less concerned with
the technical side but rather the organizational aspects of the process of cre-
ating software. Principal among these development methodologies are the
Waterfall model and Agile together with its many variants and spin-offs.
The Waterfall model is the oldest and most well known software develop-
ment methodology. The distinctive feature of the Waterfall model is its
sequential step-by-step process from requirements. Agile methodologies
are gaining popularity in industry although they comprise a mix of tra-
ditional and newly software development practices. You may see Agile or
traditional Waterfall or maybe a hybrid of the two. We have chosen to give
a high-level description of the Waterfall and Agile development models
and a variant or two of each as an introduction to software development
methodologies. Given the number of models that exist, we have not only a
generic model for our SDL model but will do the same in Chapter 9 when
we describe the applicability of our SDL to a few of the most popular soft-
ware development models that you may encounter over the next few years.
The Secure Development Lifecycle 51
2.10.1 Waterfall Development
Waterfall development (see Figure 2.11) is another name for the more
traditional approach to software development. This approach is typi-
cally higher-risk, more costly, and less efficient than the Agile approach
that will be discussed later in this chapter. The Waterfall approach uses
requirements that are already known, each stage is signed off before the
next commences, and requires extensive documentation because this is the
primary communication mechanism throughout the process. Although
most development organizations are moving toward Agile methods of
development, the Waterfall method may still be used when requirements
are fully understood and not complex. Since the plan is not to revisit a
phase using this methodology once it is completed, it is imperative that
you do it right the first time: There is generally no second chance.
Although Waterfall development methodologies vary, they tend to be
similar in that practitioners try to keep to the initial plan, do not have
working software until very late in the cycle, assume they know every-
thing upfront, minimize changes through a change control board (i.e.,
assume that change is bad and can be controlled), put most responsi-
bility on the project manager (PM), optimize conformance to schedule
and budget, generally use weak controls, and allow realization of value
only upon completion. They are driven by a PM-centric approach under
the belief that if the processes in the plan are followed, then everything
Plan
Build
Test
Review
Deploy
Figure 2.11 Waterfall software development methodology.
52 Core Software Security
will work as planned. In today’s development environment, most of the
items listed in the previous sentence are considered negative attributes of
the Waterfall methodology and are just a few of the reasons that indus-
try is moving toward Agile development methodologies. The Waterfall
approach may be looked on as an assembly-line approach which may be
excellent when applied properly to hardware but which has shortcomings
in comparison to Agile when it comes to software development.
2.10.1.1 Iterative Waterfall Development
The iterative Waterfall development model (see Figure 2.12) is an
improvement on the standard Waterfall model. This approach carries
less risk than a traditional Waterfall approach but is more risky and less
efficient than the Agile approach. In the iterative Waterfall method, the
overall project is divided into various phases, each executed using the tra-
ditional Waterfall method. Dividing larger projects into smaller identifi-
able phases results in a smaller scope of work for each phase, and the end
deliverable of each phase can be reviewed and improved if necessary before
moving to the next phase. Overall risk is thus reduced. Although the iter-
ative method is an improvement over the traditional Waterfall method,
you are more likely to face an Agile approach to software development
Plan Build
Test Review
Deploy
Plan Build
Test Review
Deploy
Figure 2.12 Iterative Waterfall software development methodology.
The Secure Development Lifecycle 53
rather than either a standard or an iterative Waterfall methodology in
today’s environment.
2.10.2 Agile Development
The Agile approach is based on both iterative and incremental develop-
ment methods. Requirements and solutions evolve through collaboration
among self-organizing, cross-functional teams, and a solution resulting
from every iteration is reviewed and refined regularly throughout the
process. The Agile method is a time-boxed iterative approach that facili-
tates a rapid and flexible response to change, which in turn encourages
evolutionary development and delivery while promoting adaptive plan-
ning, develop ment, teamwork, collaboration, and process adaptability
throughout the lifecycle of the project. Tasks are broken into small incre-
ments that require minimal planning. These iterations have short time
frames called “time boxes” that can last from one to four weeks. Multiple
iterations may be required to release a product or new features. A cross-
functional team is responsible for all software development functions
in each iteration, including planning, requirements analysis, design,
coding, unit testing, and acceptance testing. An Agile project is typi-
cally cross-functional, and self-organizing teams operate independently
from any corporate hierarchy or other corporate roles of individual team
members, who themselves decide how to meet each iteration’s require-
ments. This allows the project to adapt to changes quickly and mini-
mizes overall risk. The goal is to have an available release at the end of
the iteration, and a working product is demonstrated to stakeholders at
the end of each iteration.
2.10.2.1 Scrum
Scrum (see Figure 2.13) is an iterative and incremental Agile software
development method for managing software projects and product or
application development. Scrum adopts an empirical approach, accept-
ing that the problem cannot be fully understood or defined and focus-
ing instead on maximizing the team’s ability to deliver quickly and to
respond to emerging requirements. This is accomplished through the
use of co-located, self-organizing teams in which all disciplines can be
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.