Describe the Reference Implementation you'd like
We would like to add a new section to the DPRA for Top 10 Security Risks
Following the OWASP top CI/CD risks https://owasp.org/www-project-top-10-ci-cd-security-risks/
Describe alternatives you've considered
We planned originally to publish this to the Security blog, but the content is too long for a blogpost.

Additional context
This is following a chat with @cplee

Is your feature request related to a problem? Please describe.
The current AWS CDK Pipeline doesn't have an implementation for DAST

Describe the solution you'd like
Add OWASP ZAP testing to the Gamma stage. Consider the API Scanner

Describe the Reference Architecture you'd like
A lot of modern Frameworks like React Native, Flutter, etc. allow the development of applications that are then able to cross-compiled for multiple platforms (Android, iOS, Windows, Linux, others?). While the different frameworks in general prove guidance on how to achieve a "true" cross-platform delivery of the different versions, there is only minimal guidance available "for free" (as open source) on how to create a true CI/CD pipeline across multiple platforms.
With this proposal, we would invest into building a proposal architecture based on existing best practices.
Potential contribution partners: Google (Flutter), Meta (Android)

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
The business outcomes list:

Measured - Provide real-time metrics for code quality, speed (deployment frequency and deployment lead time), security (security control automation %, mean time to resolve security errors), and reliability (change failures and time to restore service). View metrics through a real-time dashboard. When instrumentation is not yet possible, create a Likert-based questionnaire to determine these metrics across teams.

Yet the diagrams, and reference implementation leave out observability of the pipeline itself (or indeed set of pipelines when invarably multiple pipelines will exist within an organisation)

Describe the solution you'd like
Would be good to have the reference architecture and refrence implementtaion cover in more detail the measurement aspect, and visualisation of the same

Hello,

I have deployed cdk application example (examples/cdk-application-pipeline). After I bootstrapped the accounts, I ran npx cdk deploy --profile default --all --require-appr never. Once it finished, AWS CodePipeline failed in Synth status (see screenshots). Alejandro Moncayo helped me to fix it running npx jest --updateSnapshot. The pipeline is now running again.

Is your feature request related to a problem? Please describe.
The current reference implementation adds post-deployment testing by calling addPost and passing a SoapUITest or JMeterTest, both of which extend CodeBuildStep and are defined without a scope or environment. This works well for test executions which only rely on calling an external Internet-available endpoint (which is passed into these TestStacks as a CfnOutput).

However, for test cases which require interacting with created resources directly (perhaps to assert on conditions that should not be visible via the public API), or even if the apiUrl was instead an ApiGatewayLambda (which enforces IAM authentication), we have a problem:

• In order to set a resource-based policy permitting the CodeBuild Role to interact with a resource, the ARN of the Role must be known at the time of defining the resource
• In order for the CodeBuild Role to have a known Arn, the Role must be manually created and passed to the CodeBuild Step (if we reference codeBuildStep?.role?.roleArn or codeBuildStep?.role?.roleName for a CodeBuild step without an explicitly passed Role, the value is undefined)
• In order to manually create a Role, new Role(...) requires a scope - which is not available in the current setup of creating a CodeBuild step.

Describe the solution you'd like
An expansion of the reference pipeline to demonstrate how to execute tests that require granting resource-based permissions to the Role that will execute the tests (or, a standalone example of how to do so)

Describe alternatives you've considered

• Only grant the CodeBuildStep Role AssumeRole privileges, and create specific Roles for it to assume in order to carry out testing
  • I suspect that this will be the preferred solution. Note, though, that unless the assumable roles grant Assumption privileges to all Roles in the account where the test execution role resides, we have recovered the same problem of "how can these Roles define the Roles that should be able to assume them if the test execution role has an undefined name?". The attack surface area here is probably a lot smaller, though.
  • If there are multiple assumable roles created for the Test Execution Role to assume, this abstraction will leak into the test code, which must "know about" which role to assume for which action.
• Create the role in the context of the pipeline, and pass into the service stack and the testing step
  • Into the service stack to reference for resource-based policies; into the testing step to use in the CodeBuildStep.
  • This also implies that all testing roles will be in the same account, adding a minor irritation that their IDs and names will have to be differentiated.
• Create the role in the context of the stage and pass out to the testing step
• Avoid tests which require resource-based policies
  • This might well be possible, but seems a restrictive solution. Tests which only exercise the public interface of a system have their place, but some behaviours of a system (off the top of my head - those which rely on updating some "behind-the-scenes" value, or those which should trigger an asynchronous job) would be impractical to test purely via an external interface.

Additional context
Add any other context or screenshots about the feature request here.

I think it's supposed to be Mean time between failures and not between success and failure but between failures.

Source: https://en.wikipedia.org/wiki/Mean_time_between_failures

Describe the Reference Architecture you'd like
With this reference architecture we want to provide a reference pipeline for a mobile application that includes Building, Testing and deploying and application - where "deploying" it means to make it available in the mobile app stores.

Describe alternatives you've considered
This could be seen as an "application" pipeline, too, but the delivery of a mobile application (and the testing of it) has more detailed requirements than a normal application - especially because of the required connectivity to the appstores (playstore, microsoft store, etc.)

Additional context
Maybe CodeMagic (https://codemagic.io/apps) would be interested to contribute to this as a partner?

Is your feature request related to a problem? Please describe.
The current AWS CDK Pipeline doesn't have an implementation for Resilience Testing

Describe the solution you'd like
Add a step to the gamma stage to run a ChaosToolkit experiment. The experiment should disable an availability zone and monitor the alarms from canaries.

Is your feature request related to a problem? Please describe.
The workflow created by the AmazonCodeCatalyst reference implementation does not cache Maven artifacts resulting in slow builds.

Describe the solution you'd like
Enable caching of the .m2 directory.

Love this reference and the clear terminology, it's going to make focused conversations about approaches a lot easier - thank you!

I'm curious how a hotfix/emergency-deploy system would fit into this system? Obviously, we hope to never need them, but hope is not a reliable mechanism. Do you build add-on tooling which can make an ad-hoc deployment to a target stage of the output of a given build-iteration, or is there a way to build that functionality into the pipeline itself? Having left Amazon recently, I'm wistfully remembering the extra functionality the internal Pipelines tool gives...

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.