# Secure Development Lifecycle - Patterns | Patterns Source: https://architect.salesforce.com/docs/architect/well-architected/guide/trust-secure-development-patterns.html > Learn more about Well-Architected # Secure Development Lifecycle - Patterns Learn more about Well-Architected [Trust](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html) → [Secure Development Lifecycle](https://architect.salesforce.com/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. **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 **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 **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 **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 See also: * [Compliance and Regulatory Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-compliance-patterns.html) — Platform governance and audit controls * [Identity and Access Management Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-identity-access-patterns.html) — Authentication and authorization * [Incident Response Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-incident-response-patterns.html) — Security event detection and response * [Agentic Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/trust-agentic-patterns.html) — Agent-specific security controls