SAMM - Roadmap - Independent Software Vendor

From OWASP
Revision as of 16:03, 3 May 2009 by Pravir Chandra (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
250px-OpenSAMM_logo.png For the latest project news and information,
join the mailing list and visit the OpenSAMM website.

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