DEV Community: László Tóth

From One-Off FTR Evidence to Scheduled Security and Recovery Controls in GitLab

László Tóth — Tue, 28 Jul 2026 12:38:57 +0000

A security check that runs once is evidence, while a security check that keeps running, has a controlled scope, produces reviewable artifacts, and fails visibly can become an engineering control.

We learned this while preparing WP Suite Deployment Access for the AWS Foundational Technical Review.

The final FTR validation was fast. AWS Partner Central now accepts AWS Well-Architected Framework Review reports and automatically checks whether they satisfy the required validation controls.

The work that mattered happened before we uploaded the report.

Answering the Well-Architected questions honestly forced us to compare the architecture we described with the system we had actually deployed. That process exposed a recurring problem: many of our security and recovery statements were true at a point in time, but we did not yet have a repeatable way to prove that they would remain true after the next release.

A successful scanner run could support one review. It could not tell us whether a future API change weakened an authorization boundary, whether a browser-dependent reCAPTCHA flow still worked on the CI runner, or whether an AWS Backup recovery point could actually be restored.

So we turned the evidence work into two scheduled GitLab pipelines:

a controlled security-assurance pipeline;
a separate reliability and disaster-recovery pipeline.

This article explains the structure, the mistakes we found while automating it, and why neither pipeline is allowed to approve itself.

The product boundary came first

WP Suite Deployment Access launches optional backend infrastructure into the buyer's AWS account through AWS Marketplace and CloudFormation.

The supported architecture can include components for:

Amazon Cognito identity;
AI and knowledge-base APIs;
form and workflow processing;
protected static delivery;
scheduled backup and recovery resources.

The public CloudFormation templates show buyers and reviewers what the deployment intends to create. Private runtime artifacts are staged only during an authorized deployment.

That architecture creates an important testing constraint.

Our assurance jobs must never treat customer production accounts as scanner targets.

Before selecting any testing tool, we defined the control boundary:

all automated tests run against a dedicated, production-like test deployment;
targets are explicitly allowlisted;
test data is disposable;
destructive operations are limited to pipeline-created fixtures;
denial-of-service, stress, flooding, password spraying, and uncontrolled destructive testing are excluded;
availability degradation, unexpected cost, unintended data access, or secret exposure are stop conditions.

This boundary matters more than the scanner configuration.

A technically capable security tool pointed at the wrong environment is not an assurance control. It is an operational risk.

The security pipeline shape

The resulting security pipeline runs on a schedule and can also be started through controlled manual or evidence-producing paths.

At a high level, the stages look like this:

prepare
  ↓
application security regression
  ↓
browser-dependent validation
  ↓
API scan
  ↓
fixture cleanup
  ↓
evidence generation
  ↓
human review

The real pipeline contains several jobs, but this simplified sequence captures the responsibility of each phase.

1. Prepare

The preparation stage validates the approved targets and creates only the disposable resources required by that run.

For workflow tests, for example, the pipeline creates data with identifiers derived from the pipeline run. Cleanup can therefore distinguish test fixtures from pre-existing data.

Preparation also records the tool versions and relevant test configuration required to interpret the results later.

2. Application-specific security regression

Generic scanners are useful, but they do not understand all of the invariants that matter to an application.

We use Node.js regression tests for controls such as:

expected Cognito authorization boundaries;
denial of administrative operations to non-administrative identities;
reCAPTCHA enforcement and replay behavior;
rejection of tokens generated for the wrong action;
webhook-signature validation;
mutation resistance for presigned upload URLs;
signed-cookie behavior for protected static routes;
the rule that credentialed CORS must never be combined with a wildcard origin.

These tests express product-specific expectations directly.

If an endpoint begins returning a valid HTTP response while silently ignoring an authorization rule, a generic scanner may not recognize the business impact. An explicit regression assertion can.

3. Browser-dependent validation

Some security paths cannot be tested accurately with a plain HTTP client.

