The principles described—using only tested and approved components and utilizing task-specific, built-in APIs for operating system functions—are foundational rules for writing secure code. These practices are not confined to a single security domain like sessions or authentication. Instead, they represent overarching guidelines that apply throughout the development lifecycle to minimize vulnerabilities. They fall under the broad category of "General Coding Practices," which aims to prevent common flaws like injection attacks (by using safe APIs) and vulnerabilities from third-party libraries.

A. Session Management: This practice focuses on securely maintaining a user's state and interaction with an application, not on component selection or OS-level API usage.

B. Authentication and Password Management: This area deals with verifying user identities and protecting credentials, which is distinct from the principles of code construction and library usage.

C. Data Protection: This concerns the security of data itself, such as through encryption and access controls, not the underlying code components or system call mechanisms.

---

1. OWASP Top 10 2021, A06:2021 – Vulnerable and Outdated Components. This standard directly addresses the first principle mentioned in the question. It states, "If you don’t know the vulnerabilities of the components you use, you are at risk... This is a broad category that represents the known #2 in the Top 10 community survey." This highlights using vetted components as a fundamental, general practice.

Source: OWASP Foundation, "OWASP Top 10 2021," A06:2021. Available at: https://owasp.org/Top10/A062021-VulnerableandOutdatedComponents/

2. NIST Special Publication (SP) 800-218, Secure Software Development Framework (SSDF) Version 1.1. The practice PW.5 states, "Reuse existing, well-secured software when feasible instead of duplicating functionality." This supports the use of tested components. The framework categorizes this under "Produce Well-Secured Software (PW)," which encompasses general coding and development practices.

Source: NIST SP 800-218, Section 3.3, Table 2, Practice PW.5. Available at: https://doi.org/10.6028/NIST.SP.800-218

3. CERT C Coding Standard, ENV33-C. Do not call system(). This standard explains that using the system() function is dangerous because it can lead to command injection. It recommends using library functions that accomplish the specific task directly. This rule is a prime example of a general secure coding practice related to using task-specific APIs instead of broad OS command interpreters.

Source: Carnegie Mellon University, Software Engineering Institute, "CERT C Coding Standard," Rule ENV33-C. Available at: https://wiki.sei.cmu.edu/confluence/display/c/ENV33-C.+Do+not+call+system