Security

1. Security model

FailPack is built around local-first capture, explicit cloud upload, private artifact storage, authenticated backend access, and workspace-scoped authorization.

The CLI generates reports locally. Cloud features require an authenticated account and workspace access. Private artifacts are not served from public storage URLs.

2. Authentication and sessions

• Email/password, Google, and GitHub sign-in may be supported depending on deployment configuration.
• Accounts can use 2FA and trusted devices for additional protection.
• CLI login uses a device/session flow rather than requiring users to paste long-lived credentials into the terminal.
• Refresh and access tokens are handled by the backend and clients with rotation and expiry controls.

3. Authorization

• Dashboard and API routes for private reports require authentication.
• Workspace membership is checked before private report, artifact, billing, agent, or audit data is returned.
• Admin infrastructure routes require a separate platform role and do not rely on normal workspace ownership.
• Shared reports require an intentional share token and are separate from private dashboard access.

4. Artifact storage

Cloud artifacts are stored in private object storage. The database stores metadata, manifests, hashes, sizes, ownership references, and retention dates. Access to artifact content is mediated by authenticated backend endpoints.

Object keys are designed to avoid exposing local repository names or filesystem paths.

5. Redaction

FailPack attempts to redact common secrets, credentials, tokens, and sensitive environment values before reports are saved or uploaded. Redaction is a safety layer, not a guarantee.

Users should review report output before uploading or sharing, especially when using source snapshots, bundles, command output, or git diffs.

6. Responsible disclosure

If you find a vulnerability in FailPack, email [email protected] with enough detail to reproduce and understand the issue. Please do not publicly disclose the issue until we have had reasonable time to investigate and fix it.

Do not access, modify, delete, or exfiltrate data that does not belong to you. Do not perform destructive testing, social engineering, spam, denial of service, or attacks against third-party systems.

7. Security report contents

• Affected domain, endpoint, package, or command.
• Steps to reproduce with minimal proof of impact.
• Expected and actual behavior.
• Screenshots, logs, or request examples with secrets redacted.
• Your contact information for follow-up.

8. Out of scope

• Denial-of-service attacks or high-volume automated testing.
• Social engineering, phishing, or physical attacks.
• Issues in third-party providers unless they directly affect FailPack integration.
• Reports that require access to another user's private data without authorization.
• Missing security headers that do not create practical exploitability by themselves.

9. Contact

Security reports should be sent to [email protected]. General support questions should be sent to [email protected].