reCAPTCHA is a good example. A meaningful test may require a token produced by a real browser context, followed by a backend request that verifies the token's action, validity, and replay behavior.

We use Playwright for these browser-dependent cases.

This layer also taught us an important lesson about incomplete automation.

During an early run, the reCAPTCHA script behaved differently on the CI runner than it did in our local and deployed browser tests. The affected checks remained pending.

The wrong response would have been to treat the rest of the green pipeline as a pass.

Instead, the evidence report had to preserve the incomplete state until the runner-specific problem was understood and corrected.

A missing test is not a successful test.

4. API scanning

The pipeline exports the current API definitions from the deployed test environment and uses OWASP ZAP to scan the intended API surface.

ZAP adds a different type of coverage from the application-specific tests:

passive response analysis;
API-driven exploration;
detection of common web and API weaknesses;
an independent view of the deployed interface.

The scan is deliberately bounded.

Targets are allowlisted, concurrency is limited, and testing classes that could create availability or cost risk are excluded.

ZAP is one layer of the process, not the approval authority.

5. Cleanup

Cleanup is a first-class pipeline phase rather than a shell command appended to a test job.

The pipeline verifies that temporary workflow records, uploaded objects, and other run-specific fixtures are removed.

Cleanup evidence matters for two reasons.

First, disposable data should not gradually turn a test environment into an unreviewable collection of stale records.

Second, cleanup behavior is itself part of operational correctness. A test that succeeds but leaves unexpected resources behind has found another problem.

6. Evidence generation

The pipeline produces private artifacts containing the summaries, structured results, logs, tool versions, and cleanup evidence needed for review.

Automating this stage produced one of the more instructive failures in the project.

An early summarizer confused a scanner's confidence classification with its risk classification.

The scan itself had run correctly. The generated evidence represented part of the result incorrectly.

That is a serious defect because reviewers usually consume the summary before they inspect every raw artifact.

We corrected the summarizer and added validation around the evidence transformation.

The lesson was simple:

Evidence generation is production code.

A pipeline can execute every test correctly and still produce a misleading assurance record if its reporting layer is wrong.

Why the pipeline does not approve itself

A green CI pipeline is not the final approval.

After every evidence-producing run, a separate review item is created for a human reviewer.

The reviewer checks:

security findings and their actual risk;
failed, skipped, pending, or manually validated controls;
the boundaries and exclusions of the run;
cleanup evidence;
tool and target versions;
whether the result supports the intended assurance claim.

The final disposition is recorded separately from the pipeline status.

This separation prevents several common problems.

A script cannot silently redefine its own acceptance criteria. A newly skipped test cannot disappear inside an otherwise green result. A scanner warning cannot automatically become either a release blocker or an accepted risk without context.

Automation collects and organizes evidence, a responsible person remains accountable for interpreting it.

Recovery required a different pipeline

Security testing and disaster-recovery validation have different operational characteristics, so we do not run them as one large assurance job.

The security pipeline runs more frequently.

The reliability and DR path runs monthly and performs slower, more stateful validation.

Its most important rule is:

Do not test only whether backups exist. Test whether selected recovery points can be restored.

A backup job can report success while recovery is still blocked by permissions, encryption configuration, missing dependencies, an invalid procedure, or assumptions that have never been tested.

Our monthly process therefore works with actual AWS Backup recovery points.

At a high level, it:

identifies fresh recovery points for the protected test resources;
selects a bounded restore sample;
restores DynamoDB and S3 data into isolated resources;
validates known canary data or checksums;
records the observed recovery behavior;
removes the restored resources;
generates evidence for human review.

The restore sample is intentionally bounded.

It does not claim that every protected resource is restored during every monthly run. Backup coverage and restore sampling are reported as separate concepts so a successful sample cannot accidentally be presented as proof that every resource was restored.

This distinction made the report more honest and more useful.

From internal control to product capability

The recovery work did not remain only inside our assurance repository.

