Put release-exposure checks at the right CI boundaries

Draw the pipeline before adding a command

List checkout, dependency installation, compilation, copying, diagnostic upload, packaging, signing and deployment. Identify the artifact at each step. A scan of src before a plugin copies .env into dist cannot catch the resulting public exposure. A receipt created before signing will not describe the signed bytes.

Use separate checks for source policy, deployable exposure and native validity. Each can fail for a different reason. Store reports outside the public release tree so an internal audit does not itself become a new artifact served to visitors.

Preserve the CLI result

CloneGuard exits 0 when bounded screening completes below the chosen threshold, 1 for threshold findings or a manifest mismatch, and 2 for errors or incomplete screening. Do not append an unconditional success operation that hides the result from CI. Treat an unsupported container or exhausted limit as an explicit review gap.

If an organization intentionally permits a finding, document the policy and owner rather than weakening every scan with a blanket bypass. A no-findings output and a complete screening output are separate pieces of evidence; both matter for a release gate.

Gate a distinct public artifact

For supported loose web assets, review a dry-run and stage a new public tree, then test and audit that tree. Preserve original maps privately for diagnosis. Native applications should follow their own packaging and signing flow rather than generic static staging.

python3 /tools/cloneguard/cloneguard audit ./public-release --scope release
python3 /tools/cloneguard/cloneguard manifest ./public-release --out ../evidence/release.json
python3 /tools/cloneguard/cloneguard verify ./public-release --manifest ../evidence/release.json

Check what happens after the gate

Deployment adapters, CDN transforms, service-worker generation and signing may change files. Record which changes occur after auditing and whether a later check covers them. For hosted applications, request representative private-map paths on an authorized deployment and confirm the public experience still works.

Keep the commit, build identifier, tool version, report and receipt together in restricted CI artifacts. This makes the result reproducible and useful during rollback. Passing these checks demonstrates the defined release policy; it is not a measurement of AI reconstruction time or a guarantee against copying.

Prove the gate fails before trusting it

Use a temporary synthetic fixture containing a harmless source map or a recognized fake credential pattern and confirm the release job rejects it. Then remove the fixture and confirm the intended clean artifact passes. Also exercise an unreadable or deliberately over-budget input to check that incomplete screening cannot become green. Keep these integration checks small and isolated; they should validate exit-code propagation and artifact selection, not mirror every scanner implementation detail. A gate that runs the wrong directory or ignores the command’s status can look impressive in CI while providing no release enforcement. Record the expected artifact path as part of the job configuration.

Practical checklist

• Scan after all exposure-producing build steps.
• Retain exit codes and incomplete-screening failures.
• Keep reports and keys outside public outputs.
• Verify receipts after final mutation and check deployed URLs.

Sources and further reading

Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.

1. CloneGuard CLI and documented scope ↗