From an application developer’s perspective, the further “down” in the diagram a security concern appears the more “invisible” or effort-free it is. Features the developer must add themselves must be 1) carefully considered for their implementation’s correctness, 2) correct configuration and use, and 3) thorough and consistent use. At first glance, developers prefer APIs, frameworks, and shared libraries because they only consider concerns #2 and #3. Their application may be automatic because of inheritance, the template pattern, or similar scheme. In these cases, the developer can skip concern #3. However, these situations assume the called component’s developer tackled #1: implementation correctness. If property #1 fails the developer they’re often hard-pressed to fix the situation as compared to that which they implemented in their code. Trade-offs.
Remember these properties as you write your checklist. Those responsibilities borne by developers must be checked for 1) implementation correctness, 2) correct configuration and use, and 3) consistent and thorough usage.
Responsibilities in APIs, frameworks, and shared services should be 1) audited once for correctness and, when used, 2) audited for appropriateness, 3) correct configuration and use, and if applied on a discretionary basis, 4) audited for consistent and thorough use. Platform properties and features require the same checks.