Secure Development Lifecycle - Patterns

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.

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