FAQ-000748 - Deprecated Component Security Assessment / Deprecated Component Management

To handle security findings related to deprecated components still in your managed package: 1. **Remove the Components**: If they're no longer in use, remove them from the package entirely. This is the most effective approach for deprecated custom metadata components and other unused elements. 2. **Eliminate Referencing Code**: Remove any code referencing these components from Visualforce pages, Apex classes, or other areas. Avoid simply commenting out the code as this isn't sufficient to mitigate security risks. 3. **Use Secure Alternatives**: Replace deprecated functionality with supported and secure alternatives, like protected metadata objects or updated APIs. 4. **Handle Specific Security Issues**: For deprecated attributes flagged for passing access tokens in the UI: - Use proper encryption to secure the tokens - Store encryption keys in protected custom metadata or protected custom settings - Ensure access tokens aren't exposed in the UI or logs - If token length exceeds storage limits, encrypt the token and store it in a custom object 5. **Mark as Deprecated**: If components can't be removed due to platform limitations, clearly mark the attributes as deprecated and ensure they're no longer referenced or used in the code. 6. **Document Issues**: If flagged issues are false positives, validate and document them in a false positive document with detailed explanations and supporting evidence for review. 7. **Run Security Scans**: Perform updated security scans and address any findings related to the deprecated functionality. 8. **Follow Guidelines**: If the attribute is part of a managed package, follow Salesforce's guidelines for managed component deprecation to maintain compatibility across versions. This approach ensures your package remains secure and compliant while addressing various types of deprecated component scenarios.

The main improvement needed was to make the language more conversational and direct, following the brand guidelines. Changed formal constructions like 'are not in use' to 'aren't in use' and 'cannot be removed' to 'can't be removed', and 'are not exposed' to 'aren't exposed'. These changes make the FAQ sound more like helpful advice from a knowledgeable colleague rather than enterprise documentation. The technical content and structure remain unchanged. I recommended the ApexBadCrypto rule because the FAQ specifically discusses encryption of access tokens in point 4: 'Use encryption to secure the tokens' and 'encrypt the token and store it in a custom object'. The ApexBadCrypto rule is designed to detect inadequate cryptographic implementations in Apex code, which directly relates to the FAQ's guidance on properly encrypting sensitive token data when handling deprecated components that expose access tokens.