WP Suite Deployment Access now includes an optional backup and disaster-recovery component in the deployment model.

When selected, it can configure scheduled AWS Backup recovery points for supported, deployment-tagged S3 and DynamoDB resources and copy them to a second AWS Region chosen by the buyer.

This is a recovery capability, not an active-active architecture.

It should not be described as:

automatic regional failover;
continuous replication;
point-in-time recovery for every resource;
a permanently running secondary production stack.

The intended model is simpler and more explicit: a separate regional copy remains available so selected data can be restored if the primary Region experiences a serious outage or the primary recovery points are unavailable.

The infrastructure definition is deployed into the buyer's AWS account, alongside the other selected WP Suite components.

The recurring assurance pipelines remain vendor-side controls against our dedicated test deployment. They do not scan customer production environments.

What the AWS review changed

The AWS Well-Architected review began as a validation requirement, but it became a way to find places where architectural claims were not yet represented by repeatable operational behavior.

By the time we submitted the WAFR report:

security testing had become scheduled and reviewable;
browser-dependent and application-specific controls complemented API scanning;
incomplete automation remained visible rather than being counted as a pass;
evidence generation had its own validation requirements;
recovery testing used real backup restores;
human approval was separated from CI success;
a useful recovery control had become a buyer-selectable deployment capability.

WP Suite Deployment Access subsequently passed AWS Foundational Technical Review.

That statement applies to the named solution and the submitted review scope.

It does not mean AWS audited our source code, performed our penetration test, or guaranteed that the product has no risk.

The durable result is not the badge. The durable result is that the questions asked during the review continue to be answered after the review is over.

Practical takeaways

For teams building similar assurance workflows, these are the lessons I would carry forward.

Define the boundary before choosing the tools

Decide what can be tested, where it can be tested, and which activities are excluded before configuring a scanner.

Combine generic and application-specific tests

A scanner can identify broad classes of weaknesses. It cannot automatically understand every authorization, workflow, tenancy, or business invariant in your product.

Use a browser when the control depends on browser behavior

Do not replace browser-generated security context with a mock and then claim that the complete production path was tested.

Make incomplete controls visible

Pending, skipped, and manual checks belong in the evidence summary. They must not disappear behind the overall pipeline status.

Treat reporting code as production code

A wrong summary can invalidate otherwise correct test execution.

Test restores, not backup configuration

The existence of a vault, plan, or recovery point is not proof that your recovery procedure works.

Keep a human approval step

Automation should make review faster and more consistent, not eliminate accountability.

Productize controls only when the boundary remains clear

A useful internal control can become a customer-facing capability, but its limits must remain explicit. Scheduled cross-Region backups are valuable without being presented as automatic failover.

Public references

Scaling Carmen Cloud: From Containers to Lambda SnapStart

László Tóth — Mon, 15 Sep 2025 14:40:59 +0000

At Adaptive Recognition, we run Carmen Cloud for ANPR & MMR recognition. Our neural-network engines have been evolving for 30+ years – for us, "AI" is business as usual.

The real challenge: scaling. On ECS Fargate + EC2, startup + engine init took ~60 seconds. Not acceptable.

The Fargate/ECS Approach

Our first deployment ran on ECS Fargate.

For predictable workloads, this is often good enough. You can define scaling rules or even schedule tasks so that capacity matches traffic (e.g. higher during business hours, lower at night).

But our workload is the opposite of predictable. Recognition requests come from many customers, across multiple regions, at almost random times. Bursts can hit at 2 a.m. from one continent and spike again an hour later from another.

With that traffic pattern, Fargate's trade-offs became painful:

Scale-up lag: EC2 boot + engine init ~60s.
Idle cost: keeping containers pre-warmed all the time.
Ops overhead: building/pushing images, patching, managing ECR.

That's when we started looking for a new approach.

Early Adoption of SnapStart

When AWS Lambda SnapStart (Java 21) was released, we migrated immediately.

That made us among the first to see just how well it scales – and how much money it saves.

