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: