FAQ-000379 - Code Removal and Vulnerability Persistence / Sensitive Data Removal

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How do I ensure complete removal of sensitive data storage violations and references?
Answer
To ensure complete removal of sensitive data storage violations and references: **For Field References:** 1. **Remove References in Code**: Eliminate all references to the sensitive data fields from Apex code, including any logic or operations involving these fields 2. **Check UI Elements**: Verify that the fields are not used in Visualforce pages, Lightning components, or other user interface elements 3. **Update Metadata**: Ensure the fields are not included in any metadata, such as custom objects or layouts 4. **Review Debug Logs**: Check debug logs to confirm that no sensitive data fields are logged or referenced 5. **Run Security Scans**: Perform a comprehensive scan of the codebase using security tools to identify any lingering references 6. **Document Changes**: Provide a detailed explanation in the false positive document, if applicable, to demonstrate compliance during the security review **For Storage Violations:** 1. **Use Protected Storage**: Store sensitive data in protected custom metadata or protected custom settings. Avoid unprotected locations 2. **Encrypt Sensitive Data**: Use encryption mechanisms like named credentials, encrypted fields, or the Crypto API to encrypt sensitive data before storing it 3. **Avoid Logging Sensitive Data**: Do not log sensitive data, passwords, keys, or stack traces in production environments. Redact or omit such data from logs 4. **Perform Thorough Testing**: Conduct manual testing and use tools like Salesforce Code Analyzer and Source Code Scanner to identify and address violations 5. **Follow Secure Coding Standards**: Adhere to secure coding practices, such as avoiding insecure storage of sensitive data and following enterprise security guidelines **For Managed Packages:** 1. **Encrypt Sensitive Fields**: Use encryption for sensitive fields and store the encryption key in a protected custom setting object 2. **Create Separate Encrypted Fields**: Instead of reusing existing fields, create new fields specifically for storing encrypted values 3. **Implement Triggers for Encryption**: Add triggers to encrypt sensitive data before insertion and decrypt it when needed 4. **Deprecate Unused Fields**: Deprecate sensitive fields that are no longer required 5. **Test and Validate**: Use security tools to identify and address vulnerabilities, then rescan after making changes These steps will help mitigate risks and improve your chances of passing the security review.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ProtectSensitiveDataAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInVarAssignApexSuggestUsingNamedCredApexBadCrypto
Question
How do I ensure complete removal of sensitive data storage violations and references?
Recommended Answer Update
To ensure complete removal of sensitive data storage violations and references: **For Field References:** 1. **Remove References in Code**: Eliminate all references to the sensitive data fields from Apex code, including any logic or operations involving these fields 2. **Check UI Elements**: Verify that the fields aren't used in Visualforce pages, Lightning components, or other user interface elements 3. **Update Metadata**: Ensure the fields aren't included in any metadata, such as custom objects or layouts 4. **Review Debug Logs**: Check debug logs to confirm that no sensitive data fields are logged or referenced 5. **Run Security Scans**: Perform a comprehensive scan of the codebase using security tools to identify any lingering references 6. **Document Changes**: Provide a detailed explanation in the false positive document, if applicable, to demonstrate compliance during the security review **For Storage Violations:** 1. **Use Protected Storage**: Store sensitive data in protected custom metadata or protected custom settings. Avoid unprotected locations 2. **Encrypt Sensitive Data**: Use encryption mechanisms like named credentials, encrypted fields, or the Crypto API to encrypt sensitive data before storing it 3. **Avoid Logging Sensitive Data**: Don't log sensitive data, passwords, keys, or stack traces in production environments. Redact or omit such data from logs 4. **Perform Thorough Testing**: Conduct manual testing and use tools like Salesforce Code Analyzer and Source Code Scanner to identify and address violations 5. **Follow Secure Coding Standards**: Adhere to secure coding practices, such as avoiding insecure storage of sensitive data and following enterprise security guidelines **For Managed Packages:** 1. **Encrypt Sensitive Fields**: Use encryption for sensitive fields and store the encryption key in a protected custom setting object 2. **Create Separate Encrypted Fields**: Instead of reusing existing fields, create new fields specifically for storing encrypted values 3. **Implement Triggers for Encryption**: Add triggers to encrypt sensitive data before insertion and decrypt it when needed 4. **Deprecate Unused Fields**: Deprecate sensitive fields that are no longer required 5. **Test and Validate**: Use security tools to identify and address vulnerabilities, then rescan after making changes These steps will help mitigate risks and improve your chances of passing the security review.
Reasoning
Minor improvements were made to align with the brand and tone guidelines by making the language more conversational and direct. Changed 'Do not log' to 'Don't log' to use contractions as specified in the guidelines. Changed 'are not used' to 'aren't used' and 'are not included' to 'aren't included' for consistency with the conversational tone requirements. These changes maintain all existing content while making the tone more approachable and aligned with the guidelines. Regarding the security rules selected: - ProtectSensitiveData: This rule directly relates to the FAQ's core topic of removing sensitive data storage violations, which is exactly what the entire FAQ addresses - AvoidHardcodedCredentialsInFieldDecls: Relates to the FAQ's discussion of removing sensitive data field references and storing sensitive data securely - AvoidHardcodedCredentialsInVarDecls: Connects to the FAQ's guidance on eliminating references to sensitive data in code and avoiding insecure storage - AvoidHardcodedCredentialsInVarAssign: Applies to the FAQ's recommendations about removing code references to sensitive data and secure coding practices - ApexSuggestUsingNamedCred: Directly referenced in the FAQ's recommendation to 'use encryption mechanisms like named credentials' - ApexBadCrypto: Relates to the FAQ's guidance on using proper encryption mechanisms and the Crypto API for sensitive data
Reasoning References