BeneVets, Inc. - Security and Vulnerability Disclosure Policy

Document number: 13 Drafting attorney: Cybersecurity Practice Partner Adopted: July 4, 2026 Last revised: 2026-06-02 Effective date: July 4, 2026 Owner: Executive Director (Walter), with consultation of retained counsel and engineering lead (Ian) Public URL: https://benevets.org/security/policy

Part A - Vulnerability Disclosure Policy

§ 1. Plain-English Summary

In plain English: If you find a security problem with BeneVets, please tell us. Email security@benevets.org. If you stay within the boundaries described in this policy, BeneVets, Inc. will not sue you and will not refer you for prosecution. We will respond within five business days, triage within ten, and fix issues on a schedule that depends on how serious they are. We treat veteran data with extra care; please do not look at, copy, or keep anyone else's information while testing.

§ 2. Statement of Welcome

BeneVets, Inc. ("BeneVets") operates a free public-benefit web platform that helps U.S. military veterans, their spouses and adult dependents, and their authorized representatives navigate U.S. Department of Veterans Affairs ("VA") benefits and related programs. The Service handles sensitive personal information, including discharge documents and self-reported health-condition information, on behalf of users from a population that may be in crisis at the moment they reach us.

BeneVets welcomes good-faith security research as an essential complement to internal application security work, secure-by-design engineering practices, and third-party penetration testing. Independent researchers acting in good faith make the Service safer for veterans. BeneVets thanks researchers in advance for their time and care.

§ 3. Scope (In-Scope Assets)

In plain English: Research on the BeneVets website, its API, and its email templates is in scope. Research on third-party services is not in scope; report those to the third-party provider.

The following assets are in scope:

1. The BeneVets production web application at https://benevets.org and https://www.benevets.org.
2. Vercel-hosted staging and preview environments at *.vercel.app subdomains operated by BeneVets, provided the researcher has been granted a test account for that environment.
3. BeneVets API surfaces, including authenticated and unauthenticated REST endpoints served from the in-scope domains.
4. The BeneVets email-template rendering surface and the headers, body content, and template logic of transactional and newsletter email originated by BeneVets.
5. The /.well-known/security.txt file itself.

§ 4. Out of Scope

In plain English: Do not test third-party providers; do not run denial-of-service attacks; do not socially engineer staff; do not physically test our offices; do not test other users' accounts; do not look at, copy, or keep veteran personal information.

The following are out of scope and are not authorized under this policy:

1. Third-party services on which BeneVets depends, including Vercel, Inc. (hosting); Resend.com (email transmission); Functional Software, Inc. (Sentry error monitoring); Google LLC (OAuth, Analytics); Backblaze, Inc. (file storage); the U.S. Department of Veterans Affairs Lighthouse APIs; and any large-language-model provider engaged by BeneVets. Report vulnerabilities in those services directly to those providers under their own disclosure policies.
2. Denial-of-service ("DoS") testing, distributed denial-of-service testing, volumetric load testing, resource-exhaustion testing, and any test that degrades service availability for ordinary users.
3. Social-engineering of BeneVets staff, board members, volunteers, contractors, family members of any of the foregoing, or any user of the Service.
4. Physical security testing of any BeneVets-occupied or operator-occupied premises.
5. Testing against, or attempted access to, the accounts of users other than (a) the researcher's own account or (b) test accounts that BeneVets has provisioned to the researcher in writing.
6. Any action that risks exposing veteran personal information, including Sensitive Personal Information under Cal. Civ. Code § 1798.140(ae), or consumer health data under WA Rev. Code § 19.373 et seq., to any audience wider than the individual researcher.
7. Spam, phishing, automated mass-account creation, and content-policy violations covered by the Acceptable Use Policy.
8. Testing of, or attempts to disrupt, the crisis-keyword detection and Veterans Crisis Line referral surface.

§ 5. Test Accounts

In plain English: Email us and we will give you a test account. Do not use real veteran accounts.

BeneVets will provide test accounts on request to security researchers who have read this policy and agreed in writing to abide by it. Test accounts are provisioned in the staging environment and do not contain real veteran personal information. Researchers must not test against real user accounts. To request a test account, email security@benevets.org with the subject line "Test Account Request" and a brief description of the planned research.

§ 6. Safe Harbor

In plain English: If you stay within the rules in this policy, BeneVets will not sue you and will not ask the government to prosecute you. This protection does not cover anything you do outside the rules.

BeneVets, Inc. commits that it will not pursue civil action, will not initiate or support criminal action, will not initiate or support state or federal investigatory action, and will not allege a violation of its Terms of Service against a security researcher whose conduct satisfies all of the following conditions:

