TSS-WEB 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.

Governance

Security Practices Stream Mat. Level Requirement TSS-WEB Coverage
Strategy & Metrics All All All No. Not scope of TSS-WEB task for IT security function.
Policy & Compliance Stream A Policy & Standards 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.
Policy & Compliance Stream A Policy & Standards 2 Develop security requirements applicable to all applications. Yes. TSS-WEB covers this for Web-based applications.
Policy & Compliance Stream A Policy & Standards 3 Measure and report on the status of individual application’s adherence to policies and standards. No. Not scope of TSS-WEB, task for IT security function.
Policy & Compliance Stream B Compliance Management 1 Identify 3rd-party compliance drivers and requirements and map to existing policies and standards 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.
Policy & Compliance Stream B Compliance Management 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.
Policy & Compliance Stream B Compliance Management 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.
Education & Guidance Stream A Training and Awareness 1 Provide security awareness training for all personnel involved in software development Yes. See “General Requirements” at A.2.1 Roles & Responsibilities
Education & Guidance Stream A Training and Awareness 2 Offer technology and role-specific guidance, including security nuances of each language and platform Yes. See A.2.1 Roles & Responsibilities
Education & Guidance Stream A Training and Awareness 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.
Education & Guidance Stream A Training and Awareness 1 Identify a “Security Champion” within each development team. Yes. See A.2.1 Roles & Responsibilities
Education & Guidance Stream A Training and Awareness 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 Roles
Education & Guidance Stream A Training and Awareness 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 Roles

Design

Security Practices Stream Mat. Level Requirement TSS-WEB Coverage
Threat Assessment Stream A Application Risk Profile 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 A.2.3 Secure Design
Threat Assessment Stream A Application Risk Profile 2 Understand the risk for all applications in the organization by centralizing the risk profile inventory for stakeholders. No. Not covered since not in scope but local risk management procedures in development are defined at . TBD
Threat Assessment Stream A Application Risk Profile 3 Periodically review application risk profiles at regular intervals to ensure accuracy and reflect current state. This is defined as a team responsible in TBD
Threat Assessment Stream B Threat Modeling 1 Perform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists. See A.2.3 Secure Design.
Threat Assessment Stream B Threat Modeling 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.
Threat Assessment Stream B Threat Modeling 3 Continuously optimization and automation of your threat modeling methodology. No. Not in scope of TSS-WEB. Should be described
Security Requirements Stream A Software Requirements 1 High-level application security objectives are mapped to functional requirements. TBD
Security Requirements Stream A Software Requirements 2 Structured security requirements are available and utilized by developer teams. Yes. See A.2.4 Secure Implementation.
Security Requirements Stream A Software Requirements 3 Build a requirements framework for product teams to utilize. See A.2.4 Secure Implementation.
Security Requirements Stream B Compliance Management 1 Evaluate the supplier based on organizational security requirements. See A.4 - Outsourced Development
Security Requirements Stream B Compliance Management 2 Build security into supplier agreements in order to ensure compliance with organizational requirements. See A.4 - Outsourced Development
Security Requirements Stream B Compliance Management 3 Ensure proper security coverage for external suppliers by providing clear objectives. Yes. See A.4 - Outsourced Development
Security Architecture Stream Architecture 1 Teams are trained on the use of basic security principles during design. Yes. See A.2.3 Secure Design
Security Architecture Stream Architecture 2 Establish common design patterns and security solutions for adoption. Yes. See B.1 - Secure Design Principles
Security Architecture Stream Architecture 3 Reference architectures are utilized and continuously evaluated for adoption and appropriateness. No. Not scope of TSS-WEB. This is a responsibility of architectural board.
Security Architecture Stream B Technology Management 1 Elicit technologies, frameworks and integrations within the overall solution to identify risk. No. Not scope of TSS-WEB.
Security Architecture Stream B Technology Management 2 Standardize technologies and frameworks to be used throughout the different applications No. Not scope of TSS-WEB.
Security Architecture Stream B Technology Management 3 Impose the use of standard technologies on all software development. Yes. See A.2.3 Secure Design. This can also also be concdered a responsibility of an architectural board.

Implementation

