Learn more about Well-Architected Trust → 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 — Platform governance and audit controls
- Identity and Access Management Patterns — Authentication and authorization
- Incident Response Patterns — Security event detection and response
- Agentic Patterns — Agent-specific security controls