Ciclo de vida seguro de desenvolvimento – Padrões

Saiba mais sobre Well-Architected Trust → Ciclo de vida do desenvolvimento seguro

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.

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

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

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

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

Consulte também:

Conformidade e padrões regulatórios — Controles de governança e auditoria da plataforma
Padrões de gerenciamento de identidade e acesso – autenticação e autorização
Padrões de resposta a incidentes – detecção e resposta de incidentes de segurança
Padrões agentes — Controles de segurança específicos do agente