Cybersecurity& ArchitectureIT Consulting

Appearance settings

All appearance and animation settings
Discuss your audit scopeContact
Back to Review insights

E-COMMERCE DEMONSTRATION

E-commerce delivery: release the change that was checked

Three controlled failures test whether release rules stop a failed checkout, an altered artifact and sensitive diagnostic output.

An independent demonstration using synthetic customers, orders and payment events. The findings were reproduced in a controlled model; this is not a client engagement or an audit of a live store.

The business question

Can a release proceed after failed checks, change after approval or expose secrets through logs?

Local policy functions evaluate synthetic checks, two different artifact byte sequences and diagnostic records containing four canary values. They model release decisions, not an operating CI service or a live deployment. A real review also needs access-control, bypass, deployment and log-collector evidence.

Reviewed in this demonstration

  • Required checks before promotion
  • Identity of the approved and deployed artifact
  • Sensitive values in diagnostic records

E-COMMERCE DEMONSTRATION

Findings and verified changes

DEL-01Review priority: High

Approval permits release despite a failed checkout test

The demonstrated gate promotes a change with a known failed checkout check. Approval alone provides no assurance that required behaviours passed.

Observed finding
The approval-only gate accepts a candidate even though its checkout test failed. The fixed gate checks required successful results for the exact candidate and blocks it.
Recommended fix
Protect the buying journey. Require named checks for the exact commit at the release boundary, treat missing or unsuccessful results as blocking and control exceptions explicitly.
Verification and follow-up checks
Attempt promotion with a failed, missing, pending or wrong-commit check. Each must be blocked. A fully successful control passes; verify the actual CI and deployment permissions separately.

Before the fix

Candidate with failed checkout check: promoted.

After the fix

Candidate with failed checkout check: blocked.

DEL-02Review priority: High

A release label accepts different artifact bytes

The deployment candidate differs from the approved artifact. Tests and approval no longer describe the content being promoted.

Observed finding
Two artifacts carry the same release label but have different SHA-256 digests. The label-only gate accepts the replacement; digest comparison rejects it.
Recommended fix
Bind approval to what will run. Record the artifact digest, verify it before deployment and enforce trusted provenance where supported. Protect the approval record and promote the same immutable bytes.
Verification and follow-up checks
Change one artifact byte while keeping its label: promotion must fail. The original bytes must pass. Digest equality tests identity; separately verify the trusted build and signed provenance policy.

Before the fix

Different bytes under the approved label: accepted.

After the fix

Different bytes under the approved label: blocked.

DEL-03Review priority: High

Diagnostics copy credentials and customer data

An unrestricted diagnostic dump replicates a bearer token, session value, password and customer email into another data surface. All test values are synthetic canaries.

Observed finding
The unrestricted record contains 4 canary values. The allowlisted record contains 0 while retaining its correlation identifier.
Recommended fix
Keep diagnostics useful and limited. Record approved event fields and correlation identifiers; exclude credentials, sessions and unnecessary personal data. Restrict access and set appropriate retention.
Verification and follow-up checks
Inject synthetic canaries in nested headers, bodies and error messages. Confirm none reach the final collected record while the order, error code and correlation identifier remain available.

Before the fix

Exposed canary values: 4.

After the fix

Exposed canary values: 0; correlation retained: yes.

What this helps you decide

  • Specify which checks must succeed for the exact change being released, and restrict bypass permissions.
  • Promote the approved artifact by verified identity rather than a mutable label or a fresh unverified rebuild.
  • Retain enough diagnostic context to investigate failures without copying credentials and unnecessary customer data.

What the review produces

A release-control checklist with required evidence, artifact verification and a safe diagnostic record.

Related serviceExplore the audit report outline

Technical references

The references explain the control principles. The observations above come from the local demonstration.

Explore the other reviews

All review insights

CONTACT

Discuss your audit scope.

Start with the business question, a general description of the system and your preferred dates. We agree confidentiality and information handling before you share technical materials.

Select a button to reveal the email address or phone number.

Based in Poland. On-site audits in Poland and internationally are available by arrangement.

Prepare for an audit