One of the other new items is a full XML version of the SAMM 1.0 framework document. It includes all the content from the whole SAMM document, so now it should be a lot simpler to build tools and automation around the model itself (not to mention making translations into other languages a lot simpler).

Masaki Kubo at JPCERT undertook the great effort to translate the SAMM 1.0 document into Japanese. It’s available here. I’d like to thank him and JPCERT very much for the effort and the motivation to drive this to completion. Fantastic work!

It’s been a little while since I’ve posted anything to the site, but don’t mistake that for lack of activity! There’s actually a backlog of contributed resources that I’ve been meaning to post here but haven’t had the time to get it done yet. They’re all available via the mailing list with a little digging, but in the next week or two, we’ll try to get them all up here.

Over the weekend, we managed to get large parts of the SAMM content imported into the OWASP wiki so that folks can browse the model online. This will also support community contributions for additional material that maps under the SAMM activities. It’ll also help for folks making mappings to existing regulatory standards.

The official SAMM releases going forward will still be made in PDF form for mass distribution.  The wiki version will syndicate some of the content for easy online referencing, but the PDF version is still the authoritative source of SAMM information.

Check it out on the OWASP wiki.

• Disciplines became Business Functions – The term ‘disciple’ used for the four high-level categories didn’t accurately capture their intent. After several discussions, it made more sense to rephrase them as the core business functions of software development and draw the security-related practices down from those.
• Strategic Planning became Strategy & Metrics – These changes were made to place more emphasis on the measurement of the overall software security assurance program. Even though example metrics were given for each maturity level, feedback indicated this wasn’t explicit enough
• Standards & Compliance became Policy & Compliance – Feedback showed the term ‘standard’ wasn’t as popularly used as the term ‘policy’ for referring to the normative requirements an organization places on software development. Standards are still included here, but as an extension of policies.
• Threat Modeling became Threat Assessment – Feedback indicated this section was too specific to usage of attack trees, so the language was loosened to allow other methodologies for the threat modeling activities. Also, the name was changed to avoid collision with existing notions of the term ‘threat modeling’ (e.g. Microsoft’s methodology). Further, abuse-case modeling activities were moved from Security Requirements into this practice since many felt it was more suited here.
• Defensive Design became Secure Architecture – The term ‘defensive design’ didn’t resonate with reviewers at all, so the activities were re-evaluated and recast as organization-wide augmentations to the design process that emphasize centralized application architectures. Activities related to creating access control matrices were moved into Security Requirements since feedback showed this was more of a specifying activity rather than an architecture-related one. A new activity was added here to require promotion of centralized infrastructure and services since most reviewers felt that activity was missing from the Beta.
• Architecture Review became Design Review – This change was made to ensure the terms ‘architecture’ and ‘design’ were being used more consistently. This practice discussed reviewing detailed design, so ‘design review’ seemed a more agreeable title.
• Infrastructure Hardening became Environment Hardening – Since the term ‘infrastructure’ can easily be interpreted to include network devices and other appliances, the title and associated activities were changed to indicate specific focus on bolstering the security posture of the software’s environment.

• Executive summary and introduction to the model
• Improved details on applying the model to solve problems
• Assessment worksheets for evaluating existing programs
• Roadmaps for financial services and government organizations
• Improvements and refinements to the model (I’ll cover changes individually in separate posts)

Many thanks to the individual reviewers and the organizations that have volunteered time to help improve SAMM. I look forward to more active participants as we push forward with some of the future development plans for SAMM.

• Better introduction – there’s a proper Executive Summary and a section describing the structure of the model before diving into the details
• A section on assessing an existing assurance program – this should help folks that need to map an existing software security program into SAMM (or anyone just performing an assessment of a software security program in general)
• Better guidance on building assurance programs – the Beta had some short text, but the next release includes a bigger section on and building a roadmap for a particular organization
• New layout and design – revamped the ordering of SAMM materials based on feedback from users and there’s a new topical table of contents (to better route people through the resource provided)

I’m looking forward to feedback on the 1.0 release once it’s out this week… stay tuned!