199
Chapter 7
Ship (A5): SDL Activities
and Best Practices
Now that you have reached the last phase of the software development
lifecycle, you need to ensure that the software is secure and that privacy
issues have been addressed to a level at which the software is acceptable
for release and ready to ship. Software security and privacy requirements
should have come from initial phases and been refined throughout the
cycle. In this chapter, we will take you through the last stage of policy
compliance review, followed by the final vulnerability scan, pre-release
penetration testing, open-source licensing review, and the final security
and privacy reviews (see Figure 7.1).
As discussed in SDL Phases (A1)–(A4), SDL policy compliance covers
all projects that have meaningful security and privacy risks and is analyzed
in each phase and updated to cover new threats and practices. In the final
policy compliance review, the SDL policy will be reviewed to ensure that
the policy provides specific requirements based on different development
criteria, such as product type, code type, and platform.
A vulnerability scan will look for any remaining vulnerabilities in your
software and associated systems and report potential exposures. This pro-
cess is usually automated, and it will typically be run by somebody in
Figure 7.1 Ship (A5): SDL activities and best practices.
Ship (A5): SDL Activities and Best Practices 201
your own organization. In contrast, a penetration test actually exploits
weaknesses in the architecture of your systems and requires various levels
of expertise within your scope of the software and associated systems you
are testing. A seasoned security individual or team that is part of a third
party to provide an independent point of view, high-level or specialized
external expertise, and “another set of eyes” typically conducts the testing.
During the final phase of the SDL security review of the software
being assessed, all of the security activities performed during the process,
including threat models, tools outputs, and performance against require-
ments defined early in the process will be assessed to determine whether
the software product is ready for release and shipping. We will discuss the
three options that can occur as part of this process.
It is essential to be in compliance with applicable open-source require-
ments to avoid costly and time-consuming litigation. The two primary
areas that need to be of concern for those managing the SDL where open
source software is used as part of the product or solution are license com-
pliance and security.
The privacy requirements must be satisfied before the software can
be released. Privacy requirement verification is typically verified concur-
rently with the final security review and in many cases is now considered
part of the same process.
7.1 A5 Policy Compliance Analysis
As discussed for SDL Phases (A1)–(A4), SDL policy compliance covers
all projects that have meaningful security and privacy risks and is analyzed
in each phase and updated to cover new threats and practices. Specifically,
activities and standards in the policy have been refreshed in each SDL
phase, and have incorporated lessons learned from root-cause analysis of
security incidents, adapted to the changing threat environment, and will
have resulted in tools and technique improvements. During the subse-
quent phases, SDL policy compliance has been tracked and, if needed,
exceptions have been issued for high-risk projects. From the beginning
of the SDL process, the SDL policy has formally defined which projects
qualify for SDL mandates and what the requirements are for compliance.
This policy has become a significant part in the governance of the SDL
process in that it:
202 Core Software Security
• Standardizes the types of projects that fall under the SDL mandate
and activities
• Defines the policy and processes that must happen at each phase of
the SDL/SDLC for project compliance
• Sets the requirements for the quality gates that must be met before
release
In the final policy compliance analysis, the policy will be reviewed to
ensure that it provides specific requirements based on different develop-
ment criteria, such as product type, code type, and platform.
7.2 Vulnerability Scan
Although there is no substitute for actual source-code review by a human,
automated tools do have their advantages and can be used to save time
and resources. They are particularly useful to conduct regression testing
at this stage of the process, as a double check that any possible vulnera-
bilities have not inadvertently been re-introduced into the code and that
all previously identified vulnerabilities have been mitigated throughout
the process. It is also possible that other products with similar function-
ality have had publically disclosed vulnerabilities since the beginning of
the SDL for a particular software product, and these can be checked
during the final security review as well. Given that software products
commonly include 500,000 lines or more of code, vulnerability scan-
ners can be very useful as a cost-effective and time-limited final check
of the SDL. These scanners can carry out complex and comprehensive
data flow analysis to identify vulnerability points that might be missed in
the course of manual human review. These products are a much quicker
and more efficient way to analyze every possible path through a com-
piled code base to find the root-cause-level vulnerabilities than using the
human approach. They are also good tools to “check the checker,” that
is, the software security architect who has conducted manual reviews
throughout the process.
Vulnerability scanning tools explore applications and use databases of
signatures to attempt to identify weaknesses. Vulnerability scans are not
the same as penetration tests and should not be categorized as such; how-
ever, some of the same tools may be used in both processes. A vulnerability
Ship (A5): SDL Activities and Best Practices 203
scan is actually an assessment, and as such will look for known vulner-
abilities in the software and associated systems. It is automated, it can
typically be run by a technician, and it will report potential exposures.
Having your own development staff conduct the vulnerability scans will
help them not only build up a baseline of what is normal for software
security but also to understand it. In contrast, a penetration test actually
exploits weaknesses in the architecture of your systems and requires vari-
ous levels of expertise within your scope of the software and associated
systems you are testing. Such testing is typically conducted by a seasoned
software security professional such as a software security architect or sea-
soned software security engineer.
Vulnerability scanning is a necessary part of software security and the
SDL. Given its automated nature and ease of performance, it should be
run at various times through the SDL as a cost-effective, efficient, and
minimally intrusive way to continually check your work. The results
should be continually baselined to identify code or architectural changes
that may have introduced new vulnerabilities during the process.
Although every effort must be taken to remediate all discovered vul-
nerabilities, there are some cases where the scanner may falsely identify
vulnerability or exceptions are made. False positives are vulnerabilities
where the scanner has identified the software as being vulnerable when, in
fact, it is not. Of course, once this is proven, the false positive can be dis-
counted. Exceptions are made because the remediation will prevent opti-
mal software performance, restrict a critical function in the product, or
even require a complete architecture redesign. The risk is deemed accept-
able because compensating controls are in place or can be put in place
with minimal effort to mitigate the risk. Exceptions may be permanent or
they may have an expiration date attached. The typical vulnerability scan
process is diagramed in Figure 7.2.
Static or dynamic source code vulnerability scanner tools, as discussed
earlier in this book, can be used during this phase as appropriate. If the
software is a Web application, you must use tools designed specifically
for Web application vulnerability analysis. One mistake that should be
avoided if you are using a Web application vulnerability scanner is not to
scan for just the OWASP “Top 10” vulnerabilities, but rather scan for all
software application vulnerabilities. As with static or other dynamic vul-
nerability scanners, if critical, high, or severe application vulnerabilities
are identified by scanning, those vulnerabilities must be fixed before the
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.