This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:
economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
least privilege (processes should operate with the least privilege necessary)
least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)
limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
input validation with allowlists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values)).
A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer. Many books and courses are available to help you understand how to develop more secure software and discuss design. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more secure software (it's free if you audit it; for an extra fee you can earn a certificate to prove you learned the material).
This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder: economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications) fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default) complete mediation (every access that might be limited must be checked for authority and be non-bypassable) open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords) separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication) least privilege (processes should operate with the least privilege necessary) least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files) psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help) limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited) input validation with allowlists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values)). A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer. Many books and courses are available to help you understand how to develop more secure software and discuss design. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more secure software (it's free if you audit it; for an extra fee you can earn a certificate to prove you learned the material).