TSS-WEB covers most controls of NIST SSDF v1.1, except those that either do not relate to a security requirement or are too specific for a baseline requirement.

Additionally, the general scope of SSDF is slightly different since it addresses security requirements for suppliers of public US institutions, which can be more strict than what most companies can demand from their suppliers. Therefore, from a customer perspective, the respective requirements in TSS-WEB (see A.4 - Outsourced Development) are a little less strict since they aim to provide a set of security requirements that should be commonly acceptable by software suppliers in general.

Prepare the Organization (PO)

Define Security Requirements for Software Development (PO.1)

This is what should be archived by applying TSS-WEB in general.

Implement Roles and Responsibilities (PO.2)

See A.2.1 Roles & Responsibilities.

Implement Supporting Toolchains (PO.3)

Covered from a requirement perspective mostly at A.2.5 Secure Build & Deployment. However, this SSDF requirements also focussed on the general process of selecting and implementing the right tooling which is not covered by TSS-WEB.

Define and Use Criteria for Software Security Checks (PO.4)

Covered from a requirement perspective mostly at A.2.5 Secure Build & Deployment as wel as A.2.6 Securing Third-Party Dependencies.

Implement and Maintain Secure Environments for Software Development (PO.5)

See A.1 - Secure Dev Environment.

Protect the Software (PS)

Protect All Forms of Code from Unauthorized Access and Tampering (PS.1)

Covered by various requirements, including:

Provide a Mechanism for Verifying Software Release Integrity (PS.2)

Code signature verification is required in release process (see A.2.5 Secure Build & Deployment).

Also, provisioning of code signing certificates Integrate code signing is a supplier requirement (see A.4 - Outsourced Development).

Archive and Protect Each Software Release (PS.3)

See requirements at A.2.5 Secure Build & Deployment.

Also covered from a customer perspective at A.4 - Outsourced Development.

Produce Well-Secured Software (PW)

Design Software to Meet Security Requirements and Mitigate Security Risks (PW.1)

Covered by A.2.3 Secure Design.

Review the Software Design to Verify Compliance with Security Requirements and Risk Information (PW.2)

Covered by A.2.3 Secure Design and A.2.7 Security Gates.

Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality (PW.4)

Not covered directly at the moment. This would be usually be enforced in an architecture board that approves new architecture decisions like new technologies (see A.2.7 Security Gates).

Create Source Code by Adhering to Secure Coding Practices (PW.5)

Covered technology agnostic by A.2.4 Secure Implementation; especially be te implementation requirements. In a next step you could derive technology-specific secure coding guidelines from them (e.g. secure coding guidelines for Java EE, python, etc.).

Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security (PW.6)

Security aspects of the build process are covered by A.2.5 Secure Build & Deployment.

Since the scope of TSS-WEB are web-based applications and services, security of executables are not covered here though.

Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.7)

Peer reviews are required in A.2.4 Secure Implementation.

Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements (PW.8)

Not covered by TSS-WEB since its scope are web-based applicaions and services.

Configure Software to Have Secure Settings by Default (PW.9)

Covered by A.5.2 System Hardening.

Respond to Vulnerabilities (RV)

Identify and Confirm Vulnerabilities on an Ongoing Basis (RV.1)

Covered by A.3 - Security Tests.

Assess, Prioritize, and Remediate Vulnerabilities (RV.2)

Analyze Vulnerabilities to Identify Their Root Causes (RV.3)

Covered by A.5.10 Vulnerability Management.