Develop and acquire Technology Assets, Applications and Services (TAAS) through secure-by-design, risk-informed and resilient lifecycle practices.
Organizations integrate security, compliance and resilience requirements into internally developed and acquired TAAS, including secure development practices, acquisition due diligence, supplier requirements, validation, acceptance criteria and least privilege/least functionality expectations.
Organizations introduce vulnerabilities into their own environments when they develop software or acquire TAAS without integrating security requirements into those processes. The TDA domain governs secure-by-design development practices and security requirements for acquisition, including due diligence on acquired technology, supplier security requirements, validation processes and acceptance criteria.
The SCF's intent for TDA applies least privilege and least functionality to developed and acquired TAAS. That means software should ship with the minimum functionality required, not with a maximal feature set that creates attack surface. Acquired technology should be evaluated for security posture before deployment, not assumed to be secure because a vendor says it is.
TDA connects to Third-Party Management (TPM) but addresses a different relationship. TPM governs ongoing management of third-party vendors that deliver products and services. TDA governs the development and acquisition process itself, including the security requirements built into what gets developed or purchased. Acquisition due diligence is a TDA control; ongoing supplier performance monitoring is a TPM control.
%20(white).png)
.png)