Security Practices Stream Mat. Level Requirement TSS-WEB Coverage
Secure Build Stream A Build Process 1 Yes. Create a formal definition of the build process so that it becomes consistent and repeatable. See A.2.5 Secure Build & Deployment.
Secure Build Stream A Build Process 2 Yes. Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. Yes. See A.2.5 Secure Build & Deployment.
Secure Build Stream A Build Process 3 Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails. Yes. See See A.2.5 Secure Build & Deployment.
Secure Build Stream B Software Dependencies 1 Create records with Bill of Materials of your applications and opportunistically analyze these. Yes. See See A.2.6 Securing Third-Party Dependencies.
Secure Build Stream B Software Dependencies 2 Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. Yes. See A.2.6 Securing Third-Party Dependencies.
Secure Build Stream B Software Dependencies 3 Analyze used dependencies for security issues in a comparable way to your own code. Yes. See A.2.6 Securing Third-Party Dependencies, and reference to metrics in A.3 - Security Tests
Seure Deployment Stream A Deployment Process 1 Formalize the deployment process and secure the used tooling and processes Yes, see A.2.5 Secure Build & Deployment.
Seure Deployment Stream A Deployment Process 2 Automate the deployment process over all stages and introduce sensible security verification tests. See A.3 - Security Tests, “Utilize automated security testing tools”
Seure Deployment Stream A Deployment Process 3 Automatically verify integrity of all deployed software, indenendently on whether it’s internally or externally developed. See A.2.5 Secure Build & Deployment.
Seure Deployment Stream B Secret Management 1 Introduce basic protection measures to limit access to your production secrets. See B.11 - Protection of Secrets
Seure Deployment Stream B Secret Management 2 Inject secrets dynamically during deployment process from hardened storages and audit all human access to them Yes, see A.2.5 Secure Build & Deployment.
Seure Deployment Stream B Secret Management 3 Improve the lifecycle of application secrets by regularly generating them and by ensuring proper use. Yes. See B.11 - Protection of Secrets.
Defect Management Stream A Defect Tracking 1 Introduce a structured tracking of security defects and make knowledgeable decisions based on this information. See A.3.2 Handling Security Findings.
Defect Management Stream A Defect Tracking 2 Rate all security defects over the whole organization consistently and define SLAs for particular severity classes. Not scope of TSS-WEB, task for IT security function.
Defect Management Stream A Defect Tracking 3 Enforce the predefined SLAs and integrate your defect management system with other relevant tooling. No. Not in scope of TSS-WEB; task for IT security function.
Defect Management Stream B Metrics and Feedback 1 Regularly go over previously recorded security defects and derive quick wins from basic metrics. Yes, see A.3.2 Handling Security Findings.
Defect Management Stream B Metrics and Feedback 2 Collect standardized defect management metrics and use these also for prioritization of centrally driven initiatives. Not scope of TSS-WEB, task for IT security function.
Defect Management Stream B Metrics and Feedback 3 Continuously improve your security defect management metrics and correlate it with other sources Not scope of TSS-WEB, task for IT security function.

Verification

