FAQ-000733 - Data Storage and Encryption Security / Vulnerability Identification and Remediation

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should developers challenge false positive findings for insecure storage vulnerabilities?
Answer
To challenge false positive findings for insecure storage vulnerabilities in Salesforce, developers should: 1. **Prepare a False Positive Document**: Include detailed justifications and references explaining why the reported issue is invalid. For example, if sensitive data (e.g., `client_API_ID`) is non-critical or encrypted with a key stored in protected custom settings, document this clearly. 2. **Ensure Secure Storage**: Verify that sensitive data (e.g., `client_secret_key`) is securely stored in protected custom settings. 3. **Remove Unused Code**: If the flagged code is no longer in use, remove it from the package or provide evidence of its irrelevance. 4. **Submit Documentation**: Use the appropriate case or partner portal to submit the false positive document for review and resolution. This process ensures a thorough review and helps address any misunderstandings.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
AvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInVarDeclsApexSuggestUsingNamedCred
Question
How should developers challenge false positive findings for insecure storage vulnerabilities?
Recommended Answer Update
To challenge false positive findings for insecure storage vulnerabilities in Salesforce, developers should: 1. **Prepare a False Positive Document**: Include detailed justifications and references explaining why the reported issue is invalid. For example, if sensitive data (e.g., `client_API_ID`) is non-critical or encrypted with a key stored in protected custom settings, document this clearly. 2. **Ensure Secure Storage**: Verify that sensitive data (e.g., `client_secret_key`) is securely stored in protected custom settings or Named Credentials. 3. **Remove Unused Code**: If the flagged code is no longer in use, remove it from the package or provide evidence of its irrelevance. 4. **Submit Documentation**: Use the appropriate case or partner portal to submit the false positive document for review and resolution. This process ensures a thorough review and helps address any misunderstandings.
Reasoning
I made minimal changes to improve specificity while preserving all existing points. The only update was adding 'or Named Credentials' to recommendation #2 to align with current Salesforce security best practices for credential storage. I selected four related security rules that directly correspond to the types of insecure storage vulnerabilities this FAQ addresses: AvoidHardcodedCredentialsInFieldDecls relates to the FAQ's discussion of sensitive data like `client_secret_key` stored in field declarations; AvoidHardcodedCredentialsInVarAssign and AvoidHardcodedCredentialsInVarDecls correspond to the FAQ's examples of `client_API_ID` and similar credentials that might be flagged in variable assignments and declarations; ApexSuggestUsingNamedCred directly relates to the FAQ's recommendation for secure storage solutions, as this rule suggests using Named Credentials instead of hardcoded credentials. These rules represent the exact types of vulnerabilities developers would encounter and need to challenge as false positives when following this FAQ's guidance.
Reasoning References