About
This is the official site of TSS-WEB, an open requirement framework focused on the secure development and operation of web-based applications and services. All requirements here are based on common standards and best practices, including those from OWASP, Microsoft, NIST, SAFECode and ISO/IEC.
Note that this project and its content are provided “as is” without any guarantees. The framework and its controls are subject to change without notice. You assume all risks associated with using this content.
Please not that the Atlassian space has been removed and migrated to Github.
Purpose
The purpose of this framework is to offer a comprehensive, consistent, and practical set of technical and organizational AppSec controls that organizations can adopt and tailor to their own security standards, policies, or concepts.
The goal is to provide a foundation that works for most organizations. In many cases, you may want to adopt only some controls or add others that are more suitable to your specific organization or technology stack.
General
Part A: SSDLC Controls
- A.1 - Secure Dev Environment
- A.2 - Secure Development Process
- A.3 - Security Tests
- A.4 - Outsourced Development
- A.5 - Secure Operation
Part B: Implementation Controls
- B.1 - Secure Design Principles
- B.2 - Input Validation
- B.3 - Secure Fileuploads and Downloads
- B.4 - Output Validation & Encoding
- B.5 - Secure User Registration & Authentication
- B.6 - User Passwords
- B.7 - Secure Session Management
- B.8 - Authorization
- B.9 - Error Handling and Logging
- B.10 - Data Security
- B.11 - Protection of Secrets
- B.12 - API Security
- B.13 - Client-Side Security
- B.14 - HTTP Header Security
Related Standards
Generally, TSS-WEB aims to incorporate requirements from existing standards and best practices in this field that are suitable to establish baseline security. However, that does not mean that every requirement is integrated, particularly those that address edge cases or too specific scenarios.
The following table outlines the coverage of some important standards in this area.
Standard | Coverage |
---|---|
Microsoft SDL (2024) | Full coverage by SSDLC controls. See MS SDL Mapping. |
NIST SSDF 1.1 | NIST SP 800-218, the Secure Software Development Framework (SSDF). See NIST SSDF Mapping. |
SAFECode SSDLC Practices | Requirements-relevant practices are covered. See SAFECode SSDLC Practices Mapping (Draft) |
ISO/IEC 27002:2022 | TSS-WEB implements 14.2.1 control (“Secure Development Policy”) and covers controls 8.24 - 8.31. |
OWASP TOP Ten 2021 | Full coverage by implementation controls. See OWASP Top Ten Mapping. |
OWASP SAMM 2.0 | OWASP SAMM has a different scope and goal but practices related to security requirements should generally be covered. See OWASP SAMM Mapping (Draft). |
Microsoft S2CF | TSS-WEB coveres Practice 2: Scan It as well as Practice 4: Update It, mostly by A.2.6 Securing Third-Party Dependencies at the moment. |
OWASP Top 10 CI/CD Security Risks | Many recommendations are covered, mostly in A.2.5 Secure Build & Deployment and A.1.3 Pipeline Security. However, TSS-WEB is, and will not be, that specific. You may therefore use this resource for additional ideas and best practices, particularly for improving pipeline security. |
Additional notable standards in this field include the BSA Framework for Secure Software (UK) and BSI TR-03185 Sicherer Software-Lebenszyklus (DE}. Additionally, you may want to explore OpenCRE, which provides a comprehensive mapping of ApPSec requirements across a a wide range of standards.
SecTemplates is a similar project that is focused on providing templates for security processes like incident or vulnerability management.
License
The content is licensed under Creative Commons By 4.0 and can therefore be used and changed to individual needs free of charge. The only requirement is proper attribution to the original source and author. Additionally, any adaptations of this content are not required to be released under the same license.
Author
This site is maintained by Secodis GmbH. Responsible for the content is Matthias Rohr.
Thanks
Tanks a lot to Timo Pagel and Christian Schneider for their input!