Appendix D: OWASP SAMM 2.0 Mapping
TSS-WEB 2.0 generally covers a large number of OWASP SAMM 2.0 security practices, especially from maturity level 1 & 2. We’ve added additional requirements to TSS-WEB where this was possible. However, the scope of TSS-WEB is another as OWASP SAMM.
Whereas TSS-WEB describes a security dev standard for particular development units, OWASP SAMM focuses on the entire organization. Therefore, organization-wide tasks that have to be done by the IT security government function and that are therefore mostly within business function Governance are not covered in TSS-WEB. Also, whereas TSS-WEB describes a robust enterprise standard, OWASP SAMM provides three level of maturity for all objectives.
TSS-WEB can be helpful for implementing a large number of requirements (= those that affect the dev organization) of OWASP SAMM.
Detailed Coverage
Business Function | Security Practice | Stream | Mat. | Requirement | TSS-WEB Coverage |
---|---|---|---|---|---|
Governance | All | All | All | No Not scope of this standard, task for IT security function. | |
Governance | Stream A | 1 | Determine a security baseline representing organization’s policies and standards. | No But you can use TSS-WEB as a basis to describe your organization-specific baseline. | |
Governance | Stream A | 2 | Develop security requirements applicable to all applications. | Yes TSS-WEB covers this for Web-based applications. | |
Governance | Stream A | 3 | Measure and report on the status of individual application’s adherence to policies and standards. | No Not scope of this standard, task for IT security function. | |
Governance | Stream B | 1 | Identify 3rd-party compliance drivers and requirements and map to existing policies and standards. | No This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it. | |
Governance | Stream B | 2 | Publish compliance-specific application requirements and test guidance | No This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it. | |
Governance | Stream B | 3 | Measure and report on individual application’s compliance with 3rd party requirements. | No This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it. | |
Governance | Stream A | 1 | Provide security awareness training for all personnel involved in software development | Yes See “General Requirements” athttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338 | |
Governance | Stream A | 2 | Offer technology and role-specific guidance, including security nuances of each language and platform | Yes See “General Requirements” athttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338 | |
Governance | Stream A | 3 | Standardized in-house guidance around the organization’s secure software development standards. | No This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it. | |
Governance | Stream A | 1 | Identify a “Security Champion” within each development team. | Yes See “General Requirements” athttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/98338 | |
Governance | Stream A | 2 | Develop a secure software center of excellence promoting thought leadership among developers and architects. | partially Although establishing such a community is a task for a IT security function, participation at it is described as role duties for a “security champion” at | |
Governance | Stream A | 3 | Build a secure software community including all organization people involved in software security. | partially Although establishing such a community is a task for a IT security function, participation at it is described as role duties for a “security champion” at | |
Design | Stream A | 1 | A basic assessment of the application risk is performed to understand likelihood and impact of an attack. | Yes See “Security within change management & agile development” at | |
Design | Stream A | 2 | Understand the risk for all applications in the organization by centralizing the risk profile inventory for stakeholders. | No Not covered since not scope of a standard but local risk management procedures in development are defined at | |
Design | Stream A | 3 | Periodically review application risk profiles at regular intervals to ensure accuracy and reflect current state. | No This is defined as a team responsible in | |
Design | Stream B | 1 | Perform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists. | Yes See “Security within change management & agile development” at | |
Design | Stream B | 2 | Standardize threat modeling training, processes, and tools to scale across the organization. | No Not in scope of TSS-WEB, should be described separately and linked into your own standard. | |
Design | Stream B | 3 | Continuously optimization and automation of your threat modeling methodology. | No Not in scope of TSS-WEB, should be described separately and linked into your own standard. | |
Design | Stream A | 1 | High-level application security objectives are mapped to functional requirements. | Yes See “General Requirements” at | |
Design | Stream A | 2 | Structured security requirements are available and utilized by developer teams. | Yes See | |
Design | Stream A | 3 | Build a requirements framework for product teams to utilize. | Yes See | |
Design | Stream B | 1 | Evaluate the supplier based on organizational security requirements. | Yes See | |
Design | Stream B | 2 | Build security into supplier agreements in order to ensure compliance with organizational requirements. | Yes See | |
Design | Stream B | 3 | Ensure proper security coverage for external suppliers by providing clear objectives. | Yes See | |
Design | Stream A | 1 | Teams are trained on the use of basic security principles during design | Yes See “General Requirements” at | |
Design | Stream A | 2 | Establish common design patterns and security solutions for adoption. | Yes See | |
Design | Stream A | 3 | Reference architectures are utilized and continuously evaluated for adoption and appropriateness. | No Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 1 | Elicit technologies, frameworks and integrations within the overall solution to identify risk. | No Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 2 | Standardize technologies and frameworks to be used throughout the different applications | No Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 3 | Impose the use of standard technologies on all software development. | Yes See . Also a responsibility of an architectural board. | |
Implementation | Stream A | 1 | Create a formal definition of the build process so that it becomes consistent and repeatable. | Yes See “Secure build & deployment” at | |
Implementation | Stream A | 2 | Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. | Yes See “Secure build & deployment” at | |
Implementation | Stream A | 3 | Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails. | Yes See “Secure build & deployment” at | |
Implementation | Stream B | 1 | Create records with Bill of Materials of your applications and opportunistically analyze these. | Yes See “Security of 3rd party dependencies” at | |
Implementation | Stream B | 2 | Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. | Yes See “Security of 3rd party dependencies” at | |
Implementation | Stream B | 3 | Analyze used dependencies for security issues in a comparable way to your own code. | Yes See “Security of 3rd party dependencies” at , and reference to metrics in | |
Implementation | Stream A | 1 | Formalize the deployment process and secure the used tooling and processes. | Yes Yes, see “Secure build & deployment” at | |
Implementation | Stream A | 2 | Automate the deployment process over all stages and introduce sensible security verification tests. | Yes See , “Utilize automated security testing tools” | |
Implementation | Stream A | 3 | Automatically verify integrity of all deployed software, indenendently on whether it's internally or externally developed. | Yes Yes, see “Secure build & deployment” at | |
Implementation | Stream B | 1 | Introduce basic protection measures to limit access to your production secrets. | Yes See | |
Implementation | Stream B | 2 | Inject secrets dynamically during deployment process from hardened storages and audit all human access to them. | Yes Yes, see “Secure build & deployment” at | |
Implementation | Stream B | 3 | Improve the lifecycle of application secrets by regularly generating them and by ensuring proper use. | Yes See | |
Implementation | Stream A | 1 | Introduce a structured tracking of security defects and make knowledgeable decisions based on this information. | Yes See “Defect tracking” at | |
Implementation | Stream A | 2 | Rate all security defects over the whole organization consistently and define SLAs for particular severity classes. | No Not scope of this standard, task for IT security function. | |
Implementation | Stream A | 3 | Enforce the predefined SLAs and integrate your defect management system with other relevant tooling. | No Not scope of this standard, task for IT security function. | |
Implementation | Stream B | 1 | Regularly go over previously recorded security defects and derive quick wins from basic metrics. | Yes See “Defect tracking” at | |
Implementation | Stream B | 2 | Collect standardized defect management metrics and use these also for prioritization of centrally driven initiatives. | No Not scope of this standard, task for IT security function. | |
Implementation | Stream B | 3 | Continuously improve your security defect management metrics and correlate it with other sources. | No Not scope of this standard, task for IT security function. | |
Verification | Stream A | 1 | Identify application and infrastructure architecture components and review for basic security provisioning | Yes See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in | |
Verification | Stream A | 2 | Validate the architecture security mechanisms | Yes See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in | |
Verification | Stream A | 3 | Review the architecture effectiveness and feedback results to improve the security architecture. | No Not scope of this standard, could be task for IT security function or architecture board. | |
Verification | Stream B | 1 | Ad-hoc review of the architecture for unmitigated security threats. | Yes See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in | |
Verification | Stream B | 2 | Analyze the architecture for known threats. | Yes See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in | |
Verification | Stream B | 3 | Feed the architecture review results back into the enterprise architecture, organization design principles & patterns, security solutions and reference architectures. | No Not scope of this standard, could be task for IT security function or architecture board. | |
Verification | Stream A | 1 | Test for software security controls | Yes See “Custom security tests & developer tests” at | |
Verification | Stream A | 2 | Derive test cases from known security requirements | Yes See “Complete and correct implementation” at | |
Verification | Stream A | 3 | Perform regression testing (with security unit tests) | No | |
Verification | Stream B | 1 | Perform security fuzzing testing | Yes See “Custom security tests & developer tests” at | |
Verification | Stream B | 2 | Create and test abuse cases and business logic flaw test | Yes See “Custom security tests & developer tests” at | |
Verification | Stream B | 3 | Denial of service and security stress testing | Yes See “Custom security tests & developer tests” at | |
Verification | Stream A | 1 | Utilize automated security testing tools | Yes See “Utilize automated security testing tools” at | |
Verification | Stream A | 2 | Employ application-specific security testing automation | Yes See “Custom security tests & developer tests” at | |
Verification | Stream A | 3 | Integrate automated security testing into the build and deploy process | Yes See “Secure build & deployment” at | |
Verification | Stream B | 1 | Perform manual security testing of high-risk components | Yes See “Custom security tests & developer tests” at | |
Verification | Stream B | 2 | Conduct manual penetration testing | Yes See “Custom security tests & developer tests:” at | |
Verification | Stream B | 3 | Integrate security testing into development process | Yes See “Custom security tests & developer tests” at | |
Operations | Stream A | 1 | Use available log data to perform best-effort detection of possible security incidents. | Yes See requirements on “Possible security incidents monitoring” at and | |
Operations | Stream A | 2 | Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation. | Yes See requirements on “Incident management” at | |
Operations | Stream A | 3 | Use a proactively managed process for detection of incidents. |
| |
Operations | Stream B | 1 | Identify roles and responsibilities for incident response. | Yes See requirements on “Incident management” at | |
Operations | Stream B | 2 | Establish a formal incident response process and ensure staff are properly trained in performing their roles. | Yes See requirements on “System hardening” at | |
Operations | Stream B | 3 | Employ a dedicated, well-trained incident response team. | No Not scope of this standard, task for IT security function. | |
Operations | Stream A | 1 | Perform best-effort hardening of configurations, based on readily available information. | Yes See requirements on “System hardening” at | |
Operations | Stream A | 2 | Perform consistent hardening of configurations, following established baselines and guidance. | Yes See requirements on “System hardening” at | |
Operations | Stream A | 3 | Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects. | Yes See requirements on “Security monitoring” at | |
Operations | Stream B | 1 | Perform best-effort patching of system and application components. | Yes See requirements on “System updating / patching” at and “Security of 3rd party dependencies” at | |
Operations | Stream B | 2 | Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers. | Yes See requirements on“System updating / patching” at and “Security of 3rd party dependencies” at | |
Operations | Stream B | 3 | Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components. |
| |
Operations | Stream A | 1 | Implement basic data protection practices | Yes See , and | |
Operations | Stream A | 2 | Develop data catalog and establish data protection policy. | Yes See “Security Documentation” at | |
Operations | Stream A | 3 | Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalog and data protection policy. |
| |
Operations | 1 | Decomission unused applications and services as identified. Manage customer upgrades/migrations individually. | Yes See requirement on “Decomission” at | ||
Operations | 2 | Develop repeatable decommissioning processes for unused systems/services, and for migration from legacy dependencies. Manage legacy migration roadmaps for customers. | No Not scope of this standard, task for IT security function. | ||
Operations | 3 | Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software. | No Not scope of this standard, task for IT security function. |