Years later, those benefits are still holding true.

The Shift: API Gateway + Lambda SnapStart + CRaC

Key trick: CRaC (Coordinated Restore at Checkpoint) pre-initializes our engines at checkpoint time.

But SnapStart has a serious limitation: it doesn't support >512 MB of ephemeral storage, nor EFS. Our recognition engines for a single region (EUR, NAM) are much larger than that.

So we built a staged engine loading mechanism:

During handler initialization, we download a batch of engine data from S3.
Engines are initialized into memory (via our VehicleHandler class).
Temporary .dat files are deleted to free up space.
The next batch is downloaded and initialized.

This keeps us under the 512 MB limit while still giving us full coverage. Initialization is more complex, but the scalability and cost benefits make it well worth it.

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;

public class VehicleHandler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, org.crac.Resource {

    static {
        // Load engines in batches at checkpoint time from S3
    }

    @Override
    public void beforeCheckpoint(org.crac.Context<? extends org.crac.Resource> ctx) throws Exception {
        // Close network connections – CRaC cannot persist them
    }

    @Override
    public void afterRestore(org.crac.Context<? extends org.crac.Resource> ctx) throws Exception {
        // Re-open connections on restore
    }

    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {
        // Process image with the chosen engine
        return new APIGatewayProxyResponseEvent();
    }
}

Supporting AWS Stack

API Gateway – entry point
Lambda (SnapStart) – recognition engines
Cognito – user auth
DynamoDB – API keys, billing records
SNS/EventBridge – async billing + subscription events
S3, SSM, CloudFront, WAF, Route53 – storage, config, delivery, security

Takeaways

Even heavy neural engines can scale serverless.
CRaC makes SnapStart viable by restoring pre-initialized state.
Closing & reopening network connections is essential.
Staged loading solves ephemeral storage/EFS limits.
Being an early adopter of SnapStart saved us both time and cost from day one.

👉 More about Carmen Cloud: carmencloud.com
👉 Corporate homepage: adaptiverecognition.com
👉 My side project for WordPress + Cognito login: Gatey

Add Social & Enterprise SSO to WordPress (Even on Static Sites) with Amazon Cognito + Gatey

László Tóth — Sun, 14 Sep 2025 12:38:17 +0000

WordPress was never built for OIDC or SAML. Export it as a static site to S3 + CloudFront and the built-in login system stops working completely.

The fix? Amazon Cognito + Gatey:

Configure Cognito User Pools & Hosted UI (no client secret needed, SPA app type)
Connect Social IdPs (Google, Facebook, Apple, Amazon)
Add Enterprise IdPs (OIDC, SAML: Okta, Azure AD, Auth0, Ping)
Wire it into WordPress with Gatey (User Pools, General, Custom Providers)
(Optional) Enable IAM so authenticated users can call your AWS APIs directly

🔗 Full guide with screenshots on wpsuite.io.

Static-friendly, secure, and no secrets stored in WordPress.

Behind the Scenes: Building WordPress Static Site Guardian with Kiro

László Tóth — Wed, 10 Sep 2025 12:00:00 +0000

In a recent post I explained how to secure static WordPress exports on AWS with Cognito, CloudFront, and signed cookies. This is the follow-up: a look at how the project itself came together with the help of Kiro.

Starting point

I'm comfortable working with AWS architecture, but I had little hands-on experience with CloudFormation. Writing a full stack by hand would have been slow and error-prone. For the hackathon I wanted to see how far I could get by asking Kiro to generate the stack for me.

The initial prompt described the core idea:

S3 bucket for the static export
CloudFront with signed cookies for protection
API Gateway + Lambda to issue cookies
integration points for Cognito through the Gatey plugin

The first generated template wasn't perfect, but it was good enough to get the stack running within a few hours. I only needed to fix some details and adjust resource lifecycles.

Reverse specification