(a) the researcher's activity is limited to the in-scope assets identified in § 3;

(b) the researcher does not engage in any conduct identified as out of scope in § 4;

(c) the researcher reports the finding promptly and in good faith through the channels identified in § 8;

(d) the researcher does not exfiltrate, retain, share, sell, or publish data beyond the minimum necessary to demonstrate the vulnerability, and securely destroys any incidental data upon BeneVets's request and confirms destruction in writing per § 17;

(e) the researcher does not publicly disclose the vulnerability before BeneVets has had a reasonable opportunity to remediate, with a default coordinated-disclosure window of ninety (90) days from initial report, subject to adjustment by mutual agreement under § 15; and

(f) the researcher complies with all applicable laws other than the specific access-and-authorization concerns this safe harbor is designed to address.

This safe harbor is provided in light of, and informed by, the following authorities:

• The Computer Fraud and Abuse Act, 18 U.S.C. § 1030, which prohibits accessing a protected computer "without authorization" or "exceeding authorized access."
• Van Buren v. United States, 593 U.S. 374 (2021), in which the Supreme Court held that the CFAA's "exceeds authorized access" clause is limited to circumstances in which a user accesses areas of a computer system that are off-limits to that user (a "gates-down" framework), and does not reach circumstances in which a user misuses information from areas the user is otherwise authorized to access.
• hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022), in which the Ninth Circuit further narrowed the CFAA's reach in the context of publicly accessible information, holding that scraping publicly available data is unlikely to constitute "without authorization" access under § 1030(a)(2).
• The U.S. Department of Justice's May 19, 2022 policy revision to its CFAA charging guidance, which directs federal prosecutors that good-faith security research should not be charged.
• The U.S. Cybersecurity and Infrastructure Security Agency's Binding Operational Directive 20-01, which requires federal civilian agencies to publish vulnerability disclosure policies and serves as the leading best-practice template for non-federal VDPs.

By publishing this policy and the in-scope authorization in § 3, BeneVets affirmatively authorizes good-faith security research within the boundaries described. Activities outside those boundaries are not authorized and are not protected by this safe harbor. BeneVets reserves all rights with respect to conduct outside the safe harbor's scope.

This safe harbor binds BeneVets, Inc. only. It does not bind third parties, including the operators of any out-of-scope service listed in § 4(1), and it does not constitute authorization to test those third-party services. BeneVets has no authority to grant a safe harbor on behalf of the U.S. Department of Veterans Affairs.

§ 7. Coordinated Vulnerability Disclosure with the U.S. Department of Veterans Affairs

In plain English: If you find a vulnerability that touches VA systems or VA data, we will work with VA. We do not control how VA responds.

Where a vulnerability implicates the VA Lighthouse APIs, VA-provided data, or any other federal data source or system, BeneVets will coordinate the disclosure with the U.S. Department of Veterans Affairs Office of Information Security and, as appropriate, the VA Vulnerability Disclosure Program. BeneVets will keep the researcher reasonably informed of the coordinated process to the extent permitted by VA. BeneVets does not control the VA's response timing, remediation choices, or public-communication decisions, and nothing in this policy implies that BeneVets has authority over VA's response.

§ 8. Reporting Channels

In plain English: Email security@benevets.org. Encrypt if you can. We will respond.

Primary channel: mailto:security@benevets.org. PGP-encrypted submissions are preferred. The current PGP public key is available at https://benevets.org/.well-known/pgp-key.txt, and its fingerprint is [PGP FINGERPRINT PENDING].

Secondary channel (reserved): BeneVets may, at a future date, engage HackerOne, Inc. or Bugcrowd, Inc. to operate an intake platform. If activated, the platform URL will be published at https://benevets.org/security/policy and added to the Contact: field of the /.well-known/security.txt file. The decision to engage a managed VDP platform is reserved to the Board.

Reports should include, at minimum: a description of the vulnerability, the affected URL or endpoint, reproduction steps, and (if known) the suspected impact and severity. Researchers may submit anonymously per § 14.

§ 9. Acknowledgment Service Level

BeneVets will acknowledge receipt of a report within five (5) business days of submission. Acknowledgment will confirm receipt, assign a tracking identifier, and identify the BeneVets contact responsible for triage.

§ 10. Triage Service Level

BeneVets will complete initial triage and assign a working severity rating within ten (10) business days of acknowledgment. Severity ratings follow the Common Vulnerability Scoring System (CVSS) version 3.1 base score, mapped to four bands:

§ 11. Remediation Service Levels

In plain English: We aim to fix critical issues in 30 days, high in 60, medium in 90, low in 180. We may ask for extra time and will tell you why.

BeneVets targets the following remediation timelines, measured from the date of severity assignment under § 10:

