docs(security): add scope, out-of-scope, and OAuth beta warning

[Patch76]

What does this PR do?

Expands SECURITY.md with three additions that were missing:

1. Scope / Out-of-scope — makes it clear what researchers should and
   shouldn't report, reducing low-quality submissions and HA-core misdirects.
   Explicitly calls out prompt injection as in-scope, since it's a realistic
   attack surface for an LLM-controlled system.

2. OAuth beta warning — the consent-flow mode has a larger attack surface
   than the standard LLAT setup, had two published CVEs (now fixed), and is not
   recommended for production without TLS. None of this is currently visible to
   users reading the security policy.

3. Direct advisory link — points reporters to the "New advisory" form
   rather than the landing page, and mentions CVSS as the severity baseline.

The existing policy text (good-faith requirement, AI-generated report warning,
response timelines) is unchanged.

Why now

Following the two published CVEs earlier this year, the project's security
surface has grown more complex — OAuth mode, destructive tool operations,
prompt injection risk. The current policy doesn't reflect any of this.

Type of change

• Bug fix
• New feature
• Documentation
• Maintenance/refactor
• Breaking change

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the project's security policy to better reflect the current threat landscape and operational complexity. By providing clearer guidance on reportable issues and adding necessary warnings for experimental features, the changes aim to improve the quality of security submissions and ensure users are aware of the risks associated with specific deployment configurations.

Highlights

• Security Scope Definition: Added explicit 'In scope' and 'Out of scope' sections to clarify reporting expectations and reduce noise from irrelevant submissions.
• OAuth Beta Warning: Introduced a warning for the experimental OAuth consent-flow mode, highlighting its larger attack surface and specific security requirements.
• Reporting Process Improvements: Updated the vulnerability reporting instructions to point directly to the advisory form and clarified the use of CVSS scores for severity assessment.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates SECURITY.md to include a detailed scope section, clarify vulnerability reporting requirements, and add a beta warning for the OAuth mode. The review feedback suggests a minor improvement to the phrasing of an out-of-scope item to better distinguish between vulnerability types and deployment misconfigurations.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the SECURITY.md file to provide a clearer scope for vulnerability reporting, including specific in-scope and out-of-scope items. It also introduces a beta warning for the experimental OAuth mode, referencing past CVEs and providing deployment recommendations. Additionally, the reporting process has been updated to use GitHub's private advisory system. A review comment suggests re-incorporating the 'good-faith' requirement into the reporting guidelines to ensure consistency with the previous policy.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the SECURITY.md file to provide a more comprehensive security policy. Key changes include the addition of a detailed scope for vulnerability reporting (distinguishing between in-scope and out-of-scope issues), a beta warning for OAuth mode with references to past CVEs, and updated reporting procedures with a new advisory URL. Feedback was provided to remove a redundant mention of authentication bypass in the OAuth-specific scope list to improve conciseness.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request significantly expands the SECURITY.md file to provide a more comprehensive security policy. Key updates include a defined scope for vulnerability reports, a beta warning for the experimental OAuth mode, and a direct link for private reporting. A review comment suggests further improving the policy by explicitly stating a coordinated disclosure timeline, typically 90 days, to better manage expectations for security researchers.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request significantly expands the SECURITY.md file by adding a detailed scope for vulnerability reporting, a beta warning for OAuth mode, and updated reporting requirements. A correction was identified regarding the tool name mentioned in the sandbox escape section to ensure it matches the actual implementation.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates SECURITY.md to include a detailed scope for vulnerability reporting, a beta warning for OAuth mode, and updated reporting procedures. A review comment identifies that the tool ha_manage_custom_tool mentioned in the new scope section violates the repository's naming convention (Rule 66/104) and is not listed in the README.md, suggesting a rename or correction.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request significantly expands the SECURITY.md file by defining the scope of security reports, adding a beta warning for the experimental OAuth mode, and detailing the vulnerability reporting process and requirements. Feedback suggests restoring more explicit language regarding the rejection of misleading or speculative reports to maintain the previous policy's standards.

[sergeykad]

Code review

Found 3 issues:

1. DISABLED_TOOLS env var does not exist in the codebase. The out-of-scope section claims "Tool visibility controls (DISABLED_TOOLS, group toggles) exist for this purpose" but the actual tool-filtering env var is ENABLED_TOOL_MODULES (in config.py).

ha-mcp/SECURITY.md

Lines 30 to 32 in 9719ae3

	Tool visibility controls (`DISABLED_TOOLS`, group toggles) exist for this purpose.
	- Vulnerabilities that are only exploitable due to a misconfigured deployment
	(e.g., standard-mode instance exposed to the internet without TLS)

2. "Sandbox escape via sandboxed code execution, if that feature is enabled" — the qualifier "if that feature is enabled" implies a user-controlled sandbox toggle that doesn't exist. The sandbox is always active when ENABLE_DASHBOARD_PARTIAL_TOOLS is true (default).

ha-mcp/SECURITY.md

Line 20 in 9719ae3

- Dependency vulnerabilities with a credible exploit path

3. "Two CVEs were published and fixed in v7.x" — the count will go stale as new advisories are published. The linked GHSAs already identify what was fixed; the number adds no value. Consider dropping the count.

ha-mcp/SECURITY.md

Lines 44 to 45 in 9719ae3

	If you choose to run OAuth mode, restrict the consent endpoint to trusted networks
	and place it behind a TLS-terminating reverse proxy.

[Patch76]

All three points are spot-on — thank you for the careful read!

Fixed in the latest commit:

1. DISABLED_TOOLS → corrected to ENABLED_TOOL_MODULES (the actual env var in config.py)
2. Sandbox escape line → removed entirely — it was a forward reference to the unmerged PR feat: add ha_manage_custom_tool — sandboxed code execution escape hatch #854, and "if that feature is enabled" was misleading since no user-controlled sandbox toggle exists today
3. CVE count → dropped "Two" — the linked GHSAs already carry the relevant detail and won't go stale

[kingpanther13]

Solid addition. All factual claims verified:

• ENABLED_TOOL_MODULES confirmed in config.py
• ha-mcp-oauth confirmed as entrypoint in pyproject.toml
• Both GHSA links are real and match the described vulnerabilities
• Advisory URL format is correct

One minor note: GHSA-fmfg-9g7c-3vq7 is labeled "SSRF" in the OAuth warning but its actual title is "network reconnaissance via an error oracle" — closer to info disclosure than SSRF. The link speaks for itself so not blocking on it.

Good job addressing all the review feedback, especially the DISABLED_TOOLS → ENABLED_TOOL_MODULES catch from @sergeykad and removing the forward reference to the unmerged sandbox tool.