Once the implementation was working, I asked Kiro to generate a "reverse spec" of the actual system. This produced requirements, design, and task lists that matched what I had already built. It might sound redundant, but it was valuable:

it confirmed the design was consistent,
it gave me a checklist of remaining tasks,
and it created documentation that I could share later.

Extra features and validation

Using the spec as a guide, I added missing pieces: cache policies, end-to-end tests, and deployment cleanup checks. I also asked Kiro to validate the system against the spec, which helped catch a few oversights.

What I took away

Kiro didn't magically solve everything, but it accelerated the boring parts - large CloudFormation scaffolds that I wasn't used to writing.
Having a generated spec after the fact turned out to be a useful way to organize and document the project.
With only limited CloudFormation background, I could still publish a complete SAR template in a short amount of time.

If you're curious about the solution itself, see my earlier post: Static WordPress authentication with Amazon Cognito and AWS SAR template.

Static WordPress Authentication with Amazon Cognito and AWS SAR Template

László Tóth — Fri, 05 Sep 2025 10:13:32 +0000

Static sites are great. They're fast, cheap, and secure by default.

But if you've ever tried to add login or user-only content to a static WordPress export… you know the pain.

/wp-login.php doesn't exist anymore. PHP is gone. And yet, users still expect a sign-in flow that feels smooth and professional.

That's exactly the challenge we faced - and here's how we solved it with Amazon Cognito + API Gateway + Lambda + CloudFront signed cookies.

Why Even Bother With Static WordPress?

Static WordPress exports (via plugins, S3 + CloudFront, or Netlify) are becoming popular because:

Speed: HTML served directly from a CDN
Cost: no dynamic servers to manage
Security: surface area is tiny

But the trade-off is obvious: all the built-in WP authentication features vanish.

We wanted the best of both worlds: keep WordPress static and fast, but add real authentication powered by AWS.

The AWS Approach

Instead of bending WordPress to handle login, we let AWS handle it at the edge.

Here's the high-level design:

Amazon Cognito handles user sign-up, login, MFA, and tokens.
API Gateway + Lambda exchange Cognito tokens for CloudFront signed cookies.
CloudFront enforces access, serving protected resources only to users with valid cookies.

No PHP callbacks, no secrets stored in WordPress. Just clean, serverless authentication.

How It Feels for Users

From the user's perspective:

They click Sign In on the WordPress site.
They see a branded Cognito-powered login (integrated with Gatey blocks).
On success, they get signed cookies behind the scenes.
CloudFront now lets them access members-only pages, media, or even entire routes.

It feels just like a "normal" site, but under the hood it's 100% serverless.

A Quick Architecture Sketch

[ User ] → [ WordPress (static) ]
       ↘ Sign-In → [ Amazon Cognito ]
                    ↘ Tokens → [ API Gateway + Lambda ]
                                  ↘ Issue Signed Cookies → [ CloudFront ]

CloudFront becomes the gatekeeper. If your cookies are valid, you're in. If not, you're redirected to login.

Why This Rocks

Performance - static WordPress stays lightning-fast
Security - Cognito & signed cookies > old-school PHP sessions
Scalability - runs natively on AWS infra
Flexibility - protect full sites or just specific routes

And most importantly: it keeps your WordPress database completely out of the authentication loop.

Real-World Use Cases

Membership sites hosted statically
Documentation portals with role-based access
Hybrid sites where only certain routes need login
SaaS dashboards powered by WordPress as the frontend

If you're already using CloudFront, this pattern feels very natural.

Full Tutorial with Code & Screenshots

This post was just the overview.

We wrote up the step-by-step guide with SAR template, Lambda code, and WordPress integration here:

Static WordPress Authentication Made Simple - Deploy with the AWS SAR Template

Closing Thoughts

Static WordPress doesn't mean static functionality.

With Cognito + CloudFront signed cookies, you can have speed, security, and scalability - without giving up authentication.

Curious what you think: would you ever run WordPress in static mode if authentication "just worked"? Drop your thoughts below.