Difference between revisions of "SAMM - Roadmap - Independent Software Vendor"

From OWASP
Jump to: navigation, search
m
m
 
Line 1: Line 1:
 
{{OpenSAMM}}
 
{{OpenSAMM}}
[[Category:OWASP Software Assurance Maturity Model Project]]
 
  
 
=Independent Software Vendor=
 
=Independent Software Vendor=

Latest revision as of 19:53, 4 May 2009

250px-OpenSAMM_logo.png For the latest project news and information,
join the mailing list and visit the OpenSAMM website.

Independent Software Vendor

SAMM-Roadmap-ISV.png

Rationale

An Independent Software Vendor involves the core business function of building and selling software components and applications.

Initial drivers to limit common vulnerabilities affecting customers and users leads to early concentration on Code Review and Security Testing activities.

Shifting toward more proactive prevention of security errors in product specification, an organization adds activities for Security Requirements over time.

Also, to minimize the impact from any discovered security issues, the organization ramps up Vulnerability Management activities over time.

As the organization matures, knowledge transfer activities from Operational Enablement are added to better inform customers and users about secure operation of the software.

Additional Considerations

Outsourced Development

For organizations using external development resources, restrictions on code access typically leads to prioritization of Security Requirements activities instead of Code Review activities. Additionally, advancing Threat Assessment in earlier phases would allow the organization to better clarify security needs to the outsourced developers. Since expertise on software configuration will generally be strongest within the outsourced group, contracts should be constructed to account for the activities related to Operational Enablement.

Internet-Connected Applications

Organizations building applications that use online resources have additional risks from the core internet-facing infrastructure that hosts the internet-facing systems. To account for this risk, organizations should add activities from Environment Hardening to their roadmaps.

Drivers and Embedded Development

For organizations building low-level drivers or software for embedded systems, security vulnerabilities in software design can be more damaging and costly to repair. Therefore, roadmaps should be modified to emphasize Secure Architecture and Design Review activities in earlier phases.

Organizations Grown by Acquisition

In an organization grown by acquisition, there can often be several project teams following different development models with varying degrees of security-related activities incorporated. An organization such as this may require a separate roadmap for each division or project team to account for varying starting points as well as project-specific concerns if a variety of software types are being developed.






Additional Resources