This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

SAMM - Policy & Compliance - 3

Revision as of 00:40, 20 April 2015 by David Fern (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.

PC1.png PC2.png PC3.png


Policy & Compliance - 3

Objective: Require compliance and measure projects against organization-wide policies and standards


  • Organization-level visibility of accepted risks due to non-compliance
  • Concrete assurance for compliance at the project level
  • Accurate tracking of past project compliance history
  • Efficient audit process leveraging tools to cut manual effort

Add’l Success Metrics

  • >80% projects in compliance with policies and standards as seen by audit
  • <50% time per audit as compared to manual

Add’l Costs

  • Buildout or license tools to automate audit against internal standards
  • Ongoing maintenance of audit gates and exception process

Add’l Personnel

  • Developers (1 days/yr)
  • Architects (1 days/yr)
  • Managers (1 days/yr)

Related Levels

  • Education & Guidance - 3
  • Code Review - 2
  • Security Testing - 2


A. Create compliance gates for projects

Once an organization has established internal standards for security, the next level of enforcement is to set particular points in the project life-cycle where a project cannot pass until it is audited against the internal standards and found to be in compliance.

Usually, the compliance gate is placed at the point of software release such that they are not allowed to publish a release until the compliance check is passed. It is important to provide enough time for the audit to take place and remediation to occur, so generally the audit should begin earlier, for instance when a release is given to QA.

Despite being a firm compliance gate, legacy or other specialized projects may not be able to comply, so an exception approval process must also be created. No more than about 20% of all projects should have exception approval.

B. Adopt solution for audit data collection

Organizations conducting regular audits of project teams generate a large amount of audit data over time. Automation should be utilized to assist in automated collection, manage collation for storage and retrieval, and to limit individual access to sensitive audit data.

For many concrete requirements from the internal standards, existing tools such as code analyzers, application penetration testing tools, monitoring software, etc. can be customized and leveraged to automate compliance checks against internal standards. The purpose of automating compliance checks is to both improve efficiency of audit as well as enable more staff to self-check for compliance before a formal audit takes place. Additionally, automated checks are less error-prone and allow for lower latency on discovery of problems.

Information storage features should allow centralized access to current and historic audit data per project. Automation solutions must also provide detailed access control features to limit access to approved individuals with valid business purpose for accessing the audit data.

All instructions and procedures related to accessing compliance data as well as requesting access privileges should be advertised to project teams. Additional time may be initially required from security auditors to bootstrap project teams.

Additional Resources