Source preview guide · 0.1.0

Scanner execution and preparation

Follow pinned tools, source coverage and validated data generations into normalized findings.

A scan combines an authorized source view, enabled tools, validated scanner data and an explicit coverage result. The tool catalog is curated in source. It does not discover arbitrary executables, download a missing database during a scan or promise to run upstream’s latest release.

Admit the requested coverage before starting

The API checks the current preflight revision when creating a scan. A complete scan is refused before a scan or job is created if an enabled tool is blocked. An explicitly acknowledged limited scan requires at least one ready enabled tool. It records the omitted tools and their reasons, stays partial and cannot pass the gate.

Default scans do not use AI. A requested scan-wide Advisor pass uses the separately authorized local provider path; it does not change what the scanners checked. See the Advisor guide.

incremental_diff currently runs all enabled scanners against the full source view. The summary records effective_mode=full, no changed-file count and incremental-diff-fallback-full. The implementation does not claim an incremental result from tools that lack a shared complete changed-file contract. Scan admission and execution fallback define these decisions.

Follow the native execution path

Tools run sequentially in owned process groups with finite execution bounds. Syft runs before Grype; Grype reads the sanitized SBOM from that same scan. Enabling Grype without Syft produces incomplete evidence.

Each adapter supplies an owned configuration, restricted environment and private scratch paths where required. Parsed native output is checked before normalization. Missing required output, malformed records, invalid locations or analysis errors cannot silently become a clean scan. The adapter removes its raw reports after processing; raw SARIF, JSONV2, JSONL and stderr are not downloadable artifacts.

The matrix describes the pinned execution contract. Its command fragments explain the adapter, rather than providing standalone commands that reproduce CodeSecurity’s authorization, data verification and resource controls.

The tool registry, actual adapter branches and tool lock provide the complete arguments and identities. Optional secrets-lite, sast-lite and iac-lite checks start disabled and have explicitly limited coverage.

Account for source and parser limits

Source capture permits at most 5,000 files, 8 MiB per regular file and 64 MiB total source content. Eligible text analysis has a separate 1 MiB file bound. Capturing a large code file does not make that file completely analyzed.

The source-coverage receipt records eligible files and omissions such as count overflow, oversized content, binary or invalid UTF-8 input, unreadable files and unsupported types. Native report processing has a 64 MiB input cap. Stdout and stderr share bounded container scratch storage but do not yet have individual streaming limits.

Normalized findings carry scanner, rule, severity, source location, message, snippet, fingerprint and bounded metadata. Exact duplicate findings can be collapsed; two different canonical findings with the same fingerprint are rejected. Findings are deterministically ordered before transport. The summary retains tool errors, source coverage, requested/effective mode and scanner-data identity.

Complete evidence means the eligible inputs and supported native reports were processed without reported omissions. It does not mean every language construct, dependency or weakness was covered, or that a reported risky API is exploitable. A finding-free scan may still be partial; a complete scan may fail policy. Coverage and canonicalization feed the evidence publication boundary.

Prepare data outside source execution

The separate updater has network access to reviewed data sources and writable cache storage, but no project-source mount. It stages a candidate privately, validates its locked identities and content, seals a complete generation, then atomically selects it. A partially downloaded directory is not an active cache generation.

At runtime, the scanner resolves readiness and component paths from one validated generation. It must not approve tools against one pointer revision and read data from another. Active-generation verification and previous-generation verification are separate: a bad previous generation can block rollback without invalidating a verified active generation.

Rebuilding unchanged locks or downloading the same database again does not renew an intrinsic timestamp. Warning data remains usable but can omit newer vulnerabilities. Expired data requires a reviewed source/lock update. Rollback also checks identity, compatibility and freshness; cancellation does not undo an already activated generation.

Service health, a finished download and Ready to Scan are different results. Source-defined offline flags and network topology also need actual image-level egress verification before making claims about a particular build. See generation activation, runtime verification and operator preparation.

Keep upstream licenses with the tools

The table records the identifiers in the reviewed lock and links to its pinned upstream texts. It is a source inventory, not a complete redistribution or dependency-license review.

Lomo’s Apache-2.0 license does not replace these terms. The license index preserves an unresolved distinction between OpenGrep’s lock expression and its COPYRIGHT wording. Bearer includes a modification notice and source recipe and patch; it is not interchangeable with an unmodified upstream binary. Review upstream notices, modifications, embedded dependencies, rules and data for the intended distribution.