--- schema_version: "1" id: bd24da89d1a4dc78a36c6a56bf26000a1900720ac7dcb1793f3679eabca0de34 title: Ciclo de vida seguro de desenvolvimento – Padrões collection: architect version: current locale: pt-br portal_url: https://docs.salesforce.com/architect/current/pt-br/well-architected/guides/trust-secure-development-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-secure-development-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 5a4a0a0f1922c86b76b5cb3fdce13fc8eb12420f76025ed9de92a155ad9c876e products: - Estrutura bem arquitetada - Architect Site Content Repo --- # Ciclo de vida seguro de desenvolvimento – Padrões Saiba mais sobre Well-Architected [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) → Ciclo de vida do [desenvolvimento seguro](/docs/architect/pt-br/well-architected/guide/trust.html#secure-development-lifecycle) A segurança deve ser integrada em todo o ciclo de vida do desenvolvimento, do design inicial até a implantação e operações. Esses padrões habilitam práticas de segurança de turno à esquerda, corrigem vulnerabilidades comuns e protegem seus pipelines de implementação. ## Segurança de turno esquerdo **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Desenvolvimento \| Conjunto de ferramentas | ✅ Verificação de segurança do IDE integrada ao fluxo de trabalho do desenvolvedor | | Desenvolvimento \| Design | ✅ Modelagem de ameaças concluída durante a fase de design usando a metodologia STRIDE | | Desenvolvimento \| Requisitos | ✅ Requisitos de segurança incluídos em histórias de usuário e critérios de aceitação | | Desenvolvimento \| Controle de origem | ✅ Ganchos pré-confirmação aplicam políticas de segurança (escaneamento secreto, análise de código) | | Desenvolvimento \| Treinamento | ✅ Treinamento de segurança do desenvolvedor atualizado regularmente para refletir ameaças em evolução | | Desenvolvimento \| CI/CD | ✅ O teste de segurança automatizado no pipeline CI/CD falha com base em descobertas críticas | | Desenvolvimento \| Revisão de código | ✅ Análises de colegas de segurança exigidas para autenticação, autorização e código de acesso a dados | | Desenvolvimento \| Análise de código | ✅ Padrões de codificação seguros impostos por meio de linters e análise estática | | Desenvolvimento \| Dependências | ✅ A verificação de vulnerabilidade de dependência é executada em cada confirmação | | Desenvolvimento \| Testes | ✅ O escopo de teste de penetração inclui novos recursos antes da versão GA | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Desenvolvimento \| Testes | Teste de segurança adiado para revisão manual antes da versão | | Desenvolvimento \| Treinamento | ⚡️ Treinamento de segurança realizado apenas uma vez durante a integração | | Desenvolvimento \| Revisão de código | ⚡️ A equipe de segurança revisa o código após a mesclagem | | Desenvolvimento \| Design | ⚡️ Modelos de ameaças não atualizados quando a arquitetura muda | | Desenvolvimento \| Controle de origem | ⚡️ Verificação secreta desabilitada para reduzir falsos positivos | | Desenvolvimento \| CI/CD | ⚡️ As descobertas de segurança ignoradas quando os prazos da versão chegam | ## Principais 10 OWASP para Salesforce **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Injeção | ✅ Consultas SOQL usam variáveis bind para evitar injeção | | Injeção | ✅ Entrada do usuário validada e limpa antes de usar em consultas SOQL, SOSL ou dinâmicas | | Injeção | ✅ SOQL dinâmico restrito apenas a entradas confiáveis | | Controle de acesso | ✅ Permissões CRUD e FLS impostas usando Security.stripInaccessible() | | XSS | ✅ Componentes do Lightning escapam conteúdo gerado pelo usuário na renderização da IU | | Injeção | ✅ Integrações de API externas validam e limpam todas as entradas | | Controle de acesso | ✅ Acesso do usuário convidado minimizado e fortemente restrito | | Autenticação | ✅ Credenciais nomeadas usadas para autenticação externa (não credenciais embutidas em código) | | Autenticação | ✅ Fluxos do OAuth 2.0 implementados corretamente com a PKCE | | Gerenciamento de sessão | ✅ As políticas de segurança da sessão impõem restrições de tempo limite e IP | | Configuração | ✅ Verificação de integridade de segurança revisada trimestralmente e descobertas de alto risco remediadas | | Controle de acesso | ✅ Metadados e permissões personalizados auditados para evitar privilégios excedentes | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Injeção | Consultas SOQL criadas usando concatenação de string com entrada do usuário | | Controle de acesso | Perfis de usuário convidado com as permissões Criar, Atualizar ou Excluir concedidas | | XSS | Componentes do Lightning usam expressões não escapadas em modelos | | Autenticação | ⚡️ Integrações externas usam credenciais embutidas em código | | Registrando | ⚡️ Os registros de depuração contêm dados confidenciais, como senhas ou PII | | Controle de acesso | ⚡️ Verificações FLS e CRUD omitidas porque "controla todos os usuários" | | Configuração | ⚡️ Descobertas da Verificação de integridade de segurança ignoradas ou adiadas indefinidamente | ## Design seguro de pipeline **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Pipeline \| Controle de origem | ✅ Regras de proteção de filial aplicam revisões obrigatórias e verificações de status | | Pipeline \| Controle de acesso | ✅ Os pipelines de implementação usam contas de serviço com o mínimo de permissões necessárias | | Funil \| Segredos | ✅ Segredos armazenados em cofres seguros (nunca em variáveis de ambiente ou controle de origem) | | Pipeline \| Implantação | ✅ Implantações de produção exigem a aprovação manual do pessoal autorizado | | Pipeline \| Auditoria | ✅ Os registros de implementação capturam quem implementou o que quando com trilhas de aprovação | | Pipeline \| Validação | ✅ A validação pré-implementação inclui verificações de conformidade e verificações de segurança | | Pipeline \| Controle de acesso | ✅ Autenticação multifator necessária para acesso administrativo ao pipeline | | Funil \| Monitoramento | ✅ Alterações na configuração do pipeline acionam notificações da equipe de segurança | | Pipeline \| Validação | ✅ A validação pós-implementação automatizada confirma os controles de segurança esperados ativos | | Pipeline \| Dependências | ✅ Atualizações de dependência avaliadas quanto ao impacto de segurança antes da implementação | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Funil \| Segredos | ⚡️ Segredos confirmados no controle de versão (mesmo que sejam removidos posteriormente) | | Pipeline \| Controle de origem | ⚡️ Qualquer pessoa pode ser mesclada com a ramificação principal/produção sem revisão | | Pipeline \| Controle de acesso | ⚡️ Os pipelines de implementação são executados com permissões em nível de administrador | | Pipeline \| Implantação | Implantações de produção totalmente automatizadas sem portões de aprovação | | Pipeline \| Auditoria | ⚡️ Os registros de implementação não capturam quem iniciou ou aprovou alterações | | Pipeline \| Validação | ⚡️ Verificações de segurança com falha ignoradas ou ignoradas para cumprir prazos | | Funil \| Monitoramento | Alterações de configuração do pipeline não rastreadas nem revisadas | | Pipeline \| Validação | ⚡️ A validação pós-implementação verifica apenas a correção funcional | ## Estratégia de teste de segurança **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Testar \| Análise estática | ✅ O Salesforce Code Analyzer é executado em IDEs do desenvolvedor para feedback imediato e em pipelines CI/CD como portões automatizados | | Testes \| Testes de penetração | ✅ Teste de penetração realizado para aplicativos personalizados expostos a usuários não confiáveis, especialmente sites do Experience Cloud e APIs voltadas para o público | | Testes \| Testes de unidade | ✅ Testes de unidade do Apex focados em segurança são executados como usuários com diferentes perfis de permissão | | Testar \| Dependências | ✅ A varredura de dependência monitora pacotes do AgentExchange e bibliotecas JavaScript quanto a vulnerabilidades conhecidas | | Testes \| Revisão de segurança | ✅ Relatório de análise estática preparado para cada envio do AppExchange ou da Análise de segurança do AgentExchange | | Testes \| Revisão de segurança | ✅ Relatório de verificação dinâmica (teste de penetração) preparado quando uma solução integra um aplicativo ou serviço da Web de terceiros | | Testar \| Dependências | ✅ Avisos de segurança para pacotes instalados assinados e monitorados | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Testar \| Cobertura | ⚡️ O teste de segurança depende de uma única técnica, como análise estática apenas | | Testes \| Testes de unidade | Os testes do Apex validam o comportamento funcional, mas nunca são executados como usuários com privilégios inferiores | | Testes \| Revisão de segurança | ⚡️ Envio do AppExchange ou do AgentExchange preparado sem a análise estática necessária ou relatórios de digitalização dinâmica | | Testes \| Testes de penetração | Teste de penetração ignorado para APIs e sites do Experience Cloud voltados para o público | ## Padrões relacionados Consulte também: - [Conformidade e padrões regulatórios](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-compliance-patterns.md) — Controles de governança e auditoria da plataforma - [Padrões de gerenciamento de identidade e acesso](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-identity-access-patterns.md) – autenticação e autorização - Padrões de [resposta a incidentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-incident-response-patterns.md) – detecção e resposta de incidentes de segurança - [Padrões agentes](https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-agentic-patterns.md) — Controles de segurança específicos do agente