Mapping of SAFECode Practices for Secure Software Development (Draft)
SAFECode’s Fundamental Practices for Secure Software Development from 2018 are a collection of best practices for securing software development.
TSS-WEB addresses the requirement-relevant aspects of these practices. However, many of the practices are more specialized, focusing on general vulnerability management or organizing AppSec programs, and are therefore not covered.
Application Security Control Definition
Covered as definition of application security architecture (see A.2.3 Secure Design).
Actively Manage Application Security Controls
Not covered that explicitely in the sense of a full Application Development Lifecycle Management (ADLM) as SAFEcode defines it yet.
- Definition of application security architecture (see A.2.3 Secure Design)
- its approval in the architecture gate (see A.2.7 Security Gates)
- Assess Security of New Features (see A.2.3 Secure Design)
TODO: Should be checked if this requiremend is covered.
Design
Secure Design Principles
See B.1 - Secure Design Principles.
Threat Modeling
See A.2.3 Secure Design.
Develop an Encryption Strategy
Requriements are covered in B.10 - Data Security.
A full encryption strategy would be outside of the scope of TSS-WEB though.
Standardize Identity and Access Management
Implicitly covered:
- As implementation requirements: B.8 - Authorization
- As to use standardized technologies in general: A.2.3 Secure Design.
Establish Log Requirements and Audit Practices
- Log Requirements: B.9 - Error Handling and Logging
- Audit Practices: A.5.8 Security Monitoring and Alerting
Secure Coding Practices
Establish Coding Standards and Conventions
Not covered.
TSS-WEB only coveres implementation requirements in Part B: Secure Implementation Controls from which technology-specific coding guidelines or standards can be derived.
Use Safe Functions Only
Covered in A.2.3 Secure Design.
Use Code Analysis Tools to Find Security Issues Early
Covered in A.3.3 Automated Security Scans.
Handle Data Safely
Covered in B.10 - Data Security.
Handle Errors
Covered in B.9 - Error Handling and Logging.
Manage Security Risk Inherent in the Use of Third-party Components
See A.2.6 Securing Third-Party Dependencies.
Testing and Validation
Covered in A.3 - Security Tests.
Automated Testing
Covered in A.3.3 Automated Security Scans.
Manual Testing
Abuse case testing is covered in A.3.4 - Custom Security Tests.
Manage Security Findings
Covered in A.3.2 Handling Security Findings.
Define Severity
Dfined in release gate A.2.7 Security Gates.
Risk Acceptance Process
Risk acceptance is referenced in
- Release Gate: A.2.7 Security Gates
- Operatational Security: A.5.10 Vulnerability Management
Vulnerability Response and Disclosure
Define Internal and External Policies
Should be covered within a seperate vulnerability management standard / process.
Define Roles and Responsibilities
Covered in Roles.
Ensure that Vulnerability Reporters Know Whom to Contact
Should be covered within a seperate vulnerability management standard / process.
Manage Vulnerability Reporters
Should be covered within a seperate vulnerability management standard / process.
Monitor and Manage Third-party Component Vulnerabilities
Covered in A.2.6 Securing Third-Party Dependencies.
Fix the Vulnerability
Covered in A.5.10 Vulnerability Management and A.3.2 Handling Security Findings.
Vulnerability Disclosure
Not covered (yet).
Is only relevant for external development and therefore too specific control.
Secure Development Lifecycle Feedback
Planning the Implementation and Deployment of Secure Development Practices
Covered in A.2.4 Secure Implementation.
Culture of the Organization
Not in scope.
Expertise and Skill Level of the Organization
Not in scope.
Product Development Model and Lifecycle
Covered in A.2 - Secure Development Process.
Scope of Initial Deployment
Not in scope.
Stakeholder Management and Communications
Not in scope.
Compliance Measurement
Not in scope.
SDL Process Health
Not in scope.
Value Proposition
Not in scope.