# SEC 11. How do you incorporate and validate the security properties of applications throughout the design, development, and deployment lifecycle? Training people, testing using automation, understanding dependencies, and validating the security properties of tools and applications help to reduce the likelihood of security issues in production workloads. **Topics** + [ # SEC11-BP01 Train for application security ](sec_appsec_train_for_application_security.md) + [ # SEC11-BP02 Automate testing throughout the development and release lifecycle ](sec_appsec_automate_testing_throughout_lifecycle.md) + [ # SEC11-BP03 Perform regular penetration testing ](sec_appsec_perform_regular_penetration_testing.md) + [ # SEC11-BP04 Manual code reviews ](sec_appsec_manual_code_reviews.md) + [ # SEC11-BP05 Centralize services for packages and dependencies ](sec_appsec_centralize_services_for_packages_and_dependencies.md) + [ # SEC11-BP06 Deploy software programmatically ](sec_appsec_deploy_software_programmatically.md) + [ # SEC11-BP07 Regularly assess security properties of the pipelines ](sec_appsec_regularly_assess_security_properties_of_pipelines.md) + [ # SEC11-BP08 Build a program that embeds security ownership in workload teams ](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md) # SEC11-BP01 Train for application security SEC11-BP01 Train for application security Provide training to the builders in your organization on common practices for the secure development and operation of applications. Adopting security focused development practices helps reduce the likelihood of issues that are only detected at the security review stage. **Desired outcome:** Software should be designed and built with security in mind. When the builders in an organization are trained on secure development practices that start with a threat model, it improves the overall quality and security of the software produced. This approach can reduce the time to ship software or features because less rework is needed after the security review stage. For the purposes of this best practice, *secure development* refers to the software that is being written and the tools or systems that support the software development lifecycle (SDLC). **Common anti-patterns:** + Waiting until a security review, and then considering the security properties of a system. + Leaving all security decisions to the security team. + Failing to communicate how the decisions taken in the SDLC relate to the overall security expectations or policies of the organization. + Engaging in the security review process too late. **Benefits of establishing this best practice:** + Better knowledge of the organizational requirements for security early in the development cycle. + Being able to identify and remediate potential security issues faster, resulting in a quicker delivery of features. + Improved quality of software and systems. **Level of risk exposed if this best practice is not established:** Medium ## Implementation guidance Implementation guidance Provide training to the builders in your organization. Starting off with a course on [threat modeling](https://catalog.workshops.aws/threatmodel/en-US) is a good foundation for helping train for security. Ideally, builders should be able to self-serve access to information relevant to their workloads. This access helps them make informed decisions about the security properties of the systems they build without needing to ask another team. The process for engaging the security team for reviews should be clearly defined and simple to follow. The steps in the review process should be included in the security training. Where known implementation patterns or templates are available, they should be simple to find and link to the overall security requirements. Consider using [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) [AWS Cloud Development Kit (AWS CDK) Constructs](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), [Service Catalog](https://aws.amazon.com/servicecatalog/), or other templating tools to reduce the need for custom configuration. ### Implementation steps Implementation steps + Start builders with a course on [threat modeling](https://catalog.workshops.aws/threatmodel/en-US) to build a good foundation, and help train them on how to think about security. + Provide access to [AWS Training 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), industry, or AWS Partner training. + Provide training on your organization's security review process, which clarifies the division of responsibilities between the security team, workload teams, and other stakeholders. + Publish self-service guidance on how to meet your security requirements, including code examples and templates, if available. + Regularly obtain feedback from builder teams on their experience with the security review process and training, and use that feedback to improve. + Use game days or bug bash campaigns to help reduce the number of issues, and increase the skills of your builders. ## Resources Resources **Related best practices:** + [SEC11-BP08 Build a program that embeds security ownership in workload teams](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md) **Related documents:** + [AWS Training 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) + [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) + [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) + [Accelerating training – The AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html) **Related videos:** + [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) **Related examples:** + [Workshop on threat modeling](https://catalog.workshops.aws/threatmodel) + [Industry awareness for developers](https://owasp.org/www-project-top-ten/) **Related services:** + [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + [AWS Cloud Development Kit (AWS CDK) (AWS CDK) Constructs](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 Automate testing throughout the development and release lifecycle SEC11-BP02 Automate testing throughout the development and release lifecycle Automate the testing for security properties throughout the development and release lifecycle. Automation makes it easier to consistently and repeatably identify potential issues in software prior to release, which reduces the risk of security issues in the software being provided. **Desired outcome: ** The goal of automated testing is to provide a programmatic way of detecting potential issues early and often throughout the development lifecycle. When you automate regression testing, you can rerun functional and non-functional tests to verify that previously tested software still performs as expected after a change. When you define security unit tests to check for common misconfigurations, such as broken or missing authentication, you can identify and fix these issues early in the development process. Test automation uses purpose-built test cases for application validation, based on the application’s requirements and desired functionality. The result of the automated testing is based on comparing the generated test output to its respective expected output, which expedites the overall testing lifecycle. Testing methodologies such as regression testing and unit test suites are best suited for automation. Automating the testing of security properties allows builders to receive automated feedback without having to wait for a security review. Automated tests in the form of static or dynamic code analysis can increase code quality and help detect potential software issues early in the development lifecycle. **Common anti-patterns: ** + Not communicating the test cases and test results of the automated testing. + Performing the automated testing only immediately prior to a release. + Automating test cases with frequently changing requirements. + Failing to provide guidance on how to address the results of security tests. **Benefits of establishing this best practice: ** + Reduced dependency on people evaluating the security properties of systems. + Having consistent findings across multiple workstreams improves consistency. + Reduced likelihood of introducing security issues into production software. + Shorter window of time between detection and remediation due to catching software issues earlier. + Increased visibility of systemic or repeated behavior across multiple workstreams, which can be used to drive organization-wide improvements. ** Level of risk exposed if this best practice is not established: **Medium ## Implementation guidance Implementation guidance As you build your software, adopt various mechanisms for software testing to ensure that you are testing your application for both functional requirements, based on your application’s business logic, and non-functional requirements, which are focused on application reliability, performance, and security. Static application security testing (SAST) analyzes your source code for anomalous security patterns, and provides indications for defect prone code. SAST relies on static inputs, such as documentation (requirements specification, design documentation, and design specifications) and application source code to test for a range of known security issues. Static code analyzers can help expedite the analysis of large volumes of code. The [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) provides a comparison of [Source Code Security Analyzers](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), which includes open source tools for [Byte Code Scanners](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) and [Binary Code Scanners](https://samate.nist.gov/index.php/Binary_Code_Scanners.html). Complement your static testing with dynamic analysis security testing (DAST) methodologies, which performs tests against the running application to identify potentially unexpected behavior. Dynamic testing can be used to detect potential issues that are not detectable via static analysis. Testing at the code repository, build, and pipeline stages allows you to check for different types of potential issues from entering into your code. [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) provides code recommendations, including security scanning, in the builder’s IDE. [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) can identify critical issues, security issues, and hard-to-find bugs during application development, and provides recommendations to improve code quality. The [Security for Developers workshop](https://catalog.workshops.aws/sec4devs) uses AWS developer tools, such as [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/), and [AWS CodePipeline](https://aws.amazon.com/codepipeline/), for release pipeline automation that includes SAST and DAST testing methodologies. As you progress through your SDLC, establish an iterative process that includes periodic application reviews with your security team. Feedback gathered from these security reviews should be addressed and validated as part of your release readiness review. These reviews establish a robust application security posture, and provide builders with actionable feedback to address potential issues. ### Implementation steps Implementation steps + Implement consistent IDE, code review, and CI/CD tools that include security testing. + Consider where in the SDLC it is appropriate to block pipelines instead of just notifying builders that issues need to be remediated. + The [Security for Developers workshop](https://catalog.workshops.aws/sec4devs) provides an example of integrating static and dynamic testing into a release pipeline. + Performing testing or code analysis using automated tools, such as [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrated with developer IDEs, and [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) for scanning code on commit, helps builders get feedback at the right time. + When building using AWS Lambda, you can use [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) to scan the application code in your functions. + When automated testing is included in CI/CD pipelines, you should use a ticketing system to track the notification and remediation of software issues. + For security tests that might generate findings, linking to guidance for remediation helps builders improve code quality. + Regularly analyze the findings from automated tools to prioritize the next automation, builder training, or awareness campaign. ## Resources Resources **Related documents:** + [Continuous Delivery and Continuous Deployment](https://aws.amazon.com/devops/continuous-delivery/) + [AWS DevOps Competency Partners](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) + [AWS Security Competency Partners](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) for Application Security + [Choosing a Well-Architected CI/CD approach](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/) + [Monitoring CodeCommit events in Amazon EventBridge and Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html) + [Secrets detection in Amazon CodeGuru Review](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection) + [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) + [How AWS approaches automating safe, hands-off deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) **Related videos:** + [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) + [Automating cross-account CI/CD pipelines](https://www.youtube.com/watch?v=AF-pSRSGNks) **Related examples:** + [Industry awareness for developers](https://owasp.org/www-project-top-ten/) + [AWS CodePipeline Governance](https://github.com/awslabs/aws-codepipeline-governance) (GitHub) + [Security for Developers workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US) # SEC11-BP03 Perform regular penetration testing SEC11-BP03 Perform regular penetration testing Perform regular penetration testing of your software. This mechanism helps identify potential software issues that cannot be detected by automated testing or a manual code review. It can also help you understand the efficacy of your detective controls. Penetration testing should try to determine if the software can be made to perform in unexpected ways, such as exposing data that should be protected, or granting broader permissions than expected. **Desired outcome:** Penetration testing is used to detect, remediate, and validate your application’s security properties. Regular and scheduled penetration testing should be performed as part of the software development lifecycle (SDLC). The findings from penetration tests should be addressed prior to the software being released. You should analyze the findings from penetration tests to identify if there are issues that could be found using automation. Having a regular and repeatable penetration testing process that includes an active feedback mechanism helps inform the guidance to builders and improves software quality. **Common anti-patterns: ** + Only penetration testing for known or prevalent security issues. + Penetration testing applications without dependent third-party tools and libraries. + Only penetration testing for package security issues, and not evaluating implemented business logic. **Benefits of establishing this best practice:** + Increased confidence in the security properties of the software prior to release. + Opportunity to identify preferred application patterns, which leads to greater software quality. + A feedback loop that identifies earlier in the development cycle where automation or additional training can improve the security properties of software. ** Level of risk exposed if this best practice is not established: **High ## Implementation guidance Implementation guidance Penetration testing is a structured security testing exercise where you run planned security breach scenarios to detect, remediate, and validate security controls. Penetration tests start with reconnaissance, during which data is gathered based on the current design of the application and its dependencies. A curated list of security-specific testing scenarios are built and run. The key purpose of these tests is to uncover security issues in your application, which could be exploited for gaining unintended access to your environment, or unauthorized access to data. You should perform penetration testing when you launch new features, or whenever your application has undergone major changes in function or technical implementation. You should identify the most appropriate stage in the development lifecycle to perform penetration testing. This testing should happen late enough that the functionality of the system is close to the intended release state, but with enough time remaining for any issues to be remediated. ### Implementation steps Implementation steps + Have a structured process for how penetration testing is scoped, basing this process on the [threat model](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) is a good way of maintaining context. + Identify the appropriate place in the development cycle to perform penetration testing. This should be when there is minimal change expected in the application, but with enough time to perform remediation. + Train your builders on what to expect from penetration testing findings, and how to get information on remediation. + Use tools to speed up the penetration testing process by automating common or repeatable tests. + Analyze penetration testing findings to identify systemic security issues, and use this data to inform additional automated testing and ongoing builder education. ## Resources Resources **Related best practices:** + [SEC11-BP01 Train for application security](sec_appsec_train_for_application_security.md) + [SEC11-BP02 Automate testing throughout the development and release lifecycle](sec_appsec_automate_testing_throughout_lifecycle.md) **Related documents:** + [AWS Penetration Testing](https://aws.amazon.com/security/penetration-testing/) provides detailed guidance for penetration testing on AWS + [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) + [AWS Security Competency Partners](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/) + [AWS Fault injection Simulator](https://aws.amazon.com/fis/) **Related examples:** + [Automate API testing with AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub) + [Automated security helper](https://github.com/aws-samples/automated-security-helper) (GitHub) # SEC11-BP04 Manual code reviews SEC11-BP04 Manual code reviews Perform a manual code review of the software that you produce. This process helps verify that the person who wrote the code is not the only one checking the code quality. **Desired outcome:** Including a manual code review step during development increases the quality of the software being written, helps upskill less experienced members of the team, and provides an opportunity to identify places where automation can be used. Manual code reviews can be supported by automated tools and testing. **Common anti-patterns:** + Not performing reviews of code before deployment. + Having the same person write and review the code. + Not using automation to assist or orchestrate code reviews. + Not training builders on application security before they review code. **Benefits of establishing this best practice:** + Increased code quality. + Increased consistency of code development through reuse of common approaches. + Reduction in the number of issues discovered during penetration testing and later stages. + Improved knowledge transfer within the team. **Level of risk exposed if this best practice is not established:** Medium ## Implementation guidance Implementation guidance The review step should be implemented as part of the overall code management flow. The specifics depend on the approach used for branching, pull-requests, and merging. You might be using AWS CodeCommit or third-party solutions such as GitHub, GitLab, or Bitbucket. Whatever method you use, it’s important to verify that your processes require the review of code before it’s deployed in a production environment. Using tools such as [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) can make it easier to orchestrate the code review process. ### Implementation steps Implementation steps + Implement a manual review step as part of your code management flow and perform this review before proceeding. + Consider [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) for managing and assisting in code reviews. + Implement an approval flow that requires a code review being completed before code can progress to the next stage. + Verify there is a process to identify issues being found during manual code reviews that could be detected automatically. + Integrate the manual code review step in a way that aligns with your code development practices. ## Resources Resources **Related best practices:** + [SEC11-BP02 Automate testing throughout the development and release lifecycle](sec_appsec_automate_testing_throughout_lifecycle.md) **Related documents:** + [Working with pull requests in AWS CodeCommit repositories](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html) + [Working with approval rule templates in AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html) + [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) + [Automate code reviews with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-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/) **Related videos:** + [Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw) **Related examples:** + [Security for Developers workshop](https://catalog.workshops.aws/sec4devs) # SEC11-BP05 Centralize services for packages and dependencies SEC11-BP05 Centralize services for packages and dependencies Provide centralized services for builder teams to obtain software packages and other dependencies. This allows the validation of packages before they are included in the software that you write, and provides a source of data for the analysis of the software being used in your organization. **Desired outcome:** Software is comprised of a set of other software packages in addition to the code that is being written. This makes it simple to consume implementations of functionality that are repeatedly used, such as a JSON parser or an encryption library. Logically centralizing the sources for these packages and dependencies provides a mechanism for security teams to validate the properties of the packages before they are used. This approach also reduces the risk of an unexpected issue being caused by a change in an existing package, or by builder teams including arbitrary packages directly from the internet. Use this approach in conjunction with the manual and automated testing flows to increase the confidence in the quality of the software that is being developed. **Common anti-patterns:** + Pulling packages from arbitrary repositories on the internet. + Not testing new packages before making them available to builders. **Benefits of establishing this best practice:** + Better understanding of what packages are being used in the software being built. + Being able to notify workload teams when a package needs to be updated based on the understanding of who is using what. + Reducing the risk of a package with issues being included in your software. **Level of risk exposed if this best practice is not established: **Medium ## Implementation guidance Implementation guidance Provide centralized services for packages and dependencies in a way that is simple for builders to consume. Centralized services can be logically central rather than implemented as a monolithic system. This approach allows you to provide services in a way that meets the needs of your builders. You should implement an efficient way of adding packages to the repository when updates happen or new requirements emerge. AWS services such as [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) or similar AWS partner solutions provide a way of delivering this capability. ### Implementation steps: Implementation steps: + Implement a logically centralized repository service that is available in all of the environments where software is developed. + Include access to the repository as part of the AWS account vending process. + Build automation to test packages before they are published in a repository. + Maintain metrics of the most commonly used packages, languages, and teams with the highest amount of change. + Provide an automated mechanism for builder teams to request new packages and provide feedback. + Regularly scan packages in your repository to identify the potential impact of newly discovered issues. ## Resources Resources **Related best practices:** + [SEC11-BP02 Automate testing throughout the development and release lifecycle](sec_appsec_automate_testing_throughout_lifecycle.md) **Related documents:** + [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) + [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/) + [Detecting security issues in logging with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/) + [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/) **Related videos:** + [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag) + [The AWS Philosophy of Security (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U) + [When security, safety, and urgency all matter: Handling Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg) **Related examples:** + [Multi Region Package Publishing Pipeline](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub) + [Publishing Node.js Modules on AWS CodeArtifact using AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub) + [AWS CDK Java CodeArtifact Pipeline Sample](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub) + [Distribute private .NET NuGet packages with AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub) # SEC11-BP06 Deploy software programmatically SEC11-BP06 Deploy software programmatically Perform software deployments programmatically where possible. This approach reduces the likelihood that a deployment fails or an unexpected issue is introduced due to human error. **Desired outcome: **Keeping people away from data is a key principle of building securely in the AWS Cloud. This principle includes how you deploy your software. The benefits of not relying on people to deploy software is the greater confidence that what you tested is what gets deployed, and that the deployment is performed consistently every time. The software should not need to be changed to function in different environments. Using the principles of twelve-factor application development, specifically the externalizing of configuration, allows you to deploy the same code to multiple environments without requiring changes. Cryptographically signing software packages is a good way to verify that nothing has changed between environments. The overall outcome of this approach is to reduce risk in your change process and improve the consistency of software releases. **Common anti-patterns: ** + Manually deploying software into production. + Manually performing changes to software to cater to different environments. **Benefits of establishing this best practice: ** + Increased confidence in the software release process. + Reduced risk of a failed change impacting business functionality. + Increased release cadence due to lower change risk. + Automatic rollback capability for unexpected events during deployment. + Ability to cryptographically prove that the software that was tested is the software deployed. **Level of risk exposed if this best practice is not established:** High ## Implementation guidance Implementation guidance Build your AWS account structure to remove persistent human access from environments and use CI/CD tools to perform deployments. Architect your applications so that environment-specific configuration data is obtained from an external source, such as [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Sign packages after they have been tested, and validate these signatures during deployment. Configure your CI/CD pipelines to push application code and use canaries to confirm successful deployment. Use tools such as [AWS CloudFormation](https://aws.amazon.com/cloudformation/) or [AWS CDK](https://aws.amazon.com/cdk/) to define your infrastructure, then use [AWS CodeBuild](https://aws.amazon.com/codebuild/) and [AWS CodePipeline](https://aws.amazon.com/codepipeline/) to perform CI/CD operations. ### Implementation steps Implementation steps + Build well-defined CI/CD pipelines to streamline the deployment process. + Using [AWS CodeBuild](https://aws.amazon.com/codebuild/) and [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) to provide CI/CD capability makes it simple to integrate security testing into your pipelines. + Follow the guidance on separation of environments in the [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) whitepaper. + Verify no persistent human access to environments where production workloads are running. + Architect your applications to support the externalization of configuration data. + Consider deploying using a blue/green deployment model. + Implement canaries to validate the successful deployment of software. + Use cryptographic tools such as [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) or [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) to sign and verify the software packages that you are deploying. ## Resources Resources **Related best practices:** + [SEC11-BP02 Automate testing throughout the development and release lifecycle](sec_appsec_automate_testing_throughout_lifecycle.md) **Related documents:** + [AWS CI/CD Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) + [Accelerate deployments on AWS with effective governance](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/) + [Automating safe, hands-off deployments](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/) + [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/) **Related videos:** + [Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY) **Related examples:** + [Blue/Green deployments with AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US) # SEC11-BP07 Regularly assess security properties of the pipelines SEC11-BP07 Regularly assess security properties of the pipelines Apply the principles of the Well-Architected Security Pillar to your pipelines, with particular attention to the separation of permissions. Regularly assess the security properties of your pipeline infrastructure. Effectively managing the security *of* the pipelines allows you to deliver the security of the software that passes *through* the pipelines. **Desired outcome: **The pipelines used to build and deploy your software should follow the same recommended practices as any other workload in your environment. The tests that are implemented in the pipelines should not be editable by the builders who are using them. The pipelines should only have the permissions needed for the deployments they are doing and should implement safeguards to avoid deploying to the wrong environments. Pipelines should not rely on long-term credentials, and should be configured to emit state so that the integrity of the build environments can be validated. **Common anti-patterns:** + Security tests that can be bypassed by builders. + Overly broad permissions for deployment pipelines. + Pipelines not being configured to validate inputs. + Not regularly reviewing the permissions associated with your CI/CD infrastructure. + Use of long-term or hardcoded credentials. **Benefits of establishing this best practice:** + Greater confidence in the integrity of the software that is built and deployed through the pipelines. + Ability to stop a deployment when there is suspicious activity. ** Level of risk exposed if this best practice is not established:** High ## Implementation guidance Implementation guidance Starting with managed CI/CD services that support IAM roles reduces the risk of credential leakage. Applying the Security Pillar principles to your CI/CD pipeline infrastructure can help you determine where security improvements can be made. Following the [AWS Deployment Pipelines Reference Architecture](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) is a good starting point for building your CI/CD environments. Regularly reviewing the pipeline implementation and analyzing logs for unexpected behavior can help you understand the usage patterns of the pipelines being used to deploy software. ### Implementation steps Implementation steps + Start with the [AWS Deployment Pipelines Reference Architecture](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). + Consider using [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) to programmatically generate least privilege IAM policies for the pipelines. + Integrate your pipelines with monitoring and alerting so that you are notified of unexpected or abnormal activity, for AWS managed services [Amazon EventBridge](https://aws.amazon.com/eventbridge/) allows you to route data to targets such as [AWS Lambda](https://aws.amazon.com/lambda/) or [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS). ## Resources Resources **Related documents:** + [AWS Deployment Pipelines Reference Architecture](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/) + [Monitoring AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html) + [Security best practices for AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html) **Related examples:** + [DevOps monitoring dashboard](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub) # SEC11-BP08 Build a program that embeds security ownership in workload teams SEC11-BP08 Build a program that embeds security ownership in workload teams Build a program or mechanism that empowers builder teams to make security decisions about the software that they create. Your security team still needs to validate these decisions during a review, but embedding security ownership in builder teams allows for faster, more secure workloads to be built. This mechanism also promotes a culture of ownership that positively impacts the operation of the systems you build. **Desired outcome: **To embed security ownership and decision making in builder teams, you can either train builders on how to think about security or you can augment their training with security people embedded or associated with the builder teams. Either approach is valid and allows the team to make higher quality security decisions earlier in the development cycle. This ownership model is predicated on training for application security. Starting with the threat model for the particular workload helps focus the design thinking on the appropriate context. Another benefit of having a community of security focused builders, or a group of security engineers working with builder teams, is that you can more deeply understand how software is written. This understanding helps you determine the next areas for improvement in your automation capability. **Common anti-patterns:** + Leaving all security design decisions to a security team. + Not addressing security requirements early enough in the development process. + Not obtaining feedback from builders and security people on the operation of the program. **Benefits of establishing this best practice: ** + Reduced time to complete security reviews. + Reduction in security issues that are only detected at the security review stage. + Improvement in the overall quality of the software being written. + Opportunity to identify and understand systemic issues or areas of high value improvement. + Reduction in the amount of rework required due to security review findings. + Improvement in the perception of the security function. **Level of risk exposed if this best practice is not established:** Low ## Implementation guidance Implementation guidance Start with the guidance in [SEC11-BP01 Train for application security](sec_appsec_train_for_application_security.md). Then identify the operational model for the program that you think might work best for your organization. The two main patterns are to train builders or to embed security people in builder teams. After you have decided on the initial approach, you should pilot with a single or small group of workload teams to prove the model works for your organization. Leadership support from the builder and security parts of the organization helps with the delivery and success of the program. As you build this program, it’s important to choose metrics that can be used to show the value of the program. Learning from how AWS has approached this problem is a good learning experience. This best practice is very much focused on organizational change and culture. The tools that you use should support the collaboration between the builder and security communities. ### Implementation steps Implementation steps + Start by training your builders for application security. + Create a community and an onboarding program to educate builders. + Pick a name for the program. Guardians, Champions, or Advocates are commonly used. + Identify the model to use: train builders, embed security engineers, or have affinity security roles. + Identify project sponsors from security, builders, and potentially other relevant groups. + Track metrics for the number of people involved in the program, the time taken for reviews, and the feedback from builders and security people. Use these metrics to make improvements. ## Resources Resources **Related best practices:** + [SEC11-BP01 Train for application security](sec_appsec_train_for_application_security.md) + [SEC11-BP02 Automate testing throughout the development and release lifecycle](sec_appsec_automate_testing_throughout_lifecycle.md) **Related documents:** + [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) + [How to think about cloud security governance](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/) **Related videos:** + [Proactive security: Considerations and approaches](https://www.youtube.com/watch?v=CBrUE6Qwfag)