JVS is currently governed by the v0 public contract. Security fixes target supported pre-release and v0 tags for that contract.

If you discover a security vulnerability, please do NOT report it via public GitHub issues.

Instead, please report vulnerabilities responsibly by:

1. GitHub Security Advisory: Open a private draft at GitHub Security Advisory.

2. Configured security contact: If this repository has a configured security contact in GitHub security settings, use that channel for sensitive coordination.

3. Include: Please provide as much detail as possible to help us understand and reproduce the issue:

   • A clear description of the vulnerability
   • Steps to reproduce the issue
   • Affected versions of JVS
   • Potential impact of the vulnerability
   • Any proof-of-concept code or screenshots (if applicable)

4. Response Timeline: We will acknowledge your report within 48 hours and provide a detailed response within 7 days, including:

   • Confirmation of the vulnerability
   • Severity assessment
   • Planned remediation timeline
   • Coordinate disclosure date

JVS is currently in a pre-GA direct-model collapse. JVS owns small metadata and delegates workspace/HOME file operations and access control to the filesystem and JuiceFS.

Direct AFSCP metadata objects carry SHA-256 checksums over JVS metadata only. Those checksums never read, hash, walk, sample, or summarize workspace/HOME content. They are fail-closed metadata corruption checks, not a proof of saved file content safety.

jvs afscp --control-root <control-root> --home <home> doctor --json

All mutating operations append an audit record to .jvs/audit/audit.jsonl with:

• Unique event ID (UUID v4)
• Timestamp (ISO 8601)
• Operation type
• Actor identity
• Hash chain linkage for tamper evidence

jvs doctor --strict remains a metadata/audit diagnostic spelling for legacy repository maintenance. It must not be used as a file-content hash proof. For ordinary .jvs/ projects, jvs doctor --strict --repair-runtime is the bounded runtime state repair command; it must not rewrite saved content or serve as a file-content verification mechanism.

JVS v0.x intentionally defers some security features to v1.x:

Residual Risk: An attacker with filesystem write access could theoretically rewrite both a descriptor and its checksum consistently. This is an accepted risk for v0.x local-first workflows.

JVS relies on OS-level filesystem permissions for access control:

• Repository access: Controlled by filesystem permissions on .jvs/ directory
• Workspace isolation: Workspaces are separate directories with standard filesystem permissions
• JuiceFS integration: Access control delegated to JuiceFS authentication layer

Recommendation: Run jvs init in directories with appropriate POSIX permissions (e.g., 0700 for single-user, 0750 for team access).

1. No Remote Protocol: JVS has no network-facing components. Security boundaries are filesystem permissions.

2. Local-First Design: All operations assume a trusted local execution environment. JVS does not protect against malicious code running on the same machine.

3. JuiceFS Dependency: Ensure JuiceFS mount points are properly secured. Refer to JuiceFS security documentation for best practices.

4. Path Traversal Protection: JVS validates all workspace and save point names to prevent path escape attacks. Rejects .., /, \, and absolute paths.

5. Crash Safety: Save point publish uses an atomic protocol with .READY file as publish gate. Crashes before .READY are ignored; crashes after .READY may leave partial save points (detectable via jvs doctor).

1. Run direct AFSCP doctor --json for platform-managed metadata health.
2. Treat file-content access control as JuiceFS/filesystem policy, not a JVS hash proof.
3. Back up repository metadata safely only as part of a JVS-aware migration procedure; non-portable runtime state is destination-local.
4. Use JuiceFS authentication to control access to underlying storage
5. Never commit JVS control data to Git; it is metadata, not workspace content

1. Report received via private channel
2. Maintainers triage and confirm vulnerability (within 48 hours)
3. Develop fix in private branch
4. Coordinate disclosure date (typically with release)
5. Release fix with security advisory
6. Credit reporter (unless anonymity requested)

• Primary private channel: https://github.com/agentsmith-project/jvs/security/advisories
• Configured security contact: Use the configured security contact in the GitHub repository security settings when available.
• Security Policy Docs: See docs/09_SECURITY_MODEL.md and docs/10_THREAT_MODEL.md

• Security Model Specification
• Threat Model
• Conformance Test Plan (includes integrity tests)
• Release Signing and Verification (binary bundle verification)

Release artifact signing verifies distribution binaries and checksums. It is separate from descriptor signing or in-JVS trust policy, which are not part of the stable v0 repository format. For an official release, download the binary and its matching .bundle before using it:

cosign verify-blob jvs-linux-amd64 \
  --bundle jvs-linux-amd64.bundle \
  --certificate-identity=https://github.com/agentsmith-project/jvs/.github/workflows/ci.yml@<workflow-ref> \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

For tag-push releases, <workflow-ref> is usually refs/tags/vX.Y.Z. Manual workflow_dispatch releases may have a certificate identity bound to the workflow ref that launched the run while the artifacts are checked out from and published as the requested tag. See docs/SIGNING.md for the full verification flow, including SHA256SUMS.bundle.

This security policy follows CNCF best practices and OpenSSF guidelines.