Serein’s security boundary includes filesystem target planning, path validation, Recovery journals, restore, fixed commands, macOS permissions, critical confirmation, build signing, and release notarization.

Until a Developer ID-signed and Apple-notarized binary release is published, source builds and local ad hoc packages are technical-preview artifacts.

Use GitHub’s private vulnerability reporting for the repository:

Report a vulnerability privately

If that form is unavailable, open a minimal non-sensitive issue asking the maintainer to enable a private channel. Do not include exploit details, personal paths, secrets, certificates, Recovery manifests, or command output in a public issue.

Include, where safe:

• affected commit/version and macOS version;
• hardware architecture;
• module ID and operation type;
• simulation or real execution;
• expected and actual behavior;
• minimal reproduction using disposable fixture data;
• whether target data moved, disappeared, or became unrestorable;
• sanitized logs and crash traces;
• suggested severity and impact.

Never test a report against someone else’s Mac, account, repository, or cloud service without explicit authorization.

This community project aims to:

• acknowledge a report within 5 business days;
• confirm triage or request more detail within 10 business days;
• coordinate a fix and disclosure timeline according to severity.

These are targets, not contractual service-level guarantees.

• a plan executing a path not shown to the user;
• a target escaping its catalogue PathRule;
• symlink traversal or dangerous filesystem race;
• a move without a usable write-ahead manifest;
• restore reading a source outside Recovery;
• critical action running in a mixed batch or without all gates;
• arbitrary command, argument, environment, or shell injection;
• protected-location or TCC bypass;
• telemetry/network behavior not disclosed in PRIVACY.md;
• release certificate, Keychain, notary credential, or workflow-secret exposure;
• an artifact labeled notarized when its ticket/signature is invalid;
• update/supply-chain compromise if an updater is added later.

Use a temporary fake home and temporary directory, as the self-test does. Do not aim destructive tests at real personal folders. Critical Finder Trash and Recovery purge tests should use disposable accounts or virtual machines with independent backups.

Public binaries are trustworthy only when all of the following match the release notes:

• source tag;
• SHA-256;
• expected Developer ID owner and Team ID;
• hardened-runtime timestamped signature;
• Apple notary status Accepted;
• stapled ticket;
• provenance attestation.

See docs/RELEASING.md.

Serein will credit reporters who want recognition, unless legal, privacy, or safety constraints prevent it. Anonymous reports are welcome.