Security Practices Stream Mat. Level Requirement TSS-WEB Coverage
Architecture Assessment Stream A Architecture Validation 1 Identify application and infrastructure architecture components and review for basic security provisioning Yes. See, A.2.3 Secure Design, and “architectural approval” at A.2.7 Security Gates.
Architecture Assessment Stream A Architecture Validation 2 Validate the architecture security mechanisms Yes. See, A.2.3 Secure Design, and “architectural approval” at A.2.7 Security Gates.
Architecture Assessment Stream A Architecture Validation 3 Review the architecture effectiveness and feedback results to improve the security architecture. No. Not in scope of TSS-WEB; could be task for IT security function or architecture board
Architecture Assessment Stream B Architecture Migitigation 1 Ad-hoc review of the architecture for unmitigated security threats. Yes. See A.2.3 Secure Design, and “architectural approvals” at A.2.7 Security Gates.
Architecture Assessment Stream B Architecture Migitigation 2 Analyze the architecture for known threats. Yes. See A.2.3 Secure Design, and “architectural approval” at A.2.7 Security Gates.
Architecture Assessment Stream B Architecture Migitigation 3 Feed the architecture review results back into the enterprise architecture, organization design principles & patterns, security solutions and reference architectures. No. Not in scope of TSS-WEB; could be a task of an architecture board
Requirements-driven Testing Stream A Control Verification 1 Test for software security controls Yes. See A.3.4 - Custom Security Tests.
Requirements-driven Testing Stream A Control Verification 2 Derive test cases from known security requirements Yes. See A.2.4 Secure Implementation.
Requirements-driven Testing Stream A Control Verification 3 Perform regression testing (with security unit tests) No
Requirements-driven Testing Stream B Misuse / Abuse Testing 1 Perform security fuzzing testing Yes. See A.3.4 - Custom Security Tests.
Requirements-driven Testing Stream B Misuse / Abuse Testing 2 Create and test abuse cases and business logic flaw test Yes. See A.3.4 - Custom Security Tests.
Requirements-driven Testing Stream B Misuse / Abuse Testing 3 Denial of service and security stress testing Yes. See A.3.4 - Custom Security Tests.
Security Testing Stream A Scalable Baseline 1 Utilize automated security testing tools Yes. See A.3.3 Automated Security Scans.
Security Testing Stream A Scalable Baseline 2 Employ application-specific security testing automation Yes. See A.2.5 Secure Build & Deployment.
Security Testing Stream A Scalable Baseline 3 Integrate automated security testing into the build and deploy process Yes. See A.2.5 Secure Build & Deployment.
Security Testing Stream B Deep Understanding 1 Perform manual security testing of high-risk components Yes. See A.3.4 - Custom Security Tests.
Security Testing Stream B Deep Understanding 2 Conduct manual penetration testing Yes. See A.3.4 - Custom Security Tests.
Security Testing Stream B Deep Understanding 3 Integrate security testing into development process Yes. See A.3.4 - Custom Security Tests.

Operation

Security Practices Stream Mat. Level Requirement TSS-WEB Coverage
Incident Management Stream A Incident Detection 1 Use available log data to perform best-effort detection of possible security incidents. Yes. See A.5.8 Security Monitoring and Alerting
Incident Management Stream A Incident Detection 2 Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation. See A.5.11 Incident Management]
Incident Management Stream A Incident Detection 3 Use a proactively managed process for detection of incidents. No. Not scope of TSS-WEB; task for IT security function
Incident Management Stream B Incident Detection Incident Response 1 Identify roles and responsibilities for incident response. Yes. See requirements on No. Not scope of TSS-WEB; task for IT security function.
Incident Management Stream B Incident Detection Incident Response 2 Establish a formal incident response process and ensure staff are properly trained in performing their roles. No. Not scope of TSS-WEB; task for IT security function
Incident Management Stream B Incident Detection Incident Response 3 Employ a dedicated, well-trained incident response team. No. Not scope of TSS-WEB; task for IT security function
Environment Management Stream A Configuration Hardening 1 Perform best-effort hardening of configurations, based on readily available information. Yes. See A.5.2 System Hardening]
Environment Management Stream A Configuration Hardening 2 Perform consistent hardening of configurations, following established baselines and guidance. Yes. See A.5.2 System Hardening]
Environment Management Stream A Configuration Hardening 3 Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects. Yes. See A.5.2 System Hardening]
Environment Management Stream B Patching and Updating 1 Perform best-effort patching of system and application components Yes. See requirements on A.5.9 System Maintenance].
Environment Management Stream B Patching and Updating 2 Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers. See A.5.9 System Maintenance] and A.2.6 Securing Third-Party Dependencies
Environment Management Stream B Patching and Updating 3 Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components. YES. TBD
Operational Management Stream A Data Protection 1 Implement basic data protection practices Yes. See B.10 - Data Security, B.9 - Error Handling and Logging and A.5 - Secure Operation]
Operational Management Stream A Data Protection 2 Develop data catalog and establish data protection policy. TBD
Operational Management Stream A Data Protection 3 Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalog and data protection policy. Yes. See TBD
Operational Management Stream B Systgem Decomissioning / Legacy Management 1 Decomission unused applications and services as identified. Manage customer upgrades/migrations individually. Yes. See A.5.9 System Maintenance]
Operational Management Stream B Systgem Decomissioning / Legacy Ma nagement 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 TSS-WEB
Operational Management Stream B Systgem Decomissioning / Legacy Management 3 Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software. No. Not scope of TSS-WEB