Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,11 @@
This document outlines the versions of our project that receive security updates, as well as how to report vulnerabilities responsibly.

Supported Versions
Version Supported?
5.1.x ✅ (Active security updates)
5.0.x ❌ (No longer supported)
4.0.x ✅ (Limited security fixes)
< 4.0 ❌ (No longer supported)
# Security Policy

Check notice on line 1 in SECURITY.md

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

SECURITY.md#L1

Expected: [None]; Actual: # Security Policy

## Supported Versions

| Version | Supported |
| ------- | ------------------ |
| All | :white_check_mark: |
Comment on lines +5 to +7

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

❓ Verification inconclusive

🏁 Script executed:

#!/bin/bash
# Description: Check for version tags and release history to verify if claiming "All" versions are supported is appropriate.

# Check for version tags
echo "=== Version tags in repository ==="
git tag -l | grep -E '^v?[0-9]+\.[0-9]+' | sort -V | tail -20

echo -e "\n=== Recent releases ==="
gh release list --limit 10

echo -e "\n=== Check for version file ==="
fd -t f 'version|VERSION' | head -10

Repository: LCSOGthb/Games

Length of output: 150


Clarify “All versions supported” in SECURITY.md (and fix reporting instruction clarity)

The SECURITY.md supported-versions table now declares “All” versions as supported, which is a large security-policy change; the earlier version-specific ranges no longer appear. Repo inspection for version tags/releases/version files returned no usable indicators so far, so it’s not possible to tell whether “All” is intentional or overstated—please update the table to reflect the actual supported version/range policy (or document why every historical version is covered).

Also, the vulnerability reporting instruction (“Go to Issues Report a Vulnerability”) is still unclear and missing obvious formatting/linkage.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@SECURITY.md` around lines 5 - 7, Update SECURITY.md to replace the ambiguous
"All" entry in the supported-versions table with the actual supported version
range or a clear justification that every historical release is supported (edit
the table header "Version | Supported" and the row currently showing "All |
:white_check_mark:"), and correct the vulnerability reporting instructions by
adding a clear, linked action (for example "Report a Vulnerability" linking to
the Issues page or a dedicated security contact) and explicit steps for
reporters; ensure both changes are concise, factual, and preserve the existing
table and reporting section structure.


## Reporting a Vulnerability

Go to Issues Report a Vulnerability

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (typo): Clarify the vulnerability reporting instruction sentence.

The wording reads incomplete. Please rephrase to make the steps explicit, e.g. "Go to Issues > Report a vulnerability" or "Go to Issues and select Report a vulnerability" so the instruction is grammatically clear.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 Info: Vulnerability reporting instructions lack actionable link or detail

The new vulnerability reporting text at line 11 reads Go to Issues Report a Vulnerability, which is vague — it doesn't include an actual URL, a link to the GitHub Issues tab, or instructions on how to privately report a vulnerability. The previous version also lacked this detail, but since the section is being rewritten, it would be worth making this actionable (e.g., linking to the repo's Issues page or using GitHub's private vulnerability reporting feature).

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-medium medium

The instruction for reporting a vulnerability is incomplete and lacks a functional link. It is recommended to provide a clear path, such as a link to the repository's security advisories page, to ensure that security issues are reported through the appropriate channels.

Suggested change
Go to Issues Report a Vulnerability
Please report vulnerabilities via the Security tab of this repository.

Comment on lines +9 to +11

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Public vuln reporting path 🐞 Bug ⛨ Security

SECURITY.md’s only reporting guidance is the malformed text “Go to Issues Report a Vulnerability”
and it does not provide a private disclosure channel, which can lead to public vulnerability
disclosure. This makes responsible disclosure hard/impossible for reporters to follow.
Agent Prompt
## Issue description
`SECURITY.md` currently provides an incomplete instruction (“Go to Issues Report a Vulnerability”) and does not include a private disclosure mechanism. This can cause reporters to file public issues for security vulnerabilities.

## Issue Context
The repository surfaces GitHub Issues prominently, so directing security reports to “Issues” is risky without explicit private-reporting guidance.

## Fix Focus Areas
- SECURITY.md[9-11]

## Suggested change
Update the “Reporting a Vulnerability” section to include a private reporting path (and make it an actual link), e.g.:
- Direct users to GitHub’s private vulnerability reporting: `Security` tab → `Report a vulnerability` (or link to the repository’s `/security/advisories/new` page).
- Optionally include a security contact email and an expectation for acknowledgement/response timelines.
- Explicitly state: “Please do not open a public GitHub issue for security vulnerabilities.”

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Clarify the vulnerability reporting instructions.

The current instruction "Go to Issues Report a Vulnerability" is ambiguous and lacks proper formatting. It's unclear whether this refers to a GitHub tab, a button, or a specific workflow.

📝 Suggested improvements

Option 1: If using GitHub's private vulnerability reporting feature:

-Go to Issues Report a Vulnerability
+To report a vulnerability, please use GitHub's [private vulnerability reporting feature](https://github.com/LCSOGthb/Games/security/advisories/new).

Option 2: If reporting via Issues:

-Go to Issues Report a Vulnerability
+Please report vulnerabilities by [creating a new issue](https://github.com/LCSOGthb/Games/issues/new) with the "Report a Vulnerability" template.

Option 3: If directing to the Security tab:

-Go to Issues Report a Vulnerability
+To report a vulnerability, navigate to the [Security](https://github.com/LCSOGthb/Games/security) tab and click "Report a vulnerability".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@SECURITY.md` at line 11, Replace the ambiguous line "Go to Issues Report a
Vulnerability" with a clear, formatted set of instructions that specifies the
exact reporting path and options: e.g., provide three distinct bulletized
options titled "Report via GitHub private vulnerability reporting", "Report via
Issues", and "Report via Security tab", each containing the precise UI action to
take (e.g., "Open this repository's Issues tab → New issue → choose 'Report a
vulnerability' template" or "Navigate to the Security tab → Report a
vulnerability"), and ensure the original phrase is removed and the new text uses
proper markdown headings/bullets and a link to a preferred contact (email or
security policy) for sensitive reports.

Loading