This document outlines security procedures and general policies for the Visa Vulnerability Agentic Harness (vvaharness) project.

• Reporting a Vulnerability
• Disclosure Policy
• Security considerations

Thank you for improving the security of our software. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your report.

Please report security vulnerabilities by emailing the security team at:

• vvaharness@visa.com

For coordinated disclosure and additional reporting channels, see:

• Visa Vulnerability Disclosure Program: https://usa.visa.com/about-visa/vulnerability-disclosure.html

Please do not report security vulnerabilities through public GitHub issues.

The security team will acknowledge your email and follow up with next steps in handling your report. We will keep you informed of progress toward a fix and full announcement, and may ask for additional information or guidance.

When reporting, please include as much of the following as you can to help us triage quickly:

• The version (or commit) of vvaharness affected.
• The profile/backend in use (via: cli / via: sdk / via: openai) and OS.
• A description of the issue and its security impact.
• Step-by-step instructions to reproduce.
• Proof-of-concept or exploit code, if available.
• Any known mitigations or workarounds.

Report security vulnerabilities in third-party dependencies to the party that maintains the affected component.

When the security team receives a vulnerability report, it is assigned to a primary handler. This person coordinates the fix and release process, involving the following steps:

• Confirm the problem and determine the affected versions.
• Audit code to find any potential similar problems.
• Prepare fixes for all releases still under maintenance. These fixes are released as quickly as possible.

Public disclosure is coordinated with the reporter; please give us reasonable time to remediate before any public discussion of the issue.

TL;DR: vvaharness reads repository content and forwards excerpts to the configured LLM API (redacted before egress on the sandboxed via: sdk / via: openai backends; on-disk reports are redacted on every backend). Keep scan credentials and config outside the repositories you scan, restrict tool access in CI/CD, and scope batch jobs to repositories your team is authorized to scan.

File reads through the sandboxed tool loop and the s1 inventory are confined to the repository root — symlinks and path traversals that point outside it are rejected. Redaction — masking of credentials, private keys, and payment card data — is applied at two boundaries: the report write boundary (Markdown and SARIF, on every backend) and the outbound tool-content boundary for the sandboxed via: sdk / via: openai backends, where Read/Grep results are scrubbed before they are handed back to the model. The default via: cli backend drives the claude CLI's own filesystem tools, so quoted source on that path is masked only at the report write boundary, not before it reaches the model. API keys and git tokens are kept in environment variables and sent as request credentials; they do not appear in prompts. For full detail see docs/security.md.

Batch mode clones each repository into an isolated workspace directory and scans it. Unless you pass --keep-clones, the clone is removed when the scan completes, preserving only the report output folders listed in output.preserve_on_cleanup (default security-scan). See docs/security.md for details.

For a full description of redaction patterns, backend TLS settings, and credential handling, see docs/security.md.

• Only scan repositories you trust. The scanned repository is an input to the pipeline; treat it with the same caution as any other untrusted input to a privileged process.
• Keep scan infrastructure separate from scan targets. Store config and credentials in directories outside the repositories you scan. Run scans from a working directory that is not inside the target repository.
• Restrict tool access in CI/CD. Review and restrict tool access, and ensure sandboxing to reduce risk.
• Keep batch manifests under security-team control and restrict the git host to your internal domain.

As with any analysis tool, vvaharness processes repository content as part of its normal operation. The pipeline is designed to treat that content as data, and all output is produced as report files for human review. Apply the same judgement to SARIF output that you would to any automated tool result.

• Repositories your team is not authorized to scan.
• Repositories whose committers you do not fully trust.
• Large monorepos without first scoping the scan using vvaharness estimate, --stop-after, or --auto-step1.
• Directories containing only binaries, generated code, or vendored dependencies — exclude these via exclude_dirs in your config to keep results focused.