# Segurança de aplicações
**Topics**
+ [SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?](sec-11.md)
# SEGURANÇA 11. Como incorporar e validar as propriedades de segurança de aplicações durante o ciclo de vida de design, desenvolvimento e implantação?
Treinar a equipe, testar por meio da automação, entender as dependências e validar as propriedades de segurança de ferramentas e aplicações ajuda a diminuir a probabilidade de problemas de segurança em workloads de produção.
**Topics**
+ [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Realizar teste de penetração regular](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Análises manuais de código](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizar serviços para pacotes e dependências](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Implantar software programaticamente](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
# SEC11-BP01 Treinar para segurança de aplicações
Forneça treinamento aos criadores em sua organização sobre práticas comuns para promover a segurança no desenvolvimento e na operação de aplicações. A adoção de práticas de desenvolvimento com foco na segurança ajuda a diminuir a probabilidade de problemas que são detectados somente no estágio de avaliação da segurança.
**Resultado desejado:** o software deve ser projetado e criado com a segurança em mente. Quando os criadores em uma organização são treinados em práticas de desenvolvimento seguras que começam com um modelo de ameaças, isso melhora a qualidade e a segurança gerais do software produzido. Essa abordagem pode reduzir o tempo de entrega do software ou de recursos porque não é necessário tanto retrabalho após o estágio de avaliação da segurança.
Para as finalidades desta prática recomendada, *desenvolvimento seguro* refere-se ao software que está sendo criado e às ferramentas ou aos sistemas compatíveis com o ciclo de vida de desenvolvimento de software (SDLC).
**Antipadrões comuns:**
+ Aguardar uma avaliação da segurança e, depois, considerar as propriedades de segurança de um sistema.
+ Deixar todas as decisões de segurança para a equipe de segurança.
+ Não comunicar como as decisões tomadas no SDLC se relacionam às expectativas ou as políticas de segurança gerais da organização.
+ Iniciar o processo de avaliação da segurança muito tardiamente.
**Benefícios do estabelecimento desta prática recomendada:**
+ Melhor conhecimento dos requisitos organizacionais para a segurança na fase inicial do ciclo de desenvolvimento.
+ Ser capaz de identificar e solucionar possíveis problemas de segurança com maior rapidez, promovendo uma entrega de recursos mais rápida.
+ Maior qualidade do software e dos sistemas.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
Ofereça treinamento aos criadores em sua organização. Iniciar um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) é uma boa base para ajudar a treinar para segurança. Preferencialmente, os criadores devem ser capazes de acessar de forma independente as informações relevantes às respectivas workloads. Esse acesso os ajuda a tomar decisões embasadas sobre as propriedades de segurança dos sistemas criados por eles sem a necessidade de solicitar outra equipe. O processo para envolver a equipe de segurança para avaliações deve ser claramente definido e simples de seguir. As etapas do processo de avaliação devem ser incluídas no treinamento de segurança. Quando houver padrões ou modelos de implementação disponíveis, eles deverão ser simples de encontrar e vincular aos requisitos de segurança gerais. Considere usar o [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) as [estruturas do AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), o [Service Catalog](https://aws.amazon.com/servicecatalog/) ou outras ferramentas de modelo para reduzir a necessidade de configuração personalizada.
### Etapas da implementação
+ Oferecer aos criadores um curso sobre [modelagem de ameaças](https://catalog.workshops.aws/threatmodel/en-US) para criar uma boa base e ajudar a treiná-los a pensar em segurança.
+ Conceder acesso ao treinamento do [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult), do setor ou de parceiros da AWS.
+ Fornecer treinamento sobre o processo de avaliação da segurança de sua organização, que esclarece a divisão de responsabilidades entre a equipe de segurança, as equipes de workload e outras partes interessadas.
+ Publicar orientações de autoatendimento sobre como atender aos seus requisitos de segurança, inclusive códigos de exemplo e modelos, se disponíveis.
+ Obter feedback regularmente de equipes de criadores sobre a experiência deles com o processo e o treinamento de processo de avaliação da segurança e usar esse feedback para promover melhorias.
+ Utilizar dias de jogo ou campanhas de bug bash para ajudar a reduzir o número de problemas e aumentar as habilidades de seus criadores.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
**Documentos relacionados:**
+ [Treinamento da AWS and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult)
+ [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/)
+ [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)
+ [Como acelerar o treinamento: o AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html)
**Vídeos relacionados:**
+ [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag)
**Exemplos relacionados:**
+ [Workshop sobre modelagem de ameaças](https://catalog.workshops.aws/threatmodel)
+ [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/)
**Serviços relacionados:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [Estruturas do AWS Cloud Development Kit (AWS CDK) (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)
+ [Service Catalog](https://aws.amazon.com/servicecatalog/)
+ [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html)
# SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento
Automatize o teste das propriedades de segurança durante o ciclo de vida de desenvolvimento e lançamento. Com a automação, é mais fácil identificar de forma consistente e repetível possíveis problemas no software antes do lançamento, o que reduz o risco de problemas de segurança no software que está sendo fornecido.
**Resultado esperado: ** o objetivo do teste automatizado é oferecer uma forma programática de detectar possíveis problemas precocemente e com frequência ao longo do ciclo de vida de desenvolvimento. Ao automatizar o teste de regressão, você pode executar novamente testes funcionais e não funcionais para verificar se o software testado anteriormente ainda funciona da forma esperada após uma alteração. Ao definir testes de unidade de segurança para conferir configurações incorretas comuns, como uma autenticação ausente ou danificada, é possível identificar e resolver esses problemas logo no início do processo de desenvolvimento.
A automação de testes utiliza casos de teste para um propósito específico para validação de aplicações, com base nos requisitos e na funcionalidade desejada da aplicação. O resultado dos testes automatizados baseia-se na comparação da saída do teste gerado com a respectiva saída esperada, o que acelera o ciclo de vida dos testes em geral. As metodologias de teste, como teste de regressão e pacotes de teste de unidade, são mais adequadas para automação. A automação dos testes de propriedades de segurança possibilita aos criadores receber feedback automatizado sem precisar esperar por uma avaliação da segurança. Os testes automatizados em forma de análise de código estático ou dinâmico podem melhorar a qualidade do código e ajudar a detectar possíveis problemas de software no ciclo de vida de desenvolvimento.
**Antipadrões comuns:**
+ Não comunicar os casos de teste e os resultados dos testes automatizados.
+ Realizar os testes automatizados somente antes de um lançamento.
+ Automatizar casos de teste com requisitos que mudam com frequência.
+ Não fornecer orientações sobre como abordar os resultados dos testes de segurança.
**Benefícios do estabelecimento desta prática recomendada:**
+ Redução da dependência de pessoas que avaliam as propriedades de segurança dos sistemas.
+ Descobertas consistentes em vários fluxos de trabalho que melhoram a consistência.
+ Redução da probabilidade de introduzir problemas de segurança no software de produção.
+ Redução do período de tempo entre a detecção e a correção devido à detecção mais antecipada de problemas de software.
+ Maior visibilidade do problema sistêmico ou repetido entre os vários fluxos de trabalho, o que pode ser utilizado para promover melhorias em toda a organização.
** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientação de implementação
Ao criar um software, adote vários mecanismos de teste para garantir que você esteja testando os requisitos funcionais da aplicação, com base na respectiva lógica de negócios e em requisitos não funcionais, os quais se concentram na confiabilidade, performance e segurança da aplicação.
O teste de segurança de aplicação estática (SAST) analisa padrões de segurança anômalos no código-fonte e fornece indicações de código propenso a defeitos. O SAST depende de entradas estáticas, como documentação (especificação de requisitos, documentação e especificações de design) e código-fonte da aplicação, para testar uma série de problemas de segurança conhecidos. Os analisadores de código estático podem ajudar a acelerar a análise de grandes volumes de código. O [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) oferece uma comparação de [analisadores de segurança de código-fonte](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), o que inclui ferramentas de código aberto para [leitores de código de byte](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) e [leitores de código binário](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).
Complemente seu teste estático com metodologias de teste de segurança de análise dinâmica (DAST), que realizam testes na aplicação em execução a fim de identificar comportamento possivelmente inesperado. O teste dinâmico pode ser utilizado para detectar possíveis problemas que não são detectáveis por meio de análise estática. Por meio dos testes nos estágios de repositório de código, compilação e pipeline, é possível impedir que diferentes tipos de problema em potencial ocorram no código. O [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) oferece recomendações de código, como verificação de segurança, no IDE do criador. O [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) pode identificar problemas críticos, problemas de segurança e bugs difíceis de detectar durante o desenvolvimento da aplicação e oferece recomendações para melhorar a qualidade do código.
O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) utiliza ferramentas de desenvolvedor da AWS, como [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) e [AWS CodePipeline](https://aws.amazon.com/codepipeline/), para automação de pipeline de lançamento que inclui as metodologias de teste SAST e DAST.
À medida que você avançar no SDLC, estabeleça um processo iterativo que inclua avaliações de aplicação periódicas com sua equipe de segurança. O feedback coletado dessas avaliações de segurança deve ser abordado e validado como parte de sua avaliação de prontidão do lançamento. Essas avaliações estabelecem um procedimento de segurança robusto de aplicações e fornecem aos criadores feedback útil para resolver possíveis problemas.
### Etapas da implementação
+ Implementar um IDE consistente, análise de código e ferramentas de CI/CD que incluam teste de segurança.
+ Considerar quando no SDLC é adequado bloquear pipelines em vez de apenas notificar os criadores de que problemas precisam ser corrigidos.
+ O workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs) fornece um exemplo de como integrar testes estáticos e dinâmicos a um pipeline de lançamento.
+ Realizar testes ou análise de código com ferramentas automatizadas, como o [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrado a IDEs de desenvolvedores e o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para verificação do código na confirmação, ajuda os criadores a obter feedback no momento certo.
+ Ao criar com o AWS Lambda, é possível usar o [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) para verificar o código de aplicação em suas funções.
+ O workshop [CI/CD na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) fornece um ponto de partida para criar pipelines de CI/CD na AWS.
+ Quando testes automatizados são incluídos em pipelines de CI/CD, você precisa usar um sistema de emissão de tíquetes para rastrear a notificação e a correção de problemas de software.
+ Para testes de segurança que podem gerar descobertas, a vinculação com orientações para correção ajuda os criadores a melhorar a qualidade do código.
+ Analise regularmente as descobertas das ferramentas automatizadas para priorizar a próxima automação, o treinamento de criadores ou a campanha de conscientização.
## Recursos
**Documentos relacionados:**
+ [Entrega contínua e implantação contínua](https://aws.amazon.com/devops/continuous-delivery/)
+ [Parceiros com competência em DevOps da AWS](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1)
+ [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) para segurança da aplicação
+ [Como escolher uma abordagem de CI/CD do Well-Arquitected](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/)
+ [Monitorar eventos do CodeCommit no Amazon EventBridge e no Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html)
+ [Análise da detecção de segredos no Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection)
+ [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Como a AWS aborda a automação de implantações seguras e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Vídeos relacionados:**
+ [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [Como automatizar pipelines CI/CD entre contas](https://www.youtube.com/watch?v=AF-pSRSGNks)
**Exemplos relacionados:**
+ [Conscientização do setor para desenvolvedores](https://owasp.org/www-project-top-ten/)
+ [Governança do AWS CodePipeline](https://github.com/awslabs/aws-codepipeline-governance)
+ Workshop [Segurança para desenvolvedores](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US)
+ [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/)
# SEC11-BP03 Realizar teste de penetração regular
Realize teste de penetração regular do software. Esse mecanismo ajuda a identificar possíveis problemas de software que não podem ser detectados pelo teste automatizado ou por uma análise manual do código. Ele também ajuda você a entender a eficácia dos controles de detecção. O teste de penetração deve tentar determinar se o software pode ser executado de formas inesperadas; por exemplo, expondo dados que devem ser protegidos ou concedendo permissões mais amplas que o esperado.
**Resultado desejado:** o teste de penetração é usado para detectar, corrigir e validar as propriedades de segurança da aplicação. O teste de penetração regular e programado deve ser realizado como parte do ciclo de vida de desenvolvimento de software (SDLC). As descobertas do teste de penetração devem ser abordadas antes do lançamento do software. Você precisa analisar as descobertas do teste de penetração para identificar se há problemas que podem ser encontrados usando a automação. Ter um processo de teste de penetração regular e repetível que inclua um mecanismo de feedback ativo ajuda a transmitir as orientações aos criadores e melhora a qualidade do software.
**Antipadrões comuns:**
+ Realizar um teste de penetração somente para problemas de segurança conhecidos ou prevalentes.
+ Realizar um teste de penetração em aplicações sem ferramentas e bibliotecas de terceiro dependentes.
+ Realizar um teste de penetração em aplicações em busca de problemas de segurança de pacote e não avaliar a lógica de negócios implementada.
**Benefícios do estabelecimento desta prática recomendada:**
+ Maior confiança nas propriedades de segurança do software antes do lançamento.
+ Oportunidade de identificar padrões de aplicação preferenciais, o que aumenta a qualidade do software.
+ Um ciclo de feedback que identifica mais cedo no ciclo de desenvolvimento quando a automação ou treinamento adicional pode melhorar as propriedades de segurança do software.
** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto
## Orientação de implementação
O teste de penetração é um exercício de teste de segurança estruturado em que você executa cenários de violação de segurança planejados a fim de detectar, corrigir e validar controles de segurança. Os testes de penetração começam com o reconhecimento, durante o qual os dados são coletados com base no design atual da aplicação e nas respectivas dependências. Uma lista selecionada de cenários de teste específicos de segurança é criada e executada. A principal finalidade desses testes é revelar problemas de segurança em sua aplicação, que podem ser explorados para obter acesso não intencional ao seu ambiente ou acesso não autorizado aos dados. Você precisa realizar o teste de penetração ao lançar novos recursos ou sempre que sua aplicação passar por alterações importantes na implementação técnica ou de funções.
É necessário identificar o estágio mais apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração. Esse teste deve ocorrer em uma fase tardia o suficiente para que a funcionalidade do sistema esteja próxima ao estado de lançamento pretendido, mas com tempo suficiente para corrigir todos os problemas.
### Etapas da implementação
+ Ter um processo estruturado sobre como definir o escopo do teste de penetração. Basear esse processo no [modelo de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) é uma boa forma de manter o contexto.
+ Identificar o estágio apropriado do ciclo de vida de desenvolvimento para realizar o teste de penetração, que deve ser quando houver o mínimo de alterações esperadas na aplicação e houver tempo suficiente para realizar a correção.
+ Treinar os criadores sobre o que esperar das descobertas do teste de penetração e como ter informações sobre correção.
+ Utilizar ferramentas para acelerar o processo de testes de penetração automatizando testes comuns ou repetíveis.
+ Analisar as descobertas do teste de penetração para identificar problemas de segurança sistêmicos e utilizar esses dados para embasar testes automatizados adicionais e a instrução contínua dos criadores.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [O teste de penetração da AWS](https://aws.amazon.com/security/penetration-testing/) fornece orientações detalhadas para teste de penetração na AWS
+ [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Parceiros de competência em segurança da AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc)
+ [Modernize sua arquitetura de teste de penetração no AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/)
+ [AWS Fault injection Simulator](https://aws.amazon.com/fis/)
**Exemplos relacionados:**
+ [Como automatizar testes de API com o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub)
+ [Assistente de segurança automatizado](https://github.com/aws-samples/automated-security-helper) (GitHub)
# SEC11-BP04 Análises manuais de código
Realize uma análise manual do código do software que você produz. Esse processo ajuda a verificar se a pessoa que escreveu o código não é a única que está conferindo a qualidade dele.
**Resultado desejado:** a inclusão de uma etapa de análise de código manual durante o desenvolvimento melhora a qualidade do software que está sendo criado, ajuda a melhorar as habilidades de membros menos experientes da equipe e oferece uma oportunidade de identificar locais onde a automação pode ser usada. É possível oferecer compatibilidade com as análises de código manuais com ferramentas e testes automatizados.
**Antipadrões comuns:**
+ Não realizar análises de código antes da implantação.
+ Ter a mesma pessoa para escrever e analisar o código.
+ Não utilizar a automação para auxiliar ou orquestrar as análises de código.
+ Não treinar os criadores em segurança de aplicações antes de analisarem o código.
**Benefícios do estabelecimento desta prática recomendada:**
+ Código de melhor qualidade.
+ Maior consistência do desenvolvimento do código por meio da reutilização de abordagens comuns.
+ Redução no número de problemas descobertos durante o teste de penetração e em estágios posteriores.
+ Maior transferência de conhecimentos na equipe.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientações para a implementação
A etapa de análise deve ser implementada como parte do fluxo de gerenciamento de código geral. Os detalhes dependem da abordagem utilizada para ramificação, solicitações de pull e mesclagem. Você pode utilizar o AWS CodeCommit ou soluções de terceiros, como GitHub, GitLab ou Bitbucket. Seja qual for o método utilizado, é importante verificar se seus processos precisam de análise de código antes da implantação em um ambiente de produção. O uso de ferramentas, como o [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html), pode facilitar a orquestração do processo de análise do código.
### Etapas da implementação
+ Implementar uma etapa de análise manual como parte do fluxo de gerenciamento de código e realizar essa análise antes de prosseguir.
+ Considerar o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para gerenciar e auxiliar nas análises de código.
+ Implementar um fluxo de aprovação que exija a realização de uma análise de código antes de avançá-lo para o próximo estágio.
+ Verificar se há um processo para identificar problemas encontrados durante as análises de código manuais que possam ser detectados automaticamente.
+ Integrar a etapa de análise de código manual de forma que se alinhe às suas práticas de desenvolvimento de código.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Trabalhar com solicitações de pull em repositórios do AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html)
+ [Trabalhar com modelos de regra de aprovação no AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html)
+ [Sobre solicitações de pull no GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
+ [Análises de código automatizadas com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [Automatizar a detecção de vulnerabilidades de segurança e bugs em pipelines de CI/CD com o uso da CLI do Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/)
**Vídeos relacionados:**
+ [Melhoria contínua da qualidade do código com o Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw)
**Exemplos relacionados:**
+ Workshop [Segurança para desenvolvedores](https://catalog.workshops.aws/sec4devs)
# SEC11-BP05 Centralizar serviços para pacotes e dependências
Forneça serviços centralizados a equipes de criadores para obter pacotes de software e outras dependências. Isso permite a validação de pacotes antes que eles sejam incluídos no software que você escreve e fornece uma fonte de dados para a análise do software que está sendo usado na sua organização.
**Resultado desejado:** o software é composto de um conjunto de outros pacotes de software além do código que está sendo escrito. Isso simplifica o consumo de implementações de funcionalidades que são utilizadas repetidamente, como um analisador JSON ou uma biblioteca de criptografia. A centralização lógica das fontes desses pacotes e dependências oferece um mecanismo para as equipes de segurança validarem as propriedades dos pacotes antes de eles serem utilizados. Essa abordagem também reduz o risco de um problema inesperado ser provocado por uma alteração em um pacote existente ou pela inclusão de pacotes arbitrários diretamente da Internet pelas equipes de criadores. Utilize essa abordagem em conjunto com os fluxos de testes manuais e automatizados para aumentar a confiança na qualidade do software que está sendo desenvolvido.
**Antipadrões comuns:**
+ Extrair pacotes de repositórios arbitrários na Internet.
+ Não testar novos pacotes antes de disponibilizá-los aos criadores.
**Benefícios do estabelecimento desta prática recomendada:**
+ Melhor entendimento de quais pacotes estão sendo utilizados no software que está sendo criado.
+ Capacidade de notificar as equipes de workload quando um pacote precisa ser atualizado com base no entendimento de quem está usando o quê.
+ Redução do risco de um pacote com problemas ser incluído em seu software.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** médio
## Orientação de implementação
Forneça serviços centralizados para pacotes e dependências de uma forma simples para os criadores consumirem. Serviços centralizados podem ser centralizados logicamente em vez de implementados como um sistema monolítico. Essa abordagem possibilita fornecer serviços de uma forma que atenda às necessidades dos criadores. Você precisa implementar uma forma eficiente de adicionar pacotes ao repositório quando ocorrem atualizações ou surgem novos requisitos. Serviços da AWS como o [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) ou soluções semelhantes de parceiros da AWS oferecem uma forma de entregar esse recurso.
### Etapas da implementação:
+ Implementar um serviço de repositório centralizado logicamente disponível em todos os ambientes onde o software é desenvolvido.
+ Incluir acesso ao repositório como parte do processo de provisionamento de Conta da AWS.
+ Criar automação para testar pacotes antes de serem publicados em um repositório.
+ Manter métricas dos pacotes mais utilizados, das linguagens e das equipes com a maior quantidade de alterações.
+ Fornecer um mecanismo automatizado para as equipes de criadores solicitarem novos pacotes e fornecerem feedback.
+ Verificar regularmente os pacotes em seu repositório para identificar o possível impacto de problemas recém-descobertos.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Aumentar a segurança de seu pacote com o kit de ferramentas CodeArtifact Package Origin Control](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/)
+ [Detectar problemas de segurança no registro em log com o Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/)
+ [Níveis de cadeia de suprimentos para artefatos de software (SLSA)](https://slsa.dev/)
**Vídeos relacionados:**
+ [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag)
+ [A filosofia de segurança da AWS (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U)
+ [Quando a segurança, a proteção e a urgência importam: lidar com o Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg)
**Exemplos relacionados:**
+ [Pipeline de publicação de pacotes de várias regiões](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub)
+ [Publicar módulos Node.Js no AWS CodeArtifact usando o AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub)
+ [Exemplo de pipeline do AWS CDK Java CodeArtifact](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub)
+ [Distribuir pacotes privados do .NET NuGet com o AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub)
# SEC11-BP06 Implantar software programaticamente
Faça implantações de software de forma programática quando possível. Essa abordagem diminui a probabilidade de falha em uma implantação ou da introdução de um problema inesperado devido a erro humano.
**Resultado desejado: **manter as pessoas longe dos dados é um princípio essencial da criação segura na Nuvem AWS. Esse princípio inclui como implantar seu software.
Os benefícios de não contar com pessoas para implantar software é a maior confiança de que o componente testado é o que será implantado e de que a implantação sempre é realizada de forma consistente. O software não deve precisar de alterações para funcionar em diferentes ambientes. O uso dos princípios de desenvolvimento de aplicações de 12 fatores, especificamente a externalização da configuração, possibilita implantar o mesmo código em vários ambientes sem a necessidade de alterações. Assinar de forma criptográfica os pacotes de software é uma boa maneira de garantir que nada tenha sido alterado entre os ambientes. O resultado geral dessa abordagem é reduzir o risco em seu processo de alterações e melhorar a consistência das versões do software.
**Antipadrões comuns:**
+ Implantar software manualmente em produção.
+ Realizar alterações manualmente no software para suprir diferentes ambientes.
**Benefícios do estabelecimento desta prática recomendada:**
+ Maior confiança no processo de lançamento de software.
+ Redução do risco de uma alteração com falha afetar a funcionalidade dos negócios.
+ Maior cadência de lançamentos devido ao menor risco de alterações.
+ Recurso de reversão automática para eventos inesperados durante a implantação.
+ Capacidade de comprovar de forma criptográfica que o software testado é o software implantado.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto
## Orientações para a implementação
Crie a infraestrutura de sua Conta da AWS para remover o acesso humano persistente dos ambientes e use ferramentas de CI/CD para realizar implantações. Projete suas aplicações de forma que os dados da configuração específica do ambiente sejam obtidos de uma fonte externa, como o [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Assine pacotes depois de testados e valide essas assinaturas durante a implantação. Configure seus pipelines de CI/CD para enviar código da aplicação e usar canários para confirmar a implantação bem-sucedida. Utilize ferramentas como o [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ou o [AWS CDK](https://aws.amazon.com/cdk/) para definir sua infraestrutura; depois, use o [AWS CodeBuild](https://aws.amazon.com/codebuild/) e o [AWS CodePipeline](https://aws.amazon.com/codepipeline/) para realizar operações de CI/CD.
### Etapas da implementação
+ Criar pipelines de CI/CD bem definidos para simplificar o processo de implantação.
+ O uso do [AWS CodeBuild](https://aws.amazon.com/codebuild/) e do [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) para oferecer recurso de CI/CD simplifica a integração de teste de segurança aos seus pipelines.
+ Seguir as orientações sobre separação de ambientes no whitepaper [Organizar seu ambiente da AWS com o uso de várias contas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html).
+ Garantir que não haja nenhum acesso humano persistente aos ambientes nos quais as workloads de produção estão em execução.
+ Projetar as aplicações para oferecer compatibilidade com a externalização de dados de configuração.
+ Considerar a implantação com o uso do modelo de implantação azul/verde.
+ Implementar canários para validar a implantação bem-sucedida do software.
+ Utilizar ferramentas criptográficas, como o [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) ou o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/), para assinar e confirmar os pacotes de software que você está implantando.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Workshop sobre CI/CD da AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/)
+ [Acelerar implantações na AWS com governança efetiva](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Automatizar uma implantação prática e sem intervenção manual](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Assinatura de código com o uso de CA privada do AWS Certificate Manager e chaves assimétricas do AWS Key Management Service)](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
+ [Assinatura de código: um controle de integridade e confiança para o AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/)
**Vídeos relacionados:**
+ [Sem intervenção manual: como automatizar os pipelines de entrega contínua na Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
**Exemplos relacionados:**
+ [Implantações azul/verde com o AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US)
# SEC11-BP07 Avaliar regularmente as propriedades de segurança dos pipelines
Aplique os princípios do pilar Segurança do Well-Architected aos seus pipelines, com atenção especial à separação das permissões. Avalie as propriedades de segurança de sua infraestrutura de pipelines. O gerenciamento eficaz da segurança *dos* pipelines permite que você forneça segurança ao software que passa *pelos* pipelines.
**Resultado desejado: **os pipelines utilizados para criar e implantar o software devem seguir as mesmas práticas recomendadas que qualquer outra workload em seu ambiente. Os testes implementados nos pipelines não devem ser editáveis pelos criadores que os estão utilizando. Os pipelines só devem ter as permissões necessárias para as implantações que eles estão realizando e devem implementar proteções para evitar a implantação em ambientes errados. Os pipelines não devem contar com credenciais de longo prazo e devem ser configurados para emitir o estado de forma que a integridade dos ambientes de compilação possa ser validada.
**Antipadrões comuns:**
+ Testes de segurança que podem ser ignorados pelos criadores.
+ Permissões excessivamente amplas para pipelines de implantação.
+ Pipelines não configurados para validar entradas.
+ Ausência de análise regular das permissões associadas à infraestrutura de CI/CD.
+ Uso de credenciais de longo prazo ou codificadas.
**Benefícios do estabelecimento desta prática recomendada:**
+ Maior confiança na integridade do software que está sendo criado e implantado pelos pipelines.
+ Capacidade de interromper uma implantação quando há atividade suspeita.
** Nível de exposição a riscos se esta prática recomendada não for estabelecida:** alto
## Orientação de implementação
Iniciar com serviços de CI/CD gerenciados que ofereçam compatibilidade com perfis do IAM reduz o risco de vazamento de credenciais. Aplicar os princípios do pilar Segurança à sua infraestrutura de pipeline de CI/CD pode ajudar você a determinar onde é possível realizar melhorias de segurança. Seguir a [Arquitetura de referência de pipelines de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) é um bom ponto de partida para criar seus ambientes de CI/CD. Analisar regularmente a implementação de pipelines e analisar comportamentos inesperados nos logs pode ajudar você a entender os padrões de uso dos pipelines que estão sendo utilizados para implantar o software.
### Etapas da implementação
+ Iniciar com a [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/).
+ Considerar o uso do [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) para gerar de forma programática as políticas de privilégio mínimo do IAM para os pipelines.
+ Integrar seus pipelines ao monitoramento e aos alertas de forma que você seja notificado de atividade inesperada ou anormal. Para serviços gerenciados da AWS, o [Amazon EventBridge](https://aws.amazon.com/eventbridge/) possibilita rotear dados para destinos, como o [AWS Lambda](https://aws.amazon.com/lambda/) ou o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS).
## Recursos
**Documentos relacionados:**
+ [Arquitetura de referência de pipeline de implantação da AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/)
+ [Monitorar o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html)
+ [Práticas recomendadas de segurança para o AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)
**Exemplos relacionados:**
+ [Painel de monitoramento de DevOps](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub)
# SEC11-BP08 Criar um programa que incorpore a propriedade de segurança nas equipes de workload
Crie um programa ou mecanismo que capacite as equipes de criadores a tomar decisões de segurança sobre o software que elas estão criando. Ainda assim é necessário que sua equipe de segurança valide essas decisões durante uma avaliação, mas a incorporação da propriedade de segurança nas equipes de criadores aumenta a velocidade e segurança do processo de criação de workloads. Esse mecanismo também promove uma cultura de propriedade que afeta de forma positiva a operação dos sistemas que você cria.
**Resultado desejado: **para incorporar a propriedade de segurança e a tomada de decisão às equipes de criadores, você pode treinar os criadores a pensar sobre segurança ou incrementar o treinamento deles com pessoal de segurança incorporado ou associado às equipes de criadores. As duas abordagens são válidas e possibilitam à equipe tomar decisões de segurança de melhor qualidade logo no início do ciclo de desenvolvimento. Esse modelo de propriedade é baseado em treinamento para segurança de aplicações. Iniciar com o modelo de ameaças para a workload específica ajuda a direcionar o design thinking (pensamento de design) para o contexto apropriado. Outro benefício de ter uma comunidade de criadores concentrados em segurança ou um grupo de engenheiros de segurança que trabalhem com equipes de criadores é que você pode entender mais profundamente como o software é escrito. Esse entendimento ajuda você a determinar as próximas áreas de melhoria em seu recurso de automação.
**Antipadrões comuns:**
+ Deixar todas as decisões de design de segurança para a equipe de segurança.
+ Não abordar os requisitos de segurança cedo o suficiente no processo de desenvolvimento.
+ Não obter feedback dos criadores e do pessoal de segurança sobre a operação do programa.
**Benefícios do estabelecimento desta prática recomendada:**
+ Redução do tempo para concluir as avaliações de segurança.
+ Redução dos problemas de segurança que são detectados apenas no estágio de avaliação da segurança.
+ Melhoria da qualidade geral do software que está sendo escrito.
+ Oportunidade de identificar e entender problemas sistêmicos ou áreas de melhoria de alto valor.
+ Redução da quantidade de revisão necessária devido às descobertas da avaliação da segurança.
+ Melhoria da percepção da função de segurança.
**Nível de exposição a riscos se esta prática recomendada não for estabelecida:** baixo
## Orientações para a implementação
Comece com as orientações em [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md). Depois, identifique o modelo operacional para o programa que você acredita ser o melhor para a sua organização. Os dois padrões principais são treinar os criadores ou incorporar o pessoal de segurança às equipes de criadores. Depois de decidir sobre a abordagem inicial, você precisa criar um piloto com uma equipe de workload ou um grupo pequeno de equipes de workload para comprovar que o modelo funciona para sua organização. O apoio de liderança dos criadores e da segurança da organização contribui para a entrega e o sucesso do programa. À medida que você criar esse programa, é importante selecionar as métricas que podem ser utilizadas para mostrar o valor dele. Saber como a AWS resolveu esse problema é uma boa experiência de aprendizado. A prática recomendada é muito concentrada na mudança e cultura organizacionais. As ferramentas que você utiliza devem ser compatíveis com a colaboração entre as comunidades de criadores e de segurança.
### Etapas da implementação
+ Começar com o treinamento dos criadores para segurança de aplicações.
+ Criar uma comunidade e um programa de integração para instruir os criadores.
+ Selecionar um nome para o programa. Guardiões, patrocinadores ou defensores são utilizados com frequência.
+ Identificar o modelo a ser utilizado: treinar criadores, incorporar engenheiros de segurança e ter perfis de segurança de afinidade.
+ Identificar patrocinadores do projeto em grupos de segurança e de criadores e possivelmente em outros grupos relevantes.
+ Rastrear as métricas do número de pessoas envolvidas no programa, o tempo gasto em avaliações e o feedback dos criadores e do pessoal de segurança. Utilizar essas métricas para realizar melhorias.
## Recursos
**Práticas recomendadas relacionadas:**
+ [SEC11-BP01 Treinar para segurança de aplicações](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar o teste durante o ciclo de vida de desenvolvimento e lançamento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Como abordar a modelagem de ameaças](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)
+ [Como pensar sobre governança de segurança na nuvem](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/)
**Vídeos relacionados:**
+ [Segurança proativa: considerações e abordagens](https://www.youtube.com/watch?v=CBrUE6Qwfag)