SecurityProcessCommunity

How to Accept and Triage Security Reports for Small Self‑Hosted Projects

sselfhosting

2026-02-03

9 min read

Build a one-person vulnerability intake: security.txt, PGP, templates, and triage SLAs for small self-hosted projects.

Stop fearing security reports — accept them with a 1-person, low-friction flow

As a maintainer of a small self-hosted project you face a recurring problem: community researchers find bugs, but you don’t have the time or budget to run a formal bug-bounty program. You need a secure, reliable way for people to report vulnerabilities without an entire security process team. This guide shows how to build a lightweight vulnerability intake and triage flow—email templates, PGP, issue-tracker rules, and disclosure language—so researchers can responsibly report issues and you can resolve them fast.

Why this matters in 2026

Late 2025 and early 2026 accelerated several trends that directly affect small projects: supply-chain scrutiny, wider adoption of SBOMs and SLSA provenance checks in CI workflows, and a growing expectation that even small teams publish a clear vulnerability disclosure path. Attackers increasingly exploit low-hanging self-hosted targets, and researchers expect at minimum a reachable contact, a PGP key or encryption channel, and a realistic timeline. You don’t need a full bounty program; you need a clear, minimal intake flow that builds trust and reduces noise.

What a minimal, effective intake flow looks like

At its core, the flow has five components. Each is small, actionable and suitable for one-person teams:

Contact point: a monitored security email like security@yourdomain.example and a published security.txt
Encrypted reporting: a public PGP (or modern 'age') key so reporters can send PoCs and credentials safely
Issue-tracker routing: private issues or a separate repository with labels and triage automation
Simple triage SLA: clear ack/response windows (e.g., ack within 72h, decision in 7d)
Disclosure policy & safe-harbor: short text telling reporters how you will handle reports and that you won’t pursue legal action for good-faith research

Design constraints for small projects

Keep manual steps under 15 minutes per report initially.
Minimize public exposure of PoCs before a fix.
Use existing free tools: email, GitHub/GitLab issues, GPG, and security.txt.

Step-by-step setup (practical)

1) Create a reachable contact and publish security.txt

Publish /security.txt at the project root and at the domain root (/.well-known/security.txt). Include contact details, encryption key URL, and preferred disclosure timeline. Sample security.txt:

Contact: mailto:security@yourdomain.example
Encryption: https://yourdomain.example/pgp-key.txt
Acknowledgement: https://yourdomain.example/security/acknowledgements
Preferred-Languages: en
Canonical: https://yourdomain.example/.well-known/security.txt
Expires: 2026-04-01T00:00:00Z

Keep the Expires timestamp updated. Security.txt is a recognized standard (RFC 9116) and is commonly checked by researchers and tooling in 2026.

2) Publish a PGP key (and consider age as a modern option)

PGP remains the most widely understood method for encrypted vulnerability reports. Provide a short guide to verify the fingerprint and host the public key at the URL you referenced in security.txt. Example commands to create a key and export a public file:

# create a key
gpg --full-generate-key

# list keys to get the key ID and fingerprint
gpg --list-keys --fingerprint "yourname@example.com"

# export public key text
gpg --armor --export yourname@example.com > pgp-key.txt

Include the 40-character fingerprint in your security page so reporters can validate the key. Example fingerprint line on your site:

PGP fingerprint: 1234 5678 9ABC DEF0 1234 5678 9ABC DEF0 1234 5678

In 2026 many researchers prefer age for one-off encrypted messages because it’s simpler and safer against legacy PGP pitfalls. You can support both: publish a PGP key and an age recipient line.

3) Set up an intake mailbox and storage rules

Use security@ forwarded to an account you check daily. Configure these rules:

Auto-reply with an acknowledgement template (see below).
Route encrypted attachments to an encrypted archive or secure ticketing system.
Store reports in an access-controlled archive (encrypted backups) and avoid public mailboxes.

4) Use your issue tracker with a private path

GitHub/GitLab supply built-in security advisories, but if you prefer keeping things simple use a private repo or an Issues repository dedicated to security with a small set of labels. Recommended labels and conventions:

security-report (internal only)
severity:critical / severity:high / severity:medium / severity:low
status:triage / status:in-progress / status:awaiting-info / status:patched / status:closed
component:web / component:auth / component:db

Example workflow: New email > create private issue > label severity > assign > notify reporter. If your issue tracker supports it, restrict visibility until you publish an advisory.

Triage policy and SLA (practical rules for small teams)

Keep triage rules short and automatable. Example SLAs that work for single maintainers:

Acknowledgement: Within 72 hours (auto-reply message immediately)
Initial triage decision: <= 7 days (confirm severity and whether you need more info)
Fix / mitigation timeframe: Critical & high: publish hotfix or mitigation within 14 days if practical; medium/low: prioritized by roadmap but aim for 30–90 days

Map your severity to observable impact. Use a short mapping based on CVSS for familiarity:

Critical: unauthenticated remote code execution, account takeover of many users, large data exfiltration
High: privilege escalation, authenticated RCE, wide-impact PII exposure
Medium: logic flaws with limited impact or difficult to trigger issues
Low: UI bugs, minor info leaks, non-security functional issues

Quick triage checklist (first pass)

