Skip to content

Auto-acknowledge incoming security reports from the mailing list #76

@abstractj

Description

@abstractj

Description

Description

When the bot receives an email from an external reporter on the keycloak-security@googlegroups.com mailing list and creates a corresponding GitHub issue in keycloak/keycloak-private, it should automatically send an acknowledgment reply back to the reporter. Today this is done manually, which costs the team a few minutes per report and risks leaving reporters without confirmation that their report was received.

Value Proposition

Security reporters need to know their report landed. A delayed or missing acknowledgment creates uncertainty, reporters may re-send, escalate through other channels, or lose confidence in the process. Automating this removes manual overhead for the team and gives reporters consistent feedback.

Goals

  • Automatically reply to the reporter's email when the bot successfully creates a GitHub issue from an incoming mailing list message
  • Use a standard, professional acknowledgment template
  • Preserve Gmail threading so the reply appears in the same conversation as the original report
  • Only send the ack for new reports (first email in a thread that triggers issue creation), not for follow-up messages on existing threads

Non-Goals

  • Customizing the reply per report (the message is intentionally generic)
  • Replying to emails that fail to create an issue
  • Changing the existing email-to-issue sync logic

Notes

The suggested acknowledgment template:

Hi,

Thank you for taking the time to report this — we really appreciate it.

We've received your security report and our team will review it. We'll get back to you if we need more details.

Thanks for helping make Keycloak better.

Best regards,
Keycloak Security team.

Implementation suggestion — templates/ directory:

Rather than hardcoding the ack message or placing it in application.properties, consider introducing a src/main/resources/templates/ directory containing markdown files for standard responses. For example:

src/main/resources/templates/
├── ack-security-report.md
├── request-more-info.md
└── ...

Each file would hold a complete, ready-to-send message body. This approach:

  • Keeps message content out of code and configuration, easier for non-developers to review and update
  • Scales naturally as the team adds more standard responses (e.g., "requesting more info", "report accepted", "not a vulnerability")
  • Supports markdown formatting natively, which renders well in both email and GitHub comments
  • Makes templates reviewable in PRs alongside code changes

Discussion

No response

Motivation

No response

Details

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions