Change past to future

Secure_Developer_Checklist.md

@@ -10,7 +10,7 @@
 
 Use this list as an indicator of _security-notable_ events you may want to refer up to the curator of your product's threat model. If you make a change that impacts the security posture of your product (for example, added a new input vector, opened a new network port, added a new API call, changed conditions for authentication and authorization, added privileged user functionality, etc.), create a ticket for your development work (ex. bug tracking ticket with label, _potential-tm-update_ and describe your change so that the threat model curator can further direct and communicate with other stakeholders.
 
-| If you did THIS … | … then do THAT |
+| If you want to do THIS … | … then do THAT |
 |-------------------|----------------|
 |… added functionality that changes sensitive properties or objects in the system|<ul><li>Protect with authentication - You must make sure that all new functionality is protected with authentication. Validate that an individual, entity or server is who it claims to be by using strong authentication mechanisms like SAML, OAuth, etc.</li><li>Protect with authorization - Authorization enforces what permissions/authority a person has on an entity or operation.</li><li>You must make sure that you exercise least privilege access control policies on all new functionality. You may design for coarse-grained authorization, but keep the design flexible for fine-grained authorization.</li><li>Make sure secrets are not in cleartext - A secret is only as good as how it is protected. When using passwords or cryptographic keys, it is important to keep them protected at all times. Try to minimize the amount of time they are available in memory by scrubbing variables right after use. Do not use hardcoded secrets under any circumstance.</li><li>Exercise least privilege - When deciding the level of privilege needed by a process or service, keep in mind that it should be only as much as that process or service needs. For example, if you are only querying a database, the credentials you are using should not be owned by a user that can write to the database. A process that does not need elevated (root or Administrator) privileges should not be running as root or Administrator.</li><li>Account for all vectors for client bypass - Any logic in the client side of the application is an easy target for attack. Ensure that client-side controls cannot be bypassed by skipping steps of the application, submitting incorrect values, etc.</li></ul>|
 |… created a new process or actor|<ul><li>Exercise least privilege - When deciding the level of privilege needed by a process or service, keep in mind that it should be only as much as that process or service needs. For example, if you are only querying a database, the credentials you are using should not be owned by a user that can write to the database. A process that does not need elevated (root or Administrator) privileges should not be running as root or Administrator.</li><li>Make sure credentials are securely stored Store user credentials as a salted and hashed value in a database. Ensure that a strong hash algorithm and sufficiently random salt is used.</li><li>Exercise appropriate hardening - Harden your system or component (commercial, open source, or inherited from another team), by regularly patching, installing updates, minimizing attack surface, and practicing the principle of least privilege.Minimize the attack surface by reducing the number of entry points into the system. Turn off features, services, and access that is not strictly necessary. Practice the principle of least privilege by providing the lowest amount of access and permissions necessary for a role's function. Audit each of these controls to ensure compliance.</li></ul>|