FAQ-001343 - Package Design and Architecture Security / Security Review Process and Communication

Current Status:SUGGESTS_CASEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
How do different packaging strategies impact security review requirements and how can I discuss complex packaging strategies with the security team?
Answer
Different packaging strategies influence security review requirements in several ways: **Impact of Packaging Strategies on Security Review:** - **Managed Packages**: You need to submit a Developer Edition org with the managed package installed, along with security scan reports like Checkmarx and Dynamic Application Security Test (DAST) results - **Extension Packages**: These require the same materials as standalone solutions. If the base solutions haven't passed security review, both the extension package and the unreviewed base solutions must be submitted - **Solution Architecture**: If your solution includes external web applications, mobile clients, or APIs, the specific materials and tests required for submission will vary accordingly - **Version Strategy**: It's recommended to submit only major and minor versions (e.g., 1.0.0 and 1.1.0) for security review to maximize the inheritance of security review results. Patches have limited security review inheritance, so their use should be minimized in this context **Discussing Complex Packaging Strategies:** To discuss the security implications of a complex or non-standard packaging strategy with the security team, you should raise a detailed support case. Include all relevant information such as: - The specific packaging strategy being used - Potential security concerns you've identified - Any specific questions or challenges you are facing - Supporting documentation like architecture diagrams or design documents This comprehensive approach will help the security team understand the context and provide tailored guidance to address your concerns effectively. **Patch Org Usage:** Patch orgs should not be the primary focus for security review preparation. Focus on major and minor versions instead to ensure maximum benefit from security review inheritance.

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Question
How do different packaging strategies impact security review requirements and how can I discuss complex packaging strategies with the security team?
Recommended Answer Update
Different packaging strategies influence security review requirements in several ways: **Impact of Packaging Strategies on Security Review:** - **Managed Packages**: Submit a Developer Edition org with the managed package installed, along with security scan reports like Checkmarx and Dynamic Application Security Test (DAST) results - **Extension Packages**: These require the same materials as standalone solutions. If the base solutions haven't passed security review, both the extension package and the unreviewed base solutions must be submitted - **Solution Architecture**: If your solution includes external web applications, mobile clients, or APIs, the specific materials and tests required for submission will vary accordingly - **Version Strategy**: Submit only major and minor versions (e.g., 1.0.0 and 1.1.0) for security review to maximize the inheritance of security review results. Patches have limited security review inheritance, so minimize their use in this context **Discussing Complex Packaging Strategies:** To discuss the security implications of a complex or non-standard packaging strategy with the security team, raise a detailed support case. Include all relevant information such as: - The specific packaging strategy being used - Potential security concerns you've identified - Any specific questions or challenges you're facing - Supporting documentation like architecture diagrams or design documents This comprehensive approach will help the security team understand the context and provide tailored guidance to address your concerns effectively. **Patch Org Usage:** Focus on major and minor versions instead of patch orgs for security review preparation to ensure maximum benefit from security review inheritance.
Reasoning
The FAQ content is accurate and well-structured, covering packaging strategies and their security review requirements. I made several refinements to improve clarity and tone: 1. Streamlined language to be more direct and conversational (removed "You need to" and replaced with direct instructions) 2. Simplified the version strategy explanation by removing redundant phrasing ("It's recommended to" became a direct statement) 3. Made the support case guidance more actionable by changing "you should raise" to "raise" 4. Condensed the patch org section to eliminate redundancy while preserving the key message 5. Maintained all original technical content and structure while improving readability No security rules were selected because this FAQ discusses the administrative and procedural aspects of security review submission rather than specific coding practices or security vulnerabilities that would be detected by static analysis tools. The content focuses on packaging strategy decisions, submission requirements, and communication processes with the security team - topics that are outside the scope of automated security scanning rules.