In 2024, our work on the JUDGE platform’s AWS deployment gave us an opportunity to use our own tooling in the delivery process. This article records that engineering approach. JUDGE is the historical product name; this is not the installation guide for today’s TestifySec platform.

Infrastructure changes belong in code review

We used AWS Cloud Development Kit (CDK) to describe infrastructure in Go and deliver changes through a pipeline. Keeping the infrastructure definition in version control made changes reviewable alongside the application work they supported.

That approach still requires decisions about credentials, account boundaries, permissions, and rollback. A library can generate infrastructure definitions; it cannot decide which changes an organization should authorize.

What self-mutation means

In CDK Pipelines, a self-mutation stage can update the pipeline definition when its code changes. Later stages use the updated definition to deploy application stacks.

It does not mean an application rewrites itself or that an infrastructure change approves itself. Review requirements and deployment authority still need to be configured. A pipeline capable of changing its own future behavior deserves particular attention to who can modify its source and what credentials it holds.

Repeatability has conditions

Describing infrastructure as code helps teams repeat deployments. Reproducibility also depends on pinned dependencies, account configuration, external inputs, and the behavior of the services being deployed. A CloudFormation change set supports review; it is not a guarantee that every deployment can be reversed without impact.

The useful evidence is specific: the reviewed infrastructure revision, the synthesized output, the checks that ran, the deployment decision, and the resulting environment. Keep those records connected instead of inferring success from the presence of a pipeline file.

Apply the lesson to today’s system

The shared documentation is the starting point for current deployment options. CI/lock captures configured work, Pushgate checks repository pushes, and the platform manages gates and technical control evidence. An attestation records a claim about that work; its value depends on the producer, verification policy, and scope.