security

Security and privacy

The compiler runs locally with no telemetry, socket use, source upload, cloud account or external LLM. The input CBOM may still contain sensitive names and paths; protect it and internal-evidence.json as internal files. Only the explicit seven public artifacts enter the ZIP.

JSON and XLSX are capped at 10 MiB. XLSX expansion, member count, compression ratio, traversal names, external links and VBA members are checked before parsing. Question-cell formulas are skipped; the original workbook may contain other formulas that are preserved but never evaluated by the compiler. Output cell strings starting with formula operators are escaped. HTML is escaped. ZIP members use fixed literal names, with no extraction of untrusted input. The JSON loader necessarily reads all input fields into memory; the extractor deliberately ignores key value fields and source snippets when writing outputs.

Since version 0.1.3, the package rejects duplicate XLSX ZIP members, duplicate questionnaire IDs, duplicate top-level CBOM bom-ref values, unsupported crypto asset types and high-confidence external workbook formulas. It requires acknowledgement for nonempty unmapped sheets, including content beyond row 200 and comment-only cells. Algorithm matching uses a bounded known-name set and never infers algorithmFamily from a component label. Unknown or negated technical wording remains unresolved. Release diff retains same-name asset groups. customer-cbom.json includes the source timestamp used by any timestamp answer, so a public evidence reference can be checked.

Known limits: this is not a full CycloneDX schema validator, malware sandbox, DLP engine or assurance audit. Arbitrary free-text component names and algorithm identifiers require review before sending a pack. Input files should be treated as untrusted, especially when sourced from customers. The local user controls output directory permissions and deletion. Report product security/integrity issues to [email protected] using an issue code and synthetic reproduction. Do not send private CBOMs, questionnaires, credentials or source through routine email. This contact is the established business mailbox; CryptoProof sale remains closed.

Phase 2.5 writes only to a different output XLSX. Ambiguous column headers require explicit user mapping. Any populated answer/evidence target is preserved, including whitespace-only values. Protected sheets and merged, formula or data-validated target cells are rejected before compilation. XLSX parts likely to be damaged by openpyxl are rejected by preflight. writeback-review.json, review-required.json, the answer library and internal evidence map stay local outside the customer ZIP. The original XLSX may contain sensitive existing answers; approve_existing requires the vendor to inspect them before finalization. The draft ZIP is visibly marked unapproved. The final ZIP includes an approval record only after every row has a matching explicit decision and draft artifact hashes are unchanged. This is a workflow check, not cryptographic identity proof or legal attestation.

For the Early Access candidate, preflight also rejects hidden sheets and hidden rows/columns: copying them could disclose unseen information. Finalization cross-checks the review question IDs, evidence links and status eligibility against the fingerprinted public manifest, so deleting rows from the local review file or changing a supported status cannot skip approval. These checks reduce accidental or simple local-file tampering; a user who controls the machine and files can still create or send their own ZIP. They do not authenticate the human reviewer.

Every nonempty unmapped sheet now requires a local ignore --confirm-no-questions acknowledgement bound to its content hash. The user must inspect it first; a changed sheet requires a new acknowledgement. Finalization checks the original CBOM, questionnaire, optional old CBOM and answer library hashes as well as public draft artifacts. High-confidence secret/path patterns stop public output, but arbitrary free text and existing workbook content remain a vendor review responsibility. The owner-answer library permits only narrow organizational question and answer templates; its scope must exactly match metadata.component.name in the supplied CBOM. This still does not authenticate the CBOM, reviewer or organization.

Owner answers can contain sensitive organizational information. --answer-file avoids putting the answer text into command history; the file still needs vendor-controlled permissions and retention. Scope and validity dates are explicit, and the tool refuses technical or compliance-claim library entries. A human can still approve an incorrect statement or copy a draft manually, so vendor review remains a trust boundary. No application telemetry or network call was added.