Repo-history example

`login-action`: one registry-auth redaction change the repo's own checks missed.

In a measured replay of six real first-parent commits from docker/login-action, the same selected checks passed in standard CI every time. DriftFence stayed quiet through two commits, then flagged one registry-auth redaction change and stayed red on the later first-parent merges.

With approved registry-auth behavior fixed in Git, DriftFence would have started flagging the moment registry-auth passwords began being redacted with core.setSecret.

See the first flagged change Back to results summary

First divergence

Registry-auth passwords started being redacted with `core.setSecret`.

The first two commits in this window stayed conforming. On the third commit, the action started redacting both registry-auth passwords before continuing the same multi-registry login flow, while the same selected checks still passed in standard CI.

Blocked case

Registry-auth passwords stopped remaining unmasked in workflow logs.

In the approved baseline, the selected multi-registry registry-auth path accepted both passwords without redacting them first. After the feature landed, the action started calling core.setSecret for both passwords before keeping the same login flow.

DriftFence report

Scenario

docker.login-action.registry-auth.password-masking

Expected

output.secretMaskCount = 0

Observed

output.secretMaskCount = 2

Classification

violating

The nearby saved-registry-state and standard-login controls did not trigger DriftFence on the same six-commit slice.

Across the replay window

Two quiet commits, then one clear redaction onset.

This replay is stronger than a recurring-all-red window because the onset comes after two quiet commits on the same selected test surface and keeps two matched quiet controls.

Quiet commits first

Two unrelated commits stayed conforming

A CodeQL action bump and an actions/checkout bump both stayed quiet.
Neither commit changed the protected registry-auth redaction or the nearby control behavior.
The selected registry-auth surface stayed conforming until the feature commit landed.

Then the onset

One feature started redacting the registry-auth passwords

916386b merged ensure passwords are redacted with registry-auth.
The action started calling core.setSecret twice for the two registry-auth passwords.
DriftFence flagged that change while the same checks stayed green.

Nearby controls

Two comparison cases stayed quiet

The saved multi-registry state stayed conforming across the whole slice.
The standard single-registry fallback to docker.io stayed conforming too.
Both controls stayed quiet on the same selected test surface.

Method

How it was measured.

This replay fixes one registry-auth baseline, reruns the same selected tests on each commit, and counts the onset once because only one scenario diverged in the window.

Replay size: 6 commits
Fixed workflows: registry-auth password redaction, registry-state save, and standard single-registry login
The same selected checks reran on every commit in the window
DriftFence reran on every commit with the same approved baseline
The default follow-up window contained one onset unit and no later reconciliation

Source material

Method and source files.

The links below show the benchmark notes and pinned replay plan for this Docker auth example.

Measurement notes

The benchmark results log records the completed login-action window, including the replay size, outcome mix, and first flagged change.

Benchmark results

Fixed test plan

The replay definition fixes the three selected login workflows and the exact January 2026 replay window used here.

See the product, results, pricing, and trust pages alongside this Docker auth example.