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.

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:

Establish Log Requirements and Audit Practices

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

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.