Security & Transparency

Trust should be supported by records, not slogans.

How ByteCase approaches source transparency, local operation, vulnerability reporting, dependencies, releases, and responsible software use.

01

Release and source transparency

The Hub pilot publishes the signed installer, SHA-256, signature verification record, and release manifest. Hub source is private. Linked standalone tool repositories provide source review and development history.

Verify the Hub download →
02

Local-first workflows

The current desktop-tool direction is local operation with visible case records. Each released build should disclose any network connection, update check, telemetry, crash reporting, or external-service dependency.

03

Dependency and license review

Dependencies should be identified, versioned, reviewed for licensing, and evaluated for security or maintenance concerns before an official release.

04

Honest limitations

ByteCase documentation distinguishes current behavior from planned direction and states what each module does not claim to determine or replace.

Vulnerability reporting

Report a security concern privately.

Do not place exploit details, sensitive case information, credentials, private datasets, or protected personal information in a public GitHub issue.

Until a dedicated security address is published, use the ByteCase contact page and identify the message as a security report without including sensitive details.

Start a security report

Operational responsibility

Signed releases and local operation still require organizational review.

Users and organizations remain responsible for approved-software procedures, endpoint controls, tool validation, evidence access, storage security, laboratory policy, legal requirements, and determining whether a particular release is appropriate for use.

Current development

Inspect the work as it develops.

Public repositories provide the most direct view of source changes, issues, dependencies, and development history.