How SAMM Addresses Out-sourced Development

How SAMM Addresses Out-sourced Development 

The Software Assurance Maturity Model is an open framework to help organizations implement a software security program that is tailored to the specific risk profile of their organization. The framework is maintained under OWASP’s OpenSAMM project.

SAMM framework is flexible, by design, to apply to most organizations and businesses. Its content is categorized under four (4) major business functions (Governance, Construction, Verification, and Deployment) and each function defines three (3) security practices. Every practice is mapped to 3 levels of maturity.

Despite SAMM’s comprehensive guidelines around establishing an organization-wide security program and integrating security into in-house software development life-cycle, it does not elaborate as much on third-party vendor security and outsourced software development. There is no dedicated security practice for outsourced development, and it is mainly addressed in a number of recommended activities under various functions and practices.

The following is a paragraph taken from OpenSAMM document on 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.”

The following are the recommended activities under various SAMM practices where third-party security is addressed:

  • Threat Assessment practice, Level 3, Activity A: Explicitly evaluate risk from third-party components.
  • Security Requirements practice, Level 3, Activity A: If software is being built by a third-party, security requirements, once identified, should be included with functional requirements delivered to vendors.
  • Security Requirements practice, Level 3, Activity A: Build security requirements into vendor agreements
  • Environment Hardening practice, Level 1, Activity B: Check for and install security updates for third-party code.

In summary, OpenSAMM framework addresses outsourcing security under various verticals and security practices, and not as a unified practice. The essence of SAMM’s recommendations around outsourcing boils down to investing more time and resources during requirements analysis and threat assessment practices when dealing with third-party vendors. Finally, SAMM recommends establishing processes to follow-up with vendors to obtain post-deployment security patches.

 

Previous Article
Why you shouldn’t use the OWASP Top 10 as a list of software security requirements
Why you shouldn’t use the OWASP Top 10 as a list of software security requirements

On February 15, the Open Web Application Security Project (OWASP) came out with its 2013 list of candidates...

Next Article
Can software security requirements yield a faster time to market?
Can software security requirements yield a faster time to market?

At the surface, the answer to this question is clearly no. Development teams that build more features and s...