# Seguridad de las aplicaciones
**Topics**
+ [SEGURIDAD 11. ¿Cómo incorpora y valida las propiedades de seguridad de las aplicaciones durante el ciclo de vida de diseño, desarrollo y despliegue?](sec-11.md)
# SEGURIDAD 11. ¿Cómo incorpora y valida las propiedades de seguridad de las aplicaciones durante el ciclo de vida de diseño, desarrollo y despliegue?
La formación de los usuarios, las pruebas mediante automatización, el conocimiento de las dependencias y la validación de las propiedades de seguridad de herramientas y aplicaciones contribuyen a reducir la probabilidad de que se produzcan problemas de seguridad en las cargas de trabajo de producción.
**Topics**
+ [SEC11-BP01 Formar en seguridad de las aplicaciones](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Realizar pruebas de penetración periódicas](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Revisiones manuales del código](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizar los servicios para paquetes y dependencias](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Desplegar software mediante programación](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Evaluar periódicamente las propiedades de seguridad de las canalizaciones](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Crear un programa que integre la propiedad de la seguridad en los equipos de la carga de trabajo](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
# SEC11-BP01 Formar en seguridad de las aplicaciones
Ofrezca formación a los creadores de su organización sobre las prácticas habituales para el desarrollo y el funcionamiento seguros de las aplicaciones. La adopción de prácticas de desarrollo centradas en la seguridad contribuye a reducir la probabilidad de que surjan problemas que solo se detectan en la fase de revisión de la seguridad.
**Resultado deseado:** El software debe diseñarse y crearse teniendo en cuenta la seguridad. Cuando los creadores de una organización reciben formación sobre prácticas de desarrollo seguras que parten de un modelo de amenazas, mejora la calidad y la seguridad general del software producido. Este planteamiento puede acortar el tiempo hasta la entrega del software o de las características, ya que se reduce la necesidad de tener que volver a repetir los procesos tras la fase de revisión de la seguridad.
A efectos de esta práctica recomendada, el *desarrollo seguro* se refiere al software que se está escribiendo y a las herramientas o sistemas que prestan soporte al ciclo de vida de desarrollo del software (SDLC).
**Patrones comunes de uso no recomendados:**
+ Esperar a una revisión de seguridad para estudiar las propiedades de seguridad de un sistema.
+ Dejar todas las decisiones de seguridad en manos del equipo de seguridad.
+ No comunicar claramente cómo se relacionan las decisiones tomadas en el SDLC con las expectativas o políticas generales de seguridad de la organización.
+ Intervenir demasiado tarde en el proceso de revisión de la seguridad.
**Beneficios de establecer esta práctica recomendada:**
+ Entender mejor los requisitos de la organización en materia de seguridad en una fase temprana del ciclo de desarrollo.
+ Poder identificar y corregir más rápidamente los posibles problemas de seguridad, lo que se traduce en una entrega más rápida de las características.
+ Mejora de la calidad del software y los sistemas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Proporcione formación a los creadores de su organización. Una buena base para iniciar la formación sobre seguridad es empezar con un curso sobre [modelado de amenazas](https://catalog.workshops.aws/threatmodel/en-US). Lo ideal sería que los creadores pudieran acceder por sí mismos a la información relevante para sus cargas de trabajo. Este acceso les ayuda a tomar decisiones informadas sobre las propiedades de seguridad de los sistemas que crean sin necesidad de preguntar a otro equipo. El proceso de solicitud de revisiones al equipo de seguridad debe estar claramente definido y ser fácil de seguir. Los pasos del proceso de revisión deben incluirse en la formación sobre seguridad. Cuando se disponga de patrones o plantillas de implementación, deben ser fáciles de encontrar y vincular a los requisitos generales de seguridad. Plantéese el uso de [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) [Componentes de AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), [Service Catalog](https://aws.amazon.com/servicecatalog/) u otras herramientas basadas en plantillas para reducir la necesidad de configuración personalizada.
### Pasos para la aplicación
+ Empiece por ofrecer a los creadores un curso sobre [modelado de amenazas](https://catalog.workshops.aws/threatmodel/en-US) para sentar una buena base y ayudarles a formarse en cómo pensar en la seguridad.
+ Ofrezca acceso a formación para socios de AWS, sector o [Formación de AWS y 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).
+ Ofrezca formación sobre el proceso de revisión de la seguridad de su organización, que aclare el reparto de responsabilidades entre el equipo de seguridad, los equipos de carga de trabajo y otras partes interesadas.
+ Publique guías de autoservicio sobre cómo cumplir sus requisitos de seguridad, incluidos ejemplos de código y plantillas, si están disponibles.
+ Obtenga comentarios periódicamente de los equipos de creadores sobre su experiencia con el proceso de formación y revisión de la seguridad, y utilícelos para mejorar.
+ Utilice días de juegos o campañas de detección de errores para reducir el número de problemas y mejorar las competencias de los creadores.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP08 Crear un programa que integre la propiedad de la seguridad en los equipos de la carga de trabajo](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
**Documentos relacionados:**
+ [Formación de AWS y 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)
+ [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) (Cómo concebir la gobernanza de la seguridad en la nube)
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Cómo abordar el modelado de amenazas)
+ [Accelerating training – The AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) (Acelere la formación: AWS Skills Guild)
**Vídeos relacionados: **
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (Seguridad proactiva: consideraciones y estrategias)
**Ejemplos relacionados:**
+ [Workshop on threat modeling](https://catalog.workshops.aws/threatmodel) (Taller de modelado de amenazas)
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/) (Concienciación del sector para desarrolladores)
**Servicios relacionados:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [Componentes de 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 las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento
Automatice las pruebas de las propiedades de seguridad a lo largo del ciclo de vida de desarrollo y lanzamiento. La automatización facilita la identificación coherente y repetible de posibles problemas en el software antes de su lanzamiento, lo que reduce el riesgo de problemas de seguridad en el software suministrado.
**Resultado deseado:** El objetivo de las pruebas automatizadas es proporcionar una forma programática de detectar problemas de forma temprana y frecuente a lo largo del ciclo de vida de desarrollo. Al automatizar las pruebas de regresión, puede volver a ejecutar pruebas funcionales y no funcionales para verificar que el software probado previamente siga funcionando como se esperaba después de un cambio. Cuando se definen pruebas unitarias de seguridad para detectar errores de configuración habituales, como autenticación dañada o ausente, es posible identificar y solucionar estos problemas en una fase temprana del proceso de desarrollo.
La automatización de pruebas utiliza casos de prueba creados específicamente para la validación de aplicaciones, basados en los requisitos de la aplicación y la funcionalidad deseada. El resultado de las pruebas automatizadas se basa en la comparación de los resultados de las pruebas generados con los resultados esperados, lo que agiliza el ciclo de vida de las pruebas. Las metodologías de pruebas como las pruebas de regresión y los conjuntos de pruebas unitarias son las más adecuadas para la automatización. La automatización de las pruebas de las propiedades de seguridad permite a los creadores recibir información automatizada sin tener que esperar a una revisión de seguridad. Las pruebas automatizadas en forma de análisis de código estático o dinámico permiten aumentar la calidad del código y contribuyen a detectar posibles problemas de software en una fase temprana del ciclo de vida de desarrollo.
**Patrones comunes de uso no recomendados:**
+ No comunicar los casos de prueba y los resultados de las pruebas automatizadas.
+ Realizar las pruebas automatizadas solo justo antes del lanzamiento.
+ Automatizar casos de prueba con requisitos que cambian con frecuencia.
+ No proporcionar orientación sobre cómo abordar los resultados de las pruebas de seguridad.
**Beneficios de establecer esta práctica recomendada:**
+ Menor dependencia de las personas que evalúan las propiedades de seguridad de los sistemas.
+ La obtención de resultados coherentes en numerosos flujos de trabajo mejora la coherencia general.
+ Menos probabilidades de que se introduzcan problemas de seguridad en el software de producción.
+ Reducción del intervalo de tiempo entre la detección y la corrección gracias a la detección temprana de los problemas de software.
+ Mayor visibilidad del comportamiento sistémico o repetido en numerosos flujos de trabajo, que puede servir para impulsar mejoras en toda la organización.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
A medida que crea el software, adopte diversos mecanismos de prueba de software para asegurarse de probar tanto los requisitos funcionales, basados en la lógica empresarial, como los requisitos no funcionales, que se centran en la fiabilidad, el rendimiento y la seguridad de su aplicación.
Las pruebas de seguridad de aplicaciones estáticas (SAST) analizan el código fuente para revelar patrones de seguridad anómalos y proporcionan indicios de código propenso a errores. Las pruebas SAST se basan en datos estáticos, como la documentación (especificación de requisitos, documentación de diseño y especificaciones de diseño) y el código fuente de la aplicación, con objeto de encontrar una serie de problemas de seguridad conocidos. Los analizadores de código estático pueden ayudar a agilizar el análisis de grandes volúmenes de código. El [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) ofrece una comparación de [analizadores de seguridad del código fuente](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), que abarca herramientas de código abierto para [analizadores de código de bytes](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) y [analizadores de código binario](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).
Complemente las pruebas estáticas con metodologías de pruebas de seguridad de análisis dinámico (DAST), que efectúan pruebas de la aplicación en ejecución a fin de identificar comportamiento potencialmente inesperado. Las pruebas dinámicas pueden utilizarse para detectar problemas potenciales que no son evidentes mediante el análisis estático. Las pruebas en las etapas de repositorio de código, compilación y canalización le permiten comprobar si existen diferentes tipos de problemas potenciales que podrían introducirse en el código. [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) proporciona recomendaciones de código, incluido el análisis de seguridad, en el IDE del creador. [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) puede identificar problemas cruciales, problemas de seguridad y errores difíciles de detectar durante el desarrollo de la aplicación, y proporciona recomendaciones para mejorar la calidad del código.
El [taller de seguridad para desarrolladores](https://catalog.workshops.aws/sec4devs) usa herramientas de desarrollo de AWS, como [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) y [AWS CodePipeline](https://aws.amazon.com/codepipeline/), para la automatización de canalizaciones de lanzamiento que incluyen las metodologías de prueba SAST y DAST.
A medida que avance en el SDLC, establezca un proceso iterativo que incorpore revisiones periódicas de las aplicaciones con su equipo de seguridad. Los comentarios recogidos en estas revisiones de seguridad deben abordarse y validarse como parte de la revisión de la preparación para el lanzamiento. Estas revisiones establecen una sólida postura de seguridad de la aplicación y proporcionan a los desarrolladores información práctica para afrontar posibles problemas.
### Pasos para la aplicación
+ Implemente herramientas coherentes de IDE, revisión de código y CI/CD que incluyan pruebas de seguridad.
+ Considere en qué momento del SDLC es apropiado bloquear las canalizaciones en lugar de limitarse a notificar a los creadores que es necesario solucionar los problemas.
+ El [taller de seguridad para desarrolladores](https://catalog.workshops.aws/sec4devs) ofrece un ejemplo de integración de pruebas estáticas y dinámicas en un proceso de lanzamiento.
+ La realización de pruebas o análisis de código mediante herramientas automatizadas, como [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrado con los IDE de los desarrolladores y [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para escanear código al confirmar, ayuda a los desarrolladores a obtener información en el momento adecuado.
+ Si usa AWS Lambda para la compilación, puede utilizar [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) para analizar el código de la aplicación en sus funciones.
+ El [taller de CI/CD de AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) proporciona un punto de partida la crear canalizaciones de CI/CD en AWS.
+ Cuando se incluyen pruebas automatizadas en las canalizaciones de CI/CD, es preciso utilizar un sistema de tickets para realizar un seguimiento de la notificación y corrección de problemas de software.
+ En el caso de las pruebas de seguridad que puedan generar hallazgos, la vinculación a orientaciones para la corrección ayuda a los creadores a mejorar la calidad del código.
+ Analice periódicamente los resultados de las herramientas automatizadas para dar prioridad a la siguiente automatización, la formación de los creadores o la campaña de concienciación.
## Recursos
**Documentos relacionados:**
+ [Entrega continua e implementación continua](https://aws.amazon.com/devops/continuous-delivery/)
+ [Socios con competencias en DevOps de 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)
+ [Socios con competencia en seguridad de 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 la seguridad de las aplicaciones
+ [Choosing a Well-Architected CI/CD approach](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) (Elección de un enfoque CI/CD bien diseñado)
+ [Monitoring CodeCommit events in Amazon EventBridge and Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) (Supervisión de eventos de CodeCommit en Amazon EventBridge y Amazon CloudWatch Events)
+ [Secrets detection in Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) (Revisión de la detección de secretos en Amazon CodeGuru)
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (Acelerar los despliegues en AWS con una gobernanza eficaz)
+ [How AWS approaches automating safe, hands-off deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) (Cómo AWS aborda la automatización de despliegues seguros y sin intervención)
**Vídeos relacionados: **
+ [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) (Sin intervención: automatización de canalizaciones de entrega continua en Amazon)
+ [Automating cross-account CI/CD pipelines](https://www.youtube.com/watch?v=AF-pSRSGNks) (Automatización de canalizaciones CI/CD entre cuentas)
**Ejemplos relacionados:**
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/) (Concienciación del sector para desarrolladores)
+ [AWS CodePipeline Governance](https://github.com/awslabs/aws-codepipeline-governance) (Gobernanza de AWS CodePipeline) (GitHub)
+ [Security for Developers workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) (Taller de seguridad para desarrolladores)
+ [AWS CI/CD Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) (Taller de CI/CD de AWS)
# SEC11-BP03 Realizar pruebas de penetración periódicas
Realice pruebas de penetración periódicas de su software. Este mecanismo ayuda a identificar posibles problemas de software que no pueden detectarse mediante pruebas automatizadas o una revisión manual del código. También puede ayudarle a comprender la eficacia de sus controles de detección. Las pruebas de penetración deben tratar de determinar si se puede hacer que el software realice operaciones inesperadas, como exponer datos que deberían estar protegidos o conceder permisos más amplios de lo esperado.
**Resultado deseado:** Las pruebas de penetración se utilizan para detectar, remediar y validar las propiedades de seguridad de la aplicación. Las pruebas de penetración periódicas y programadas deben formar parte del ciclo de vida de desarrollo de software (SDLC). Los hallazgos de las pruebas de penetración deben resolverse antes del lanzamiento del software. Debe analizar los resultados de las pruebas de penetración para identificar si hay problemas que podrían detectarse mediante la automatización. El uso de un proceso de pruebas de penetración periódicas y repetibles que incluya un mecanismo de retroalimentación activo ayuda a orientar a los creadores y mejora la calidad del software.
**Patrones comunes de uso no recomendados:**
+ Hacer pruebas de penetración solo para problemas de seguridad conocidos o frecuentes.
+ Hacer pruebas de penetración de aplicaciones sin herramientas ni bibliotecas de terceros dependientes.
+ Hacer pruebas de penetración solo para problemas de seguridad de paquete, sin evaluar la lógica empresarial implementada.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor confianza en las propiedades de seguridad del software antes de su lanzamiento.
+ Oportunidad de identificar los patrones de aplicación preferidos, lo que conduce a una mayor calidad del software.
+ Un ciclo de retroalimentación que identifica en una fase más temprana del ciclo de desarrollo dónde la automatización o la formación adicional podrían mejorar las propiedades de seguridad del software.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Las pruebas de penetración son un ejercicio estructurado de pruebas de seguridad en el que se ejecutan escenarios planificados de violación de la seguridad para detectar, remediar y validar los controles de seguridad. Las pruebas de penetración comienzan con el reconocimiento, durante el cual se recopilan datos basados en el diseño actual de la aplicación y sus dependencias. Luego, se elabora y ejecuta una lista seleccionada de escenarios de pruebas de seguridad. El objetivo principal de estas pruebas es descubrir problemas de seguridad en la aplicación, que podrían aprovecharse para obtener acceso no deseado a su entorno o acceso no autorizado a los datos. Debe llevar a cabo pruebas de penetración cuando lance nuevas características, o siempre que la aplicación haya sufrido cambios importantes en su funcionamiento o implementación técnica.
Debe identificar la etapa más apropiada del ciclo de vida de desarrollo en el que realizar las pruebas de penetración. Estas pruebas deben hacerse lo bastante tarde como para que la funcionalidad del sistema se aproxime al estado de lanzamiento previsto, pero con tiempo suficiente para solucionar cualquier problema.
### Pasos para la aplicación
+ Tenga un proceso estructurado para determinar el alcance de las pruebas de penetración. Basar este proceso en el [modelo de amenazas](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) es una buena forma de mantener el contexto.
+ Identifique la etapa más apropiada del ciclo de desarrollo en el que realizar las pruebas de penetración. Debería ser cuando se espera un cambio mínimo en la aplicación, pero con tiempo suficiente para llevar a cabo la corrección.
+ Forme a sus creadores sobre qué esperar de los resultados de las pruebas de penetración y cómo obtener información sobre la corrección.
+ Utilice herramientas para acelerar el proceso de las pruebas de penetración mediante la automatización de pruebas habituales o repetibles.
+ Analice los resultados de las pruebas de penetración con vistas a identificar problemas de seguridad sistémicos y utilice estos datos para efectuar pruebas automatizadas adicionales y para la formación continua de los creadores.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP01 Formar en seguridad de las aplicaciones](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ Las [pruebas de penetración de AWS](https://aws.amazon.com/security/penetration-testing/) ofrecen orientación detallada sobre las pruebas de penetración en AWS
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (Acelerar los despliegues en AWS con una gobernanza eficaz)
+ [Socios con competencia en seguridad de 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 your penetration testing architecture on AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/) (Modernice su arquitectura de pruebas de penetración en AWS Fargate)
+ [AWS Fault injection Simulator](https://aws.amazon.com/fis/)
**Ejemplos relacionados:**
+ [Automate API testing with AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (Automatización de las pruebas de API con AWS CodePipeline) (GitHub)
+ [Automated security helper](https://github.com/aws-samples/automated-security-helper) (Ayudante de seguridad automatizado) (GitHub)
# SEC11-BP04 Revisiones manuales del código
Realice una revisión manual del código del software que produce. Este proceso ayuda a verificar que la persona que ha escrito el código no es la única que comprueba su calidad.
**Resultado deseado:** La inclusión de un paso de revisión manual del código durante el desarrollo aumenta la calidad del software que se está escribiendo, ayuda a mejorar las competencias de los miembros con menos experiencia del equipo y da la oportunidad de identificar los puntos en los que se puede utilizar la automatización. Las revisiones manuales del código pueden apoyarse en herramientas y pruebas automatizadas.
**Patrones comunes de uso no recomendados:**
+ No revisar el código antes del despliegue.
+ Tener una misma persona que escriba y revise el código.
+ No utilizar la automatización para ayudar u organizar las revisiones del código.
+ No formar a los creadores sobre la seguridad de las aplicaciones antes de que revisen el código.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor calidad del código.
+ Mayor coherencia en el desarrollo del código gracias a la reutilización de estrategias comunes.
+ Reducción del número de problemas revelados durante las pruebas de penetración y etapas posteriores.
+ Mejora de la transferencia de conocimientos dentro del equipo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
La etapa de revisión debe implementarse como parte del flujo general de gestión del código. Los pormenores dependen del planteamiento utilizado para la bifurcación, las solicitudes de incorporación de cambios y la fusión. Utilice AWS CodeCommit o soluciones de terceros como GitHub, GitLab o Bitbucket. Sea cual sea el método que utilice, es importante verificar que sus procesos requieren la revisión del código antes de desplegarlo en un entorno de producción. El uso de herramientas como [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) puede facilitar la organización del proceso de revisión del código.
### Pasos para la aplicación
+ Implemente un paso de revisión manual como parte del flujo de administración de código y realice esta revisión antes de continuar.
+ Considere [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para administrar y ayudar en las revisiones de código.
+ Implemente un flujo de aprobación que exija que se complete una revisión del código antes de que este pueda pasar a la siguiente etapa.
+ Compruebe que existe un proceso para identificar los problemas encontrados durante las revisiones manuales del código que podrían detectarse automáticamente.
+ Integre el paso de revisión manual del código de forma que se ajuste a sus prácticas de desarrollo de código.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Working with pull requests in AWS CodeCommit repositories](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) (Trabajo con solicitudes de incorporación de cambios en repositorios de AWS CodeCommit)
+ [Working with approval rule templates in AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) (Trabajar con plantillas de reglas de aprobación en AWS CodeCommit)
+ [About pull requests in GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (Acerca de las solicitudes de incorporación de cambios en GitHub)
+ [ Automate code reviews with Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)(Revisiones automáticas de código con Amazon CodeGuru Reviewer)
+ [Automating detection of security vulnerabilities and bugs in CI/CD pipelines using Amazon CodeGuru Reviewer CLI](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/) (Automatización de la detección de vulnerabilidades y errores de seguridad en los procesos CI/CD mediante la CLI de Amazon CodeGuru Reviewer)
**Vídeos relacionados: **
+ [Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) (Mejora continua de la calidad del código con Amazon CodeGuru)
**Ejemplos relacionados:**
+ [Security for Developers workshop](https://catalog.workshops.aws/sec4devs) (Taller de seguridad para desarrolladores)
# SEC11-BP05 Centralizar los servicios para paquetes y dependencias
Proporcione servicios centralizados para que los equipos de creadores obtengan paquetes de software y otras dependencias. De este modo, se podrán validar los paquetes antes de incluirlos en el software que escriba y se dispondrá de un origen de datos para el análisis del software que se utiliza en su organización.
**Resultado deseado:** El software se compone de un conjunto de otros paquetes de software además del código que se escribe. Esto facilita el consumo de implementaciones de funcionalidades que se utilizan repetidamente, como un analizador JSON o una biblioteca de cifrado. La centralización lógica de los orígenes de estos paquetes y dependencias proporciona un mecanismo para que los equipos de seguridad validen las propiedades de los paquetes antes de utilizarlos. Este planteamiento también reduce el riesgo de que se produzca un problema inesperado debido a un cambio en un paquete existente o a la inclusión por equipos de creadores de paquetes arbitrarios directamente desde Internet. Utilice este planteamiento junto con los flujos de pruebas manuales y automatizadas para aumentar la confianza en la calidad del software que desarrolla.
**Patrones comunes de uso no recomendados:**
+ Obtener paquetes de repositorios arbitrarios de Internet.
+ No probar nuevos paquetes antes de ponerlos a disposición de los desarrolladores.
**Beneficios de establecer esta práctica recomendada:**
+ Mejor comprensión de los paquetes que se utilizan en el software que se crea.
+ Poder notificar a los equipos de carga de trabajo cuándo es necesario actualizar un paquete basándose en la comprensión de quién utiliza qué.
+ Reducción del riesgo de que se incluya en el software un paquete con problemas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Proporcione servicios centralizados para paquetes y dependencias de una manera que resulte sencilla de consumir a los creadores. Los servicios centralizados pueden ser lógicamente centrales en lugar de implementarse como un sistema monolítico. Este método le permite proporcionar servicios de una manera que satisfaga las necesidades de los creadores. Debe implementar una forma eficaz de añadir paquetes al repositorio cuando se produzcan actualizaciones o surjan nuevos requisitos. Los servicios de AWS como [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) o soluciones similares de socios de AWS son una forma de ofrecer esta capacidad.
### Pasos para la aplicación:
+ Implemente un servicio de repositorio lógicamente centralizado que esté disponible en todos los entornos en los que se desarrolla software.
+ Incluya el acceso al repositorio como parte del proceso de aprovisionamiento de cuentas de Cuenta de AWS.
+ Consolide la automatización para probar paquetes antes de que se publiquen en un repositorio.
+ Mantenga métricas de los paquetes, lenguajes y equipos más utilizados y con mayor cantidad de cambios.
+ Proporcione un mecanismo automatizado para que los equipos de creación soliciten nuevos paquetes y proporcionen comentarios.
+ Analice periódicamente los paquetes del repositorio para identificar la posible repercusión de los problemas que se acaban de detectar.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (Acelerar los despliegues en AWS con una gobernanza eficaz)
+ [Tighten your package security with CodeArtifact Package Origin Control toolkit](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/) (Refuerce la seguridad de sus paquetes con el kit de herramientas de control de origen de paquetes de CodeArtifact)
+ [Detecting security issues in logging with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) (Detección de problemas de seguridad en el registro con Amazon CodeGuru Reviewer)
+ [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/) (Niveles de la cadena de suministro de artefactos de software [SLSA])
**Vídeos relacionados: **
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (Seguridad proactiva: consideraciones y estrategias)
+ [The AWS Philosophy of Security (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) (La filosofía de seguridad de AWS [re:Invent 2017])
+ [When security, safety, and urgency all matter: Handling Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) (Cuando la seguridad, la protección y la urgencia son importantes: gestión de Log4Shell)
**Ejemplos relacionados:**
+ [Multi Region Package Publishing Pipeline](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (Canalización de publicación de paquetes multirregión) [GitHub] )
+ [Publishing Node.js Modules on AWS CodeArtifact using AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (Publicación de módulos Node.js en AWS CodeArtifact con AWS CodePipeline) (GitHub)
+ [AWS CDK Java CodeArtifact Pipeline Sample](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (Ejemplo de canalización de CodeArtifact en Java en AWS CDK) (GitHub)
+ [Distribute private .NET NuGet packages with AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (Distribuir paquetes NuGet .NET privados con AWS CodeArtifact) (GitHub)
# SEC11-BP06 Desplegar software mediante programación
Siempre que sea posible, realice los despliegues de software mediante programación. Con este enfoque se reduce la probabilidad de que se produzca un error en el despliegue o de que surja un problema inesperado debido a un error humano.
**Resultado deseado:** Mantener a las personas alejadas de los datos es un principio clave para crear de forma segura en la Nube de AWS. Este principio incluye la forma de desplegar el software.
La ventaja de no depender de personas para desplegar el software es que tendrá mayor confianza en que se ha probado lo que se despliega, y que el despliegue se realice siempre de forma coherente. No tendrá que modificar el software para que funcione en distintos entornos. El uso de los principios del desarrollo de aplicaciones de doce factores, en concreto la externalización de la configuración, le permite desplegar el mismo código en varios entornos sin necesidad de realizar cambios. La firma criptográfica de los paquetes de software es una buena forma de verificar que no ha cambiado nada entre entornos. El resultado general de este método es que se reduce el riesgo en el proceso de cambio y mejorar la coherencia de las versiones de software.
**Patrones comunes de uso no recomendados:**
+ Despliegue manual del software en producción.
+ Realización manual de cambios en el software para adaptarlo a distintos entornos.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor confianza en el proceso de lanzamiento de software.
+ Reducción del riesgo de que un cambio erróneo afecte a las funciones de la empresa.
+ Aumento de la cadencia de lanzamiento debido al menor riesgo del cambio.
+ Capacidad de reversión automática en caso de imprevistos durante el despliegue.
+ Capacidad para demostrar criptográficamente que el software probado es el software desplegado.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Cree su estructura de cuenta de Cuenta de AWS de forma que elimine el acceso humano persistente desde los entornos y utilice herramientas de CI/CD para realizar los despliegues. Diseñe las aplicaciones de manera que los datos de configuración específicos del entorno se obtengan de un origen externo, como el [Parameter Store de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Firme los paquetes después de probarlos y valide estas firmas durante el despliegue. Configure las canalizaciones de CI/CD para que envíen el código de la aplicación y utilice valores controlados para confirmar que el despliegue ha tenido lugar como corresponde. Utilice herramientas como [AWS CloudFormation](https://aws.amazon.com/cloudformation/) o [AWS CDK](https://aws.amazon.com/cdk/) para definir su infraestructura y, a continuación, use [AWS CodeBuild](https://aws.amazon.com/codebuild/) y [AWS CodePipeline](https://aws.amazon.com/codepipeline/) para realizar las operaciones de CI/CD.
### Pasos para la aplicación
+ Cree canalizaciones de CI/CD bien definidas para agilizar el proceso de despliegue.
+ Proporcione capacidad de CI/CD para simplificar la integración de las pruebas de seguridad en las canalizaciones con [AWS CodeBuild](https://aws.amazon.com/codebuild/) y [AWS Code Pipeline](https://aws.amazon.com/codepipeline/).
+ Siga las directrices sobre separación de entornos del documento técnico [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) (Organización del entorno de AWS con varias cuentas).
+ Verifique que no haya acceso humano persistente a los entornos donde se ejecutan las cargas de trabajo de producción.
+ Diseñe las aplicaciones de modo que admitan la externalización de datos de configuración.
+ Piense en la posibilidad de llevar a cabo el despliegue mediante un modelo de despliegue azul-verde.
+ Implemente valores controlados para validar el despliegue correcto del software.
+ Utilice herramientas criptográficas como [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) para firmar y verificar los paquetes de software que está desplegando.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [AWS CI/CD Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) (Taller de CI/CD de AWS)
+ [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) (Acelerar los despliegues en AWS con una gobernanza eficaz)
+ [Automatización de implementaciones seguras y sin intervención](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Code signing using AWS Certificate Manager Private CA and AWS Key Management Service asymmetric keys](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) (Firma de código mediante CA privada de AWS Certificate Manager y claves asimétricas deAWS Key Management Service)
+ [Code Signing, a Trust and Integrity Control for AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) (Firma de código, un control de confianza e integridad para AWS Lambda)
**Vídeos relacionados: **
+ [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) (Sin intervención: automatización de canalizaciones de entrega continua en Amazon)
**Ejemplos relacionados:**
+ [Blue/Green deployments with AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) Despliegues azul-verde AWS Fargate)
# SEC11-BP07 Evaluar periódicamente las propiedades de seguridad de las canalizaciones
Aplique los principios del pilar de seguridad de Well-Architected a sus canalizaciones, prestando especial atención a la separación de permisos. Evalúe periódicamente las propiedades de seguridad de su infraestructura de canalización. La administración eficaz de la seguridad *de* las canalizaciones le permite garantizar la seguridad del software que pasa *por* ellas.
**Resultado deseado:** Las canalizaciones utilizadas para crear y desplegar el software deben seguir las mismas prácticas recomendadas que cualquier otra carga de trabajo en su entorno. Los desarrolladores no deben poder editar las pruebas que se implementan en las canalizaciones que utilizan. Las canalizaciones solo deben tener los permisos necesarios para los despliegues que están realizando y debe implementar salvaguardas para evitar que se desplieguen en los entornos equivocados. Las canalizaciones no deben depender de credenciales a largo plazo; además, deben estar configuradas para emitir estado de forma que se pueda validar la integridad de los entornos de compilación.
**Patrones comunes de uso no recomendados:**
+ Pruebas de seguridad que los creadores pueden omitir.
+ Permisos demasiado amplios para las canalizaciones de despliegue.
+ Canalizaciones no configuradas para validar entradas.
+ No revisar periódicamente los permisos asociados a la infraestructura de CI/CD.
+ Uso de credenciales a largo plazo o codificadas.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor confianza en la integridad del software que se construye y despliega a través de las canalizaciones.
+ Capacidad de detener un despliegue cuando hay actividades sospechosas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Comience con servicios de CI/CD administrados que admiten roles de IAM para reducir el riesgo de fuga de credenciales. La aplicación de los principios del pilar de seguridad a la infraestructura de canalización de CI/CD puede ayudarle a determinar dónde es posible realizar mejoras de seguridad. Siga la [arquitectura de referencia de canalizaciones de despliegue de AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). Es un buen punto de partida para crear entornos de CI/CD. Revise a intervalos regulares la implementación de la canalización y analice los registros para detectar comportamientos inesperados; esto puede ayudarle a comprender los patrones de uso de las canalizaciones que se utilizan para desplegar software.
### Pasos para la aplicación
+ Empiece con la [arquitectura de referencia de canalizaciones de despliegue de AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/).
+ Plantéese la posibilidad de utilizar [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) para generar mediante programación políticas de IAM de privilegios mínimos para las canalizaciones.
+ Integre las canalizaciones con monitorización y alertas para que recibir notificaciones de actividad inesperada o anómala. Para los servicios administrados de AWS, [Amazon EventBridge](https://aws.amazon.com/eventbridge/) le permite enrutar datos a destinos como [AWS Lambda](https://aws.amazon.com/lambda/) o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS).
## Recursos
**Documentos relacionados:**
+ [AWS Deployment Pipelines Reference Architecture](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) (Arquitectura de referencia de canalizaciones de despliegue de AWS)
+ [Monitoring AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) (Monitorización de AWS CodePipeline)
+ [Security best practices for AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) (Prácticas recomendadas de seguridad de AWS CodePipeline)
**Ejemplos relacionados:**
+ [DevOps monitoring dashboard](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (Panel de monitorización de DevOps) (GitHub)
# SEC11-BP08 Crear un programa que integre la propiedad de la seguridad en los equipos de la carga de trabajo
Elabore un programa o un mecanismo que permita a los equipos de creadores tomar decisiones de seguridad sobre el software que crean. Aún así, su equipo de seguridad debe validar estas decisiones durante una revisión, pero integrar la propiedad de la seguridad en los equipos de creadores permite crear cargas de trabajo más rápidas y seguras. Este mecanismo también fomenta una cultura de propiedad que repercute positivamente en el funcionamiento de los sistemas que se crean.
**Resultado deseado:** Para integrar la propiedad de la seguridad y la toma de decisiones en los equipos de creación, puede formar a los creadores sobre cómo pensar en la seguridad o puede mejorar su formación con personal de seguridad integrado o asociado a los equipos de creación. Cualquiera de las dos estrategias es válida y permite al equipo tomar decisiones de seguridad de mayor calidad en una fase más temprana del ciclo de desarrollo. Este modelo de propiedad se basa en la formación para lograr la seguridad de las aplicaciones. Empiece con el modelo de amenazas para la carga de trabajo concreta, lo que ayudará a dirigir el enfoque de diseño al contexto apropiado. Otra ventaja de contar con una comunidad de desarrolladores centrados en la seguridad, o con un grupo de ingenieros de seguridad que trabajen con equipos de creadores, es que es posible comprender más a fondo cómo se escribe el software. Esta comprensión le ayuda a determinar las próximas áreas de mejora en su capacidad de automatización.
**Patrones comunes de uso no recomendados:**
+ Dejar todas las decisiones del diseño de la seguridad en manos del equipo de seguridad.
+ No hacer frente a los requisitos de seguridad con suficiente antelación en el proceso de desarrollo.
+ No obtener comentarios de los creadores y del personal de seguridad sobre el funcionamiento del programa.
**Beneficios de establecer esta práctica recomendada:**
+ Reducción del tiempo necesario para completar las revisiones de seguridad.
+ Reducción de los problemas de seguridad que solo se detectan en la fase de revisión de la seguridad.
+ Mejora de la calidad general del software que se escribe.
+ Oportunidad de identificar y comprender problemas sistémicos o áreas de mejora de alto valor.
+ Reducción de la cantidad de tareas que es necesario repetir debido a los hallazgos de la revisión de seguridad.
+ Mejora de la percepción de la función de seguridad.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** bajo
## Guía para la implementación
Empiece con la orientación de [SEC11-BP01 Formar en seguridad de las aplicaciones](sec_appsec_train_for_application_security.md). A continuación, identifique el modelo operativo para el programa que crea que puede funcionar mejor para su organización. Los dos modelos principales son formar a los desarrolladores o integrar al personal de seguridad en los equipos de creadores. Una vez que haya decidido el abordaje inicial, deberá realizar una prueba piloto con uno o un pequeño grupo de equipos de carga de trabajo para comprobar que el modelo funciona en su organización. El apoyo de los líderes de los departamentos de creación y seguridad de la organización contribuye a la implantación y al éxito del programa. A medida que cree este programa, es importante elegir métricas que sirvan para mostrar el valor del programa. Aprender de cómo AWS ha tratado este problema es una buena experiencia de aprendizaje. Esta práctica recomendada se centra en gran medida en la cultura y el cambio organizativo. Las herramientas que emplee deben apoyar la colaboración entre las comunidades de creadores y de seguridad.
### Pasos para la aplicación
+ Empiece por formar a los desarrolladores en la seguridad para las aplicaciones.
+ Cree una comunidad y un programa de incorporación para educar a los creadores.
+ Elija un nombre para el programa. Los más utilizados son «Guardians», «Champions» o «Advocates».
+ Identifique el modelo a utilizar: formar a los desarrolladores, incorporar ingenieros de seguridad o tener roles de seguridad afines.
+ Identifique a los patrocinadores del proyecto entre los encargados de la seguridad, los creadores y, quizá, otros grupos pertinentes.
+ Haga un seguimiento del número de personas que participan en el programa, el tiempo necesario para las revisiones y los comentarios de los creadores y el personal de seguridad. Utilice estas métricas para acometer mejoras.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC11-BP01 Formar en seguridad de las aplicaciones](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automatizar las pruebas a lo largo del ciclo de vida de desarrollo y lanzamiento](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documentos relacionados:**
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (Cómo abordar el modelado de amenazas)
+ [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) (Cómo concebir la gobernanza de la seguridad en la nube)
**Vídeos relacionados: **
+ [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) (Seguridad proactiva: consideraciones y estrategias)