Chapter 6
Design and
Development (A4):
SDL Activities and
Best Practices
In this chapter we will describe the SDL activities for the design and
develop ment (A4) phase of our security development lifecycle (see
Figure6.1). This phase can be mapped to the “readiness” phase in a typi-
cal software development lifecycle. We start with the continuation of pol-
icy compliance analysis for this phase and then move on to describe the
elements of security test case execution. Building on the proper process
for security testing that should have already been created, documented,
and tested, analysis will continue until necessary tuning is identified in
order to accomplish the required security level. We then describe the use
of automated tools such as static, dynamic, and fuzz test tools to help
automate and enforce security practices efficiently and effectively at a
low cost. Static analysis analyzes the source code prior to compiling, pro-
vides a scalable method of security code review, and helps ensure that
secure coding policies are being followed. Dynamic analysis monitors
application behavior and ensures that the software functionality works
Figure 6.1 Design and Development (A4): SDL activities and best practices.
Design and Development (A4): SDL Activities and Best Practices 163
as designed. Fuzz testing induces program failure by deliberately intro-
ducing malformed or random data to an application and can be used as
an effective and low-cost way of finding potential security issues prior
to release and potentially throughout the SDL process. Fuzz testing is a
specialized form of dynamic analysis. By using the latest version of these
automated tools, the latest known automated security analysis, vulnera-
bilities, and recommended protections will be identified. After these
multiple automated tools have been used to quickly analyze the flaws
and vulnerabilities in the software, the code is then reviewed manually,
every issue validated, and the code inspected to overcome the limitations
of automated tools and techniques. As part of this process, attack surface
and threat model reviews will ensure that any new attack vectors that
have been created by any design or implementation changes have been
identified and mitigated. Finally, we discuss the need, value, and process
for privacy validation and remediation to be conducted during this phase
of the SDL.
6.1 A4 Policy Compliance Analysis
This is a continuation of the A3 policy compliance review described in
the previous chapter. As you will see, we continue to perform policy com-
pliance analysis during different phases and review it again and again. It
is of paramount importance that you persist through this and not make
an assumption that you have covered everything in previous iterations.
You will be surprised how often things are missed during initial phases/
iterations of this step.
During this phase, any policy that exists outside the domain of the
SDL policy is reviewed (or reviewed again). This may include policies
from outside the development organization that carry security and privacy
requirements and guidelines to be adhered to when developing software
or applications anywhere within the organization. Often, too, policies
are updated during the development process, and new requirements are
added. Thus it is best to obtain a list of updated policies and make sure
you have incorporated any additional requirements.
Corporate security and privacy policies will likely instruct designers
and developers on what the security and privacy features need to be and
how they must be implemented. Other policies may focus on the use of

Get Core Software Security now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.