Read the scope before counting findings
A report with zero findings is meaningful only alongside what was examined. Record the target path, source or release scope, tool version and completion result. A scan that skipped a large container or reached an inventory cap has not established that the unseen bytes are clear.
CloneGuard source mode lists excluded dependency and cache directories, while release mode does not apply those same directory exclusions. This distinction prevents development caches from overwhelming source planning without silently assuming shipped dependency files are irrelevant.
Set budgets deliberately
The documented defaults include 10,000 filesystem entries, 16 MiB per file, 256 MiB of aggregate bytes, 2,000 archive entries, two ZIP levels and a 100:1 expansion ratio. Audit exposes deliberate larger file and total-byte limits through its command options.
Before increasing a budget, inspect the artifact type and why it is large. A legitimate video bundle, nested release archive and unexpected compressed payload deserve different handling. Raising a byte limit does not add semantic understanding or support for an opaque container.
Separate supported bytes from native validation
CloneGuard screens supported local files and bounded ZIP members without extracting or executing them. It does not follow symlinks or run the inspected project’s build scripts. Containers such as ASAR or DMG need additional native tooling and must remain explicit gaps in the generic result.
For a native release, use approved tools to inspect the package and verify signatures, architecture and runtime behavior. Keep those outputs alongside the generic audit. Do not rename the container to a familiar extension or report an outer-file hash as if every inner file was screened.
Build a complete evidence record
A practical review table has one row per release surface: public web assets, native package, server deployment and private diagnostics. Assign the appropriate audit, native check or request test to each row and mark anything unrun. This avoids forcing one generic scanner to stand in for an entire security review.
CI should preserve incomplete-screening exit codes. If an exception is necessary, record the owner, reason and follow-up check with a bounded lifetime. The result can then support an informed release decision without overstating protection against credentials, runtime vulnerabilities or application reconstruction.
Investigate an unexpected size change
Suppose a web release that previously contained a few hundred files suddenly includes tens of thousands. Before raising the entry limit, compare top-level directories with the last accepted release. An accidentally copied dependency cache or source checkout may explain both the size increase and new exposure. If the larger inventory is intentional, split the review by genuine distribution surfaces and record which check covers each. Do not split only to hide a failed result: the evidence should still account for every file the customer can receive and every unsupported container that remains.
Practical checklist
- Record target, scope, completion and skipped surfaces.
- Inspect artifacts before increasing budgets.
- Use native tools for opaque containers and signatures.
- Keep incomplete results visible in CI and release notes.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.