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
41 changes: 41 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Security Policy

## Reporting a Vulnerability

If you believe you have found a security vulnerability in `acbu-backend`, please report it privately and do not open a public issue.

Use GitHub's private vulnerability reporting for this repository:

- Go to the repository's **Security** tab
- Select **Report a vulnerability**
- Provide the details requested in the form

If private reporting is unavailable, contact the repository maintainers through GitHub as privately as possible and avoid posting exploit details publicly.

Comment on lines +7 to +14

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 & Privacy | 🟠 Major | ⚡ Quick win

Add explicit security team contact and reference the CODEOWNERS security team.

The current reporting instructions rely on GitHub's private vulnerability reporting and a vague fallback to "repository maintainers." Issue #480 requests a specific point of contact for external researchers. The CODEOWNERS file shows @Pi-Defi-world/security-team owns security-sensitive directories (prisma/, src/services/, src/controllers/, src/routes/), yet this team is not referenced in the disclosure policy.

Add an explicit mention of the security team and a dedicated contact method (e.g., security team email or GitHub team handle) to ensure researchers know where to route reports when GitHub private reporting is unavailable.

🤖 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 7 - 14, Add an explicit disclosure contact in
SECURITY.md by referencing the CODEOWNERS security team
(`@Pi-Defi-world/security-team`) and a dedicated contact method for external
reports when GitHub private vulnerability reporting is unavailable. Update the
reporting guidance text to replace the vague “repository maintainers” fallback
with a clear security-team route, using the security policy section as the place
to locate and edit the disclosure instructions.

## What To Include

Please include as much of the following as you can:

- A short description of the issue
- The affected endpoint, service, or workflow
- Steps to reproduce
- Any proof of concept, logs, or screenshots
- The potential impact
- Whether the issue is currently exploitable in production or only in development

## Response Expectations

We will acknowledge security reports as soon as practical, investigate privately, and coordinate a fix before any public disclosure when possible.

Please allow reasonable time for triage and remediation before sharing details publicly.

## Safe Harbor

We consider good-faith security research to be helpful. Please avoid:

- Accessing data you do not own or are not authorized to access
- Modifying or deleting data
- Disrupting service availability
- Exfiltrating secrets, credentials, or personal data

If you accidentally encounter sensitive information during testing, stop immediately and report it through the private channel above.
Comment on lines +32 to +41

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 & Privacy | 🟠 Major | ⚡ Quick win

Expand safe harbor with explicit authorization and scope boundaries.

The current safe harbor lists prohibited activities but lacks:

  1. Explicit authorization statement: Researchers need confirmation that good-faith testing of this repository is permitted
  2. Scope definition: Clarify which systems, endpoints, or environments are in scope (e.g., production API, staging, specific domains)
  3. Legal safe harbor commitment: Explicit statement that the project will not pursue legal action against good-faith researchers who comply with this policy

Without these elements, researchers lack legal clarity, which discourages participation and undermines the policy's purpose.

🤖 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 32 - 41, The Safe Harbor section in SECURITY.md
needs to explicitly state that good-faith security testing of this repository is
authorized, define the allowed scope by naming the in-scope systems/environments
or endpoints, and add a clear legal safe-harbor commitment that the project will
not pursue legal action against researchers who follow the policy. Update the
existing Safe Harbor text to keep the current prohibited activities while adding
these missing authorization and scope boundaries in the same section.

Loading