Verify the reporter’s identity and PGP signature if provided.
Reproduce within a disposable environment and collect logs.
Classify severity and assign a label/assignee in your tracker.
Decide public/privileged disclosure path and draft an embargo timeline if necessary.

Email templates you can copy

Use these short templates verbatim to reduce back-and-forth. Replace bracketed text.

Acknowledgement (auto-reply)

Thanks — we received your report.

We appreciate the responsible disclosure. This is an automated acknowledgement. We will triage the report and reply with a status update within 72 hours.

If you included an encrypted attachment, ensure it is encrypted to the PGP fingerprint published at https://yourdomain.example/pgp-key.txt.

Thank you — the maintainer team, YourProject

Request for more info

Thanks for the report. We are working on triage but need additional details to reproduce:
- Steps to reproduce (copy/paste)
- Exact versions and any backend config
- PoC code or logs encrypted to our public key

Please avoid public disclosure while we investigate. We will update you within 7 days.

Patch/mitigation note (to reporter before public disclosure)

We’ve implemented a fix in commit  and will publish a security advisory on . If you’re able, please test the patched version and confirm. We’d like to thank you in our acknowledgements unless you request anonymity.

If you prefer a stipend or other recognition, please let us know and we will consider a one-time payment or credit.

Safe-harbor / legal language

We welcome good-faith security research. Please avoid tests that affect availability for other users, do not access or destroy data, and limit testing to accounts you control. We will not pursue legal action for good-faith reports sent to security@yourdomain.example.

Handling PoCs, exploits and sensitive data

Do not store PoCs or credentials in plaintext in public places. Recommended handling:

Require encrypted attachments (PGP or age).
Download to a locked machine and move into an encrypted archive (e.g., gpg --encrypt --recipient ...).
Limit access to the minimum number of people on your team; audit access with a changelog.
When publishing advisories, remove or sanitize PoCs that enable mass exploitation; provide high-level reproduction steps instead.

Rewards and alternatives to bug bounty programs

Full managed bounty programs are expensive. Instead, consider these low-cost recognition options which work well for smaller projects:

Public acknowledgements in release notes (default)
One-time small payments (via Paypal, GitHub Sponsors, or OpenCollective)
Swag: stickers, shirts, or digital credits
Expedited support or priority feature review

Make the reward optional and announce a small budget on your disclosure page: e.g., "We maintain a discretionary bounty pool for significant security reports." This transparency increases researcher engagement without binding you to fixed payouts.

Automation: small but powerful

Automate repetitive steps so you focus on judgement. Ideas for one-person teams:

Auto-create issues from incoming mail using your mail provider’s rules and a webhook.
Use GitHub Actions to tag and route security issues to a private project board.
Store encrypted backups of reports in a dedicated bucket with MFA and restricted keys.

Case study: FileShareX (hypothetical)

FileShareX is a small self-hosted file server maintained by a single developer. In mid-2025 they implemented the simple flow described here. Results within 6 months:

Average acknowledgement time: <24 hours (auto-reply + manual confirm)
Two high-impact reports were triaged and patched within 10 days.
Researcher trust increased: both reporters accepted acknowledgment credit and one received a small discretionary payment.
Administrative overhead was <2 hours/week.

Key win: early encrypted reporting prevented leaking credentials publicly and allowed time-limited coordinated disclosure.

Checklist to launch in 30 minutes

Create security@ forwarding address and set auto-reply (ack template).
Generate a PGP key, export public file to /pgp-key.txt, publish fingerprint on site.
Publish /.well-known/security.txt with contact and encryption URL.
Create a private repo or security issue board with labels listed above.
Add the short safe-harbor paragraph to your security page.
Draft the three email templates and store them in your secure notes.

Future-proofing and 2026 trends

Through 2026, expect researchers to look for these signals before reporting:

An up-to-date security.txt and a verifiable PGP/age key
Evidence of basic supply-chain hygiene (SBOM generation and automated dependency scanning)
A clearly stated timeline and safe-harbor

Invest a little time in SBOM generation and automated dependency scanning — these reduce report volume for dependency-related vulnerabilities and increase researcher confidence in your project.

Common pitfalls and how to avoid them

Pitfall: No encryption option. Fix: Publish PGP and an age recipient and enforce encrypted attachments for PoCs.
Pitfall: Publicly visible PoCs in issues. Fix: Create private ticketing or redact PoCs until patched.
Pitfall: Vague timelines. Fix: Publish simple SLAs and stick to them.

Resources and references

Security.txt (RFC 9116) — use it to publish contact & encryption info
GPG manual — for PGP key generation and verification
Consider Disclose community templates and the OpenSSF guidance for small projects

Final recommendations (actionable takeaways)

Publish a security contact and encryption key today: security.txt + pgp-key.txt.
Set a simple SLA: auto-acknowledge, triage in 7 days.
Use private issues and labels for triage; keep PoCs encrypted and access-controlled.
Offer low-cost rewards and public credit to encourage good-faith researchers.

Start small, be predictable. A lightweight, documented intake flow signals that you take security seriously — and researchers will treat your project with greater care in return.

Call to action

Ready to accept your first report? Publish a security.txt and PGP key this week, set up security@, and copy the templates above. If you want, clone a lightweight template repo (issue templates, security.txt, and PGP key placeholder) and adapt it for your project. Implement the checklist and share your experience with the self-hosting community — it helps others secure their stacks faster.

selfhosting

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.