Revise SECURITY.md with new email and patch schedule

[HackingRepo]

PR Summary by Qodo

Update SECURITY.md contact email and document Patch Tuesday schedule
📝 Documentation 🕐 Less than 5 minutes

Walkthroughs

User Description

Updated contact email for security reports and added a section on Patch Day.

AI Description

• Update the security report contact email and deprecate the previous address.
• Add a “Patch Day” section describing the weekly Tuesday patch cadence.
• Clarify expectations to report vulnerabilities privately rather than via PRs/issues.

Diagram

graph TD
  R["Security researcher"] --> E["Report via email"] --> M["Maintainer triage"] --> S["Patch Day (Tuesday)"] --> P["Patch release"]
  subgraph Legend
    direction LR
    _a["Actor"] ~~~ _p["Policy/Process"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Adopt GitHub Security Advisories (private reporting)

• ➕ Standardized private disclosure workflow inside GitHub
• ➕ Better tracking, notifications, and CVE support (where applicable)
• ➕ Reduces reliance on a single email inbox
• ➖ May require repository security settings and maintainer familiarity
• ➖ Some reporters may prefer email-only workflows

2. Publish a security.txt alongside SECURITY.md

• ➕ Industry-standard discovery mechanism for security contacts
• ➕ Supports multiple contacts/keys and clearer reporting metadata
• ➖ Adds another artifact to maintain
• ➖ Doesn’t replace the need to keep SECURITY.md accurate

Recommendation: The PR’s approach (updating SECURITY.md) is appropriate for a quick contact/policy update. Consider tightening the “Patch Day” wording for clarity and professionalism, and optionally adopt GitHub Security Advisories or a security.txt to standardize intake and reduce ambiguity about where to report issues.

File Changes

Documentation (1)

SECURITY.md Update security contact email and add Patch Day policy +9/-2

Update security contact email and add Patch Day policy

• Replaces the listed security reporting email with a new address and explicitly deprecates the old one. Adds a new “Patch Day” section describing a Tuesday patch cadence and reiterating that vulnerabilities should be reported privately.

SECURITY.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

1. Ambiguous report email 🐞 Bug ⛨ Security

Description

The Contact instruction includes both the new and deprecated email in one sentence, making it
unclear which address should receive vulnerability reports and increasing the chance reports are
misrouted or delayed.

Code

SECURITY.md[32]

+Send your report to the email **<relunsec@insitetech.jp>** no longer **<cs7778503@gmail.com>** the old email.

Evidence

The Contact line explicitly contains both email addresses in the same sentence, which is ambiguous
about the intended destination.

SECURITY.md[30-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Contact section currently includes both the new and old email in the same instruction, which creates ambiguity about where to send security reports.

## Issue Context
Security reporting instructions should be unambiguous to avoid misrouting sensitive disclosures.

## Fix Focus Areas
- SECURITY.md[32-32]

## Suggested change
Rewrite to name only the current inbox (and optionally mention the old inbox separately as "deprecated; do not use" without repeating it as a destination). For example:
- "Send your report to: relunsec@insitetech.jp"

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Patch policy delays unclear 🐞 Bug ☼ Reliability

Description

The new Patch Day section states vulnerabilities will be patched "Tuesday of the next week" and
provides no exception/escalation path for critical or actively exploited issues, potentially
extending exposure due to an implied fixed delay.

Code

SECURITY.md[R83-87]

+## Patch Day
+
+Patches before arrives in any day, but now will be vulns patched in Tuesday of the next week to match the standard patch **Tuesday** phenomen, So security researchers need not leak vulns via PRs and issues anymore, they need use those above
+reporting methods.
+

Evidence

The Patch Day paragraph explicitly commits to patching on "Tuesday of the next week" and does not
mention severity-based expedited handling or an emergency release path.

SECURITY.md[83-87]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Patch Day section currently implies fixes are shipped on the next Tuesday, without specifying how urgent/critical vulnerabilities are handled. This can be interpreted as intentionally delaying all security fixes and lacks an emergency process.

## Issue Context
Security policies typically differentiate between routine patch cadence and expedited response for high-severity or actively exploited vulnerabilities.

## Fix Focus Areas
- SECURITY.md[83-87]

## Suggested change
Rephrase the Patch Day section to:
- clarify that triage starts immediately upon report receipt,
- state that routine fixes are targeted for Tuesday releases,
- add an explicit exception for critical/actively exploited issues (out-of-band patches),
- restate the non-public disclosure request clearly (e.g., "Please do not disclose via PRs/issues; use the reporting channels above").

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[codacy-production]

Not up to standards ⛔

🔴 Issues 3 minor

Alerts:
⚠ 3 issues (≤ 0 issues of at least minor severity)

Results:
3 new issues

Category	Results
CodeStyle	3 minor

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}