--- schema_version: "1" id: 55c1c0ad828c80ca191e7316c445039480c35ba1fd683de0d655b03f0cb19403 title: Secure Development Lifecycle - Patterns collection: architect version: next locale: en-us portal_url: https://docs.salesforce.com/architect/next/en-us/well-architected/guides/trust-secure-development-patterns.md canonical_url: https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-secure-development-patterns.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 794c49576364151f57c169e2defae92c4ed2a77f333a3041ba2825e921e915b1 products: - Well-Architected Framework - Architect Site Content Repo --- # Secure Development Lifecycle - Patterns Learn more about Well-Architected [Trust](/docs/architect/well-architected/guide/trust.html) → [Secure Development Lifecycle](/docs/architect/well-architected/guide/trust.html#secure-development-lifecycle) Security must be integrated throughout the development lifecycle, from initial design to deployment and operations. These patterns enable shift-left security practices, address common vulnerabilities, and secure your deployment pipelines. ## Shift-Left Security **Patterns** | Where to look | What good looks like | | --- | --- | | Development \| Tooling | ✅ IDE security scanning integrated into developer workflow | | Development \| Design | ✅ Threat modeling completed during design phase using STRIDE methodology | | Development \| Requirements | ✅ Security requirements included in user stories and acceptance criteria | | Development \| Source Control | ✅ Pre-commit hooks enforce security policies (secret scanning, code analysis) | | Development \| Training | ✅ Developer security training refreshed regularly to reflect evolving threats | | Development \| CI/CD | ✅ Automated security testing in CI/CD pipeline fails builds on critical findings | | Development \| Code Review | ✅ Security peer reviews required for authentication, authorization, and data access code | | Development \| Code Analysis | ✅ Secure coding standards enforced through linters and static analysis | | Development \| Dependencies | ✅ Dependency vulnerability scanning runs on every commit | | Development \| Testing | ✅ Penetration testing scope includes new features before GA release | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Development \| Testing | ⚠️ Security testing deferred to manual review before release | | Development \| Training | ⚠️ Security training conducted once during onboarding only | | Development \| Code Review | ⚠️ Security team reviews code after merge | | Development \| Design | ⚠️ Threat models not updated when architecture changes | | Development \| Source Control | ⚠️ Secret scanning disabled to reduce false positives | | Development \| CI/CD | ⚠️ Security findings ignored when release deadlines loom | ## OWASP Top 10 for Salesforce **Patterns** | Where to look | What good looks like | | --- | --- | | Injection | ✅ SOQL queries use bind variables to prevent injection | | Injection | ✅ User input validated and sanitized before use in SOQL, SOSL, or dynamic queries | | Injection | ✅ Dynamic SOQL restricted to trusted inputs only | | Access Control | ✅ CRUD and FLS permissions enforced using Security.stripInaccessible() | | XSS | ✅ Lightning components escape user-generated content in UI rendering | | Injection | ✅ External API integrations validate and sanitize all inputs | | Access Control | ✅ Guest user access minimized and heavily restricted | | Authentication | ✅ Named credentials used for external authentication (not hardcoded credentials) | | Authentication | ✅ OAuth 2.0 flows implemented correctly with PKCE | | Session Management | ✅ Session security policies enforce timeout and IP restrictions | | Configuration | ✅ Security Health Check reviewed quarterly and high-risk findings remediated | | Access Control | ✅ Custom metadata and permissions audited to prevent over-privileging | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Injection | ⚠️ SOQL queries constructed using string concatenation with user input | | Access Control | ⚠️ Guest user profiles granted Create, Update, or Delete permissions | | XSS | ⚠️ Lightning components use unescaped expressions in templates | | Authentication | ⚠️ External integrations use hardcoded credentials in code | | Logging | ⚠️ Debug logs contain sensitive data like passwords or PII | | Access Control | ⚠️ FLS and CRUD checks omitted because "we control all the users" | | Configuration | ⚠️ Security Health Check findings ignored or postponed indefinitely | ## Secure Pipeline Design **Patterns** | Where to look | What good looks like | | --- | --- | | Pipeline \| Source Control | ✅ Branch protection rules enforce required reviews and status checks | | Pipeline \| Access Control | ✅ Deployment pipelines use service accounts with minimal required permissions | | Pipeline \| Secrets | ✅ Secrets stored in secure vaults (never in source control or environment variables) | | Pipeline \| Deployment | ✅ Production deployments require manual approval gate from authorized personnel | | Pipeline \| Auditing | ✅ Deployment logs capture who deployed what when with approval trails | | Pipeline \| Validation | ✅ Pre-deployment validation includes security scans and compliance checks | | Pipeline \| Access Control | ✅ Multi-factor authentication required for pipeline administrative access | | Pipeline \| Monitoring | ✅ Pipeline configuration changes trigger security team notifications | | Pipeline \| Validation | ✅ Automated post-deployment validation confirms expected security controls active | | Pipeline \| Dependencies | ✅ Dependency updates evaluated for security impact before deployment | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Pipeline \| Secrets | ⚠️ Secrets committed to version control (even if later removed) | | Pipeline \| Source Control | ⚠️ Anyone can merge to main/production branch without review | | Pipeline \| Access Control | ⚠️ Deployment pipelines run with admin-level permissions | | Pipeline \| Deployment | ⚠️ Production deployments fully automated with no approval gates | | Pipeline \| Auditing | ⚠️ Deployment logs don't capture who initiated or approved changes | | Pipeline \| Validation | ⚠️ Failed security scans ignored or bypassed to meet deadlines | | Pipeline \| Monitoring | ⚠️ Pipeline configuration changes not tracked or reviewed | | Pipeline \| Validation | ⚠️ Post-deployment validation only checks functional correctness | ## Security Testing Strategy **Patterns** | Where to look | What good looks like | | --- | --- | | Testing \| Static Analysis | ✅ Salesforce Code Analyzer run in developer IDEs for immediate feedback and in CI/CD pipelines as automated gates | | Testing \| Penetration Testing | ✅ Penetration testing conducted for custom applications exposed to untrusted users, especially Experience Cloud sites and public-facing APIs | | Testing \| Unit Tests | ✅ Security-focused Apex unit tests run as users with different permission profiles | | Testing \| Dependencies | ✅ Dependency scanning monitors AgentExchange packages and JavaScript libraries for known vulnerabilities | | Testing \| Security Review | ✅ Static analysis report prepared for every AppExchange or AgentExchange Security Review submission | | Testing \| Security Review | ✅ Dynamic scan (penetration test) report prepared when a solution integrates a third-party web application or service | | Testing \| Dependencies | ✅ Security advisories for installed packages subscribed to and monitored | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Testing \| Coverage | ⚠️ Security testing relies on a single technique such as static analysis alone | | Testing \| Unit Tests | ⚠️ Apex tests validate functional behavior but never run as lower-privilege users | | Testing \| Security Review | ⚠️ AppExchange or AgentExchange submission prepared without the required static analysis or dynamic scan reports | | Testing \| Penetration Testing | ⚠️ Penetration testing skipped for public-facing Experience Cloud sites and APIs | ## Related Patterns See also: - [Compliance and Regulatory Patterns](https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-compliance-patterns.md) — Platform governance and audit controls - [Identity and Access Management Patterns](https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-identity-access-patterns.md) — Authentication and authorization - [Incident Response Patterns](https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-incident-response-patterns.md) — Security event detection and response - [Agentic Patterns](https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-agentic-patterns.md) — Agent-specific security controls