Ship (A5): SDL Activities and Best Practices 219
without any exceptions. If there are exceptions to security requirements,
they need to be well documented and be time-bound. An example is a
“conditional go,” under which unmet requirements do not stop release
but will be remediated by an agreed-upon date.
Success Factor 6: Final Privacy Review
Similar to Factor 5, this step allows final review of the product against pri-
vacy requirements that were laid out at the start of the cycle and that have
been updated or refined since then. If any requirements are unmet, they
should be documented as exceptions that are time-bound and require
remediation by a definite date.
Success Factor 7: Customer Engagement Framework
As discussed earlier in the chapter, it is important that a framework be
defined to engage customers in security-related discussions both during
and after the sale process. This can limit ad-hoc requests and escalations
from customers and give them confidence that your company has a han-
dle on security.
7.8 De live r abl es
Table 7.2 lists deliverables for this phase of the SDL.
Updated Policy Compliance Analysis
Policy compliance analysis artifacts (see Chapters 4, 5, and 6) should be
updated based on any new requirements or policies that may have come
up during this phase of the SDL.
Security Testing Reports
The findings summary as discussed in Chapter 6 should be updated to
include vulnerability scanning (external, internal, and authenticated) as
well as any new penetration testing that is performed during this phase.
A customer-facing report should also be prepared to share with enter-
prise customers.
220 Core Software Security
Remediation Report
In addition to updating security testing reports (or findings), the reme-
diation report should also be updated to give a better idea of the security
posture of the product going into release. Any findings that have not been
remediated by now (and are not to be remediated before the release date),
should be discussed and put on a roadmap.
Open-Source Licensing Review Report
A formal review report should be prepared of open-source software used
in the software stack that outlines different licensing requirements (The
MIT License, GNU General Public License, GNU Lesser General Public
License, BSD License) and how they are being met. The security and pri-
vacy officers should review the report and sign off on it.
Final Security and Privacy Review Reports
After final review of compliance against security and privacy requirements,
a formal sign-off by security and privacy officers should be required.
Table 7.2 Deliverables for Phase A5
Deliverable Goal
Updated policy compliance
analysis
Analysis of adherence to
company policies
Security testing reports Findings from different types of
security testing in this phase of
SDL
Remediation report Provide status on security posture
of product
Open-source licensing review
report
Review of compliance with
licensing requirements if open-
source software is used
Final security and privacy review
reports
Review of compliance with
security and privacy requirements
Customer engagement
framework
Detailed framework to engage
customers during different stages
of product life cycle
Ship (A5): SDL Activities and Best Practices 221
Customer Engagement Framework
A formally documented process to share security information with cus-
tomers should be delivered as part of this phase. The process should
include types of information (and frequency) that should be shared with
customers, notification in case of security incidents, as well as security
findings and remediation SLAs.
7.9 Metrics
The following metrics should be collected during this phase of the SDL:
• Percent compliance with company policies (updated)
o
Percent of compliance in Phase 5 versus Phase 4
• Number, type, and severity of security issues found through vulner-
ability scanning and penetration testing
o
Overlap of security issues found through different types of testing
o
Comparison of severity of findings from different types of testing
o
Mapping of findings to threats/risks identified earlier
• Number of security findings remediated (updated)
o
Severity of findings
o
Time spent (approximate) in hours to remediate findings
• Number, types, and severity of findings outstanding (updated)
• Percentage compliance with security and privacy requirements
7.10 Chapter Summary
In this chapter we have described the requirements for successful release
and ship of the software product after it has finished the SDLC and
associated SDL activities and best practices (see Figure 7.5). Now that
we have made it through SDL Phase A5 and the product has been
released, the next chapter will describe SDL Phase A6, which will out-
line the SDL post-release support activity (PRSA) phase of our SDL.
After a software product is released and shipped, the software security,
development, and privacy teams, with support from the corporate pub-
lic relations, legal, and other groups must be available to respond to any
possible security vulnerabilities or privacy issues that warrant a response.
Figure 7.5 A1 to A5 SDL activities and best practices.
Ship (A5): SDL Activities and Best Practices 223
In addition, a response plan detailing appropriate processes and proce-
dures must be developed that includes preparations for potential post-
release issues. In addition to external vulnerability disclosure responses,
this phase should include internal review for new product combinations
or cloud deployment, post-release certifications, security architectural
reviews, and tool-based assessments of current, legacy, and M&A pro-
ducts and solutions, as well as third-party reviews of released software
products that may be required by customers, regulatory requirements,
or industry standards.
References
1. Paul, R. (2008). “Diebold Faces GPL Infringement Lawsuit over Voting Machines:
Artifex Software, the Company Behind Ghostscript, Has Filed a Lawsuit
Against. . . .” Arstechnica: Technology Lab/Information Technology, November
4. Available at http://arstechnica.com/information-technology/2008/11/
diebold-faces-gpl-infringement-lawsuit-over-voting-machines.
2. Broersma, M. (2007). “Skype Found Guilty of GPL Violations.” IDG News
Service, July 26. Available at http://www.pcworld.com/article/135120/article.
html.
3. McDougall, P. (2008). “Verizon Settles Open Source Software Lawsuit:
The Issue Centered on Claims That a Subcontractor Used an Open Source
Program Called BusyBox in Verizon’s Wireless Routers.” Information
Week, March 17. Available at http://www.informationweek.com/
verizon-settles-open-source-software-law/206904096.
4. Koetsier, J. (2012). “Sorry, Google Fanboys: Android Security Suffers as Malware
Explodes by 700%.” VentureBeat, September 4. Available at http://venturebeat.
com/2012/09/04/sorry-google-fanboys-android-security-sucks-hard-as-malware-
explodes-by-700/#FKvUAhZrG8g5jywy.99.
5. Rashid, F. (2012). “Oracle Accused of Downplaying Database Flaws,
Severity.” eWeek, January 1. Available at http://www.eweek.com/c/a/Security/
Oracle-Accused-of-Downplaying-Database-Flaws-Severity-155094.
6. Insecure.org (2013). “Download.com Caught Adding Malware to Nmap & Other
Software.” Available at http://insecure.org/news/download-com-fiasco.html.
7. Schwartz, E. (2007). “Open Source Lands in the Enterprise with Both
Feet: Major Business Applications on Linux Turns OS into a Commodity.”
Infoworld, August 6. Available at http://www.infoworld.com/t/applications/
open-source-lands-in-enterprise-both-feet-576.
8. Worthington, D. (2007). “Quacking Through Licensing Complexity: Black
Duck’s Open Source Licensing Solution Tackles GPLv3.” SDTimes, August 6.
Available at http://www.sdtimes.com/link/31007.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.