BeneVets may extend a remediation deadline where remediation requires coordinated action with a third-party provider, requires architectural change, or where a temporary mitigation has been deployed and a permanent fix is in progress. Extensions will be communicated to the researcher with a stated reason and a new target date.

§ 12. Recognition

In plain English: With your permission, we will list you on our hall-of-fame page.

BeneVets maintains a public acknowledgments page at https://benevets.org/security/acknowledgments listing researchers who have made qualifying reports and have consented to be recognized. Recognition entries may include the researcher's name or handle, a date, and a short non-technical description of the contribution. Researchers may decline recognition or request anonymized recognition.

§ 13. Bug Bounty Posture

At v1, BeneVets does not operate a paid bug-bounty program. BeneVets is a 501(c)(3) public charity operating on a constrained budget and prioritizing direct veteran services. BeneVets recognizes researcher contributions through acknowledgment under § 12 and reserves the right to activate a bounty program in the future. No reasonable expectation of monetary compensation arises from this policy.

§ 14. Researcher Anonymity

A researcher may submit a report anonymously or under a pseudonym. BeneVets will not attempt to deanonymize a researcher who reports in good faith. Where law enforcement compels disclosure of information held by BeneVets, BeneVets will, to the extent lawful, notify the researcher and provide a reasonable opportunity to object.

§ 15. Coordinated Public Disclosure

In plain English: We will work with you on when and how to publish.

BeneVets and the researcher will coordinate timing and content of any public disclosure. The default coordinated-disclosure window is ninety (90) days from initial report under § 6(e). BeneVets and the researcher may shorten or extend the window by mutual agreement, with shortening favored where the vulnerability is being actively exploited and extension favored where the fix requires complex coordination.

§ 16. Data Handling During Research

In plain English: Look only as far as needed to confirm the problem. Do not keep anyone's personal information.

Researchers must not retain, share, sell, publish, or transmit to any third party any personal information observed during testing, including any veteran personal information, any Sensitive Personal Information under Cal. Civ. Code § 1798.140(ae), any consumer health data under WA Rev. Code § 19.373 et seq., any information from a DD-214 or other discharge document, and any information from a Helper relationship audit log. Researchers must securely destroy any incidental data observed during testing within seventy-two (72) hours of confirming the vulnerability and must, upon BeneVets's request, confirm destruction in writing.

§ 17. Crisis-Content Sensitivity

In plain English: Some content on BeneVets relates to mental-health crisis. If you see it during testing, do not screenshot, do not copy, do not share. Tell us right away.

The Service includes a crisis-keyword automated decisioning surface that routes users in possible mental-health crisis to the Veterans Crisis Line and related resources (Call 988 then press 1; Text 838255; Chat veteranscrisisline.net; TTY 711, then 988). Content surfaced through that pathway carries heightened sensitivity. A researcher who inadvertently encounters crisis-related content during testing must:

(a) cease testing in that area immediately; (b) not screenshot, copy, exfiltrate, or retain the content; (c) report the inadvertent encounter to security@benevets.org within twenty-four (24) hours; and (d) treat the encounter as a confidential matter with the heightened care owed to vulnerable populations.

The Veterans Crisis Line is operated by the U.S. Department of Veterans Affairs. BeneVets does not operate that line.

§ 18. FTC Health Breach Notification Rule Cross-Reference

In plain English: If a vulnerability has actually exposed unsecured health-identifiable information, federal law makes us notify users, the FTC, and (in larger cases) the press, on tight timelines. We will activate that response.

If a reported vulnerability indicates that an acquisition of unsecured PHR identifiable health information has occurred without the authorization of the individual within the meaning of the Federal Trade Commission's Health Breach Notification Rule, 16 C.F.R. Part 318, BeneVets's internal breach-response runbook is activated. That runbook requires:

(a) individual notice without unreasonable delay and in no event later than sixty (60) calendar days after discovery, per 16 C.F.R. § 318.4;

(b) FTC notice without unreasonable delay and in no event later than ten (10) business days after discovery if the breach involves five hundred (500) or more individuals, per 16 C.F.R. § 318.5(c); and

(c) media notice in affected jurisdictions where the breach involves five hundred (500) or more residents of a state or jurisdiction, per 16 C.F.R. § 318.5(a)(2).

Activation of the breach-response runbook does not extinguish the safe harbor in § 6 with respect to the researcher who made the report in good faith.

§ 19. NIST Secure Software Development Framework Alignment

BeneVets aligns its internal secure-development practices with the National Institute of Standards and Technology Secure Software Development Framework, NIST Special Publication 800-218 ("SSDF"). Alignment areas include: protect the organization (PO), prepare the organization (PS), produce well-secured software (PW), and respond to vulnerabilities (RV). This policy is BeneVets's primary RV.1 ("Identify and Confirm Vulnerabilities on an Ongoing Basis") public-facing artifact.

§ 20. Updates to This Policy

BeneVets may update this policy from time to time. The "Last revised" date at the top of the document reflects the most recent update. Material changes will be summarized in a change log appended to the published policy.

§ 21. No Legal Advice; Reservation of Rights

This policy is not a contract and is not legal advice. It states BeneVets's good-faith commitments to security researchers. BeneVets reserves all rights, including the right to update this policy, to revoke authorization in cases of bad-faith conduct, and to enforce its Terms of Service and applicable law with respect to conduct outside the safe harbor's scope.

Part B - /.well-known/security.txt (RFC 9116) File Content

Engineering note. The text below is the literal content to be placed at /public/.well-known/security.txt in the BeneVets repository. RFC 9116 § 3.3 requires the Expires: field; BeneVets selects a six-month expiration to force a rotation cadence. RFC 9116 § 3.3 strongly recommends the file be cryptographically signed by the operator with PGP using a clear-signed signature (gpg --clearsign); the signed .asc payload is the file that ships to production. The unsigned canonical content is reproduced first; the signed form wraps it.

Unsigned canonical content

# BeneVets, Inc. - Security Contact
# RFC 9116 compliant. Cryptographically signed companion at the same URL.

Contact: mailto:security@benevets.org
Contact: https://benevets.org/security/report
Expires: 2026-12-02T23:59:59Z
Encryption: https://benevets.org/.well-known/pgp-key.txt
Acknowledgments: https://benevets.org/security/acknowledgments
Preferred-Languages: en
Canonical: https://benevets.org/.well-known/security.txt
Policy: https://benevets.org/security/policy
Hiring: https://benevets.org/about/jobs

Notes on each field

• Contact (required, repeatable): Primary mailto: channel plus a web form fallback. RFC 9116 § 2.5.3 permits multiple Contact: fields and recommends ordering by preference.
• Expires (required): Set to six (6) months from drafting. RFC 9116 § 2.5.5 requires the value to be no more than one year in the future and recommends a shorter window for rotation discipline. Engineering must rotate this file before the expiration date.
• Encryption (optional, recommended): Points to the operator's PGP public key. Key fingerprint placeholder is [PGP FINGERPRINT PENDING].
• Acknowledgments (optional): Hall-of-fame URL per § 12 of Part A.
• Preferred-Languages (optional): en matches the Service's English-only posture at v1.
• Canonical (optional, recommended): Self-referential URL prevents adversaries from passing off a different host's file as BeneVets's. RFC 9116 § 2.5.2.
• Policy (optional, recommended): Points to the published Part A policy.
• Hiring (optional): Included to encourage talent inbound; remove if no open security roles.

Signed form (operator action required before deployment)

The published file must be a PGP-signed clear-text signature wrapping the canonical content above, produced by the BeneVets operator key, in the form:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# BeneVets, Inc. - Security Contact
# RFC 9116 compliant. Cryptographically signed companion at the same URL.

Contact: mailto:security@benevets.org
Contact: https://benevets.org/security/report
Expires: 2026-12-02T23:59:59Z
Encryption: https://benevets.org/.well-known/pgp-key.txt
Acknowledgments: https://benevets.org/security/acknowledgments
Preferred-Languages: en
Canonical: https://benevets.org/.well-known/security.txt
Policy: https://benevets.org/security/policy
Hiring: https://benevets.org/about/jobs
-----BEGIN PGP SIGNATURE-----

[SIGNATURE BLOCK - generated at deploy time by `gpg --clearsign --default-key <fingerprint>`]
-----END PGP SIGNATURE-----

Engineering should add a CI check that fails the build if the file is unsigned, if the Expires: field is within thirty (30) days of expiration, or if the signature does not verify against the published public key.

Part C - Cross-References

This policy is consistent with and should be read alongside:

• Terms of Service (Document 01) - limitation-of-liability and contract-defense package.
• Privacy Policy (Document 02) - breach-notification commitments and processor inventory.
• Acceptable Use Policy (Document 06) - non-research user conduct.
• Data Retention Schedule (Document 14) - researcher-incident retention.
• Automated Decision-Making and AI Notice (Document 15) - crisis-keyword surface description.

Part D - Internal Distribution

This policy is published at https://benevets.org/security/policy, linked from the site footer, referenced in the Policy: field of the /.well-known/security.txt file, and circulated to the Board of Directors, the Executive Director, and the engineering lead.

End of Document 13 - Security Vulnerability Disclosure.