FAQ-000749 - Deprecated Component Security Assessment / Documentation and False Positive Handling

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
What documentation is needed to demonstrate that deprecated components don't pose actual security risks, and can I use false positive documentation for this purpose?
Answer
To show that deprecated components don't pose security risks in the AppExchange Security Review, you can use false positive documentation. Here's what you need to provide: **For General Deprecated Components:** - Explains the functionality and current state of the deprecated components - Details why they are no longer in use and how they are isolated or disabled - Describes measures taken to ensure they don't introduce vulnerabilities - Includes security scan reports and explanations for any false positives, if applicable **For Detailed False Positive Documentation:** 1. **Component Details**: Identify the deprecated component, including its name, purpose, and location in the package 2. **Reason for Deprecation**: Explain why the component is deprecated and why it cannot be removed (e.g., dependencies, backward compatibility) 3. **Security Assessment**: Provide evidence that the component does not pose a security risk, such as: - Confirmation that it is no longer in use - Details on how it is isolated or inaccessible to external users - Mitigations in place to prevent misuse 4. **Code Review**: Include a review of the component's code to show it has no vulnerabilities or sensitive data 5. **Supporting Documentation**: Attach relevant references like security review findings, Checkmarx or ZAP scan reports, and other evidence 6. **Future Plans**: If applicable, outline plans for eventual removal or replacement in future package versions **Acceptable Use Cases:** - Yes, it is acceptable to document deprecated sensitive fields in false positive documentation - Yes, you can use a false positive document to address a public custom metadata field that is no longer in use but cannot be modified - The document should include a detailed explanation of why the field is no longer utilized and relevant case information or justifications **Important Exception:** - Unused weblinks should not be documented as false positives. Instead, it is recommended to remove them through patches to ensure they do not pose any potential security risks **Key Differences:** - **Deprecated Objects**: Components or settings no longer actively supported but not considered active security vulnerabilities, though they still need review - **Actual Security Vulnerabilities**: Identified issues that could threaten integrity, confidentiality, or availability and must be addressed to pass review Make sure the document is clear, concise, and includes screenshots or examples if needed. Submit this as part of the security review process.

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
AvoidJavaScriptWebLinkAvoidJavaScriptCustomObjectAvoidJavaScriptHomePageComponentAvoidJavaScriptInUrlsAvoidSControls
Question
What documentation is needed to demonstrate that deprecated components don't pose actual security risks, and can I use false positive documentation for this purpose?
Recommended Answer Update
To show that deprecated components don't pose security risks in the AppExchange Security Review, you can use false positive documentation. Here's what you need to provide: **For General Deprecated Components:** - Explains the functionality and current state of the deprecated components - Details why they are no longer in use and how they are isolated or disabled - Describes measures taken to ensure they don't introduce vulnerabilities - Includes security scan reports and explanations for any false positives, if applicable **For Detailed False Positive Documentation:** 1. **Component Details**: Identify the deprecated component, including its name, purpose, and location in the package 2. **Reason for Deprecation**: Explain why the component is deprecated and why it can't be removed (e.g., dependencies, backward compatibility) 3. **Security Assessment**: Provide evidence that the component doesn't pose a security risk, such as: - Confirmation that it's no longer in use - Details on how it's isolated or inaccessible to external users - Mitigations in place to prevent misuse 4. **Code Review**: Include a review of the component's code to show it has no vulnerabilities or sensitive data 5. **Supporting Documentation**: Attach relevant references like security review findings, Checkmarx or ZAP scan reports, and other evidence 6. **Future Plans**: If applicable, outline plans for eventual removal or replacement in future package versions **Acceptable Use Cases:** - Yes, it's acceptable to document deprecated sensitive fields in false positive documentation - Yes, you can use a false positive document to address a public custom metadata field that's no longer in use but can't be modified - The document should include a detailed explanation of why the field's no longer utilized and relevant case information or justifications **Important Exception:** - Unused weblinks shouldn't be documented as false positives. Instead, it's recommended to remove them through patches to ensure they don't pose any potential security risks **Key Differences:** - **Deprecated Objects**: Components or settings no longer actively supported but not considered active security vulnerabilities, though they still need review - **Actual Security Vulnerabilities**: Identified issues that could threaten integrity, confidentiality, or availability and must be addressed to pass review Make sure the document's clear, concise, and includes screenshots or examples if needed. Submit this as part of the security review process.
Reasoning
The main changes focus on improving the conversational tone per the brand guidelines by using contractions throughout (can't instead of cannot, it's instead of it is, shouldn't instead of should not, etc.) and making the language more natural and direct. The content remains substantively the same with all original points preserved, but the phrasing is now more conversational and user-friendly while maintaining the professional security guidance. The related security rules were selected because they all deal with deprecated components that commonly appear in AppExchange packages: AvoidJavaScriptWebLink directly relates to the FAQ's specific mention of weblinks that should be removed rather than documented as false positives. AvoidJavaScriptCustomObject, AvoidJavaScriptHomePageComponent, and AvoidJavaScriptInUrls all detect deprecated JavaScript-based components that are commonly flagged in security reviews and would need the type of false positive documentation described in this FAQ. AvoidSControls detects S-Controls, which are deprecated Salesforce components that frequently require false positive documentation when they cannot be removed due to backward compatibility requirements.
Reasoning References