Usually not. Security addresses exist for reporting new vulnerabilities, not for support. The Apache Software Foundation, for example, says its security team will ignore questions about whether a published vulnerability applies to your versions or configuration, and points people to the project users list instead.
Reporting versus asking
There are two different jobs. Reporting means you found something new and want to tell the maintainers privately. Asking means a vulnerability is already published and you need help applying it to your system. Mixing them overloads small security teams and delays real reports.
The Apache security pages list questions that should not go to the security contacts, including:
- how to configure the package securely
- whether a published vulnerability applies to specific versions you are using
- whether it applies to your configuration
- further information on a published vulnerability
- availability of patches or new releases
For those, the page says the relevant project's users list is the place. The Kubernetes page makes a related split: reports go to its bug bounty program or a private security address, while announcements come through a separate announce group.
Where to ask instead
- The project users list or discussion forum, if there is one.
- The public issue tracker, for questions that do not reveal anything sensitive about your own system.
- A distributor or vendor support line, if you consume the software through one.
- Your own security team, which may already have the answer in your SBOM and scan results.
Check the project's SECURITY.md or security policy first. It normally says where each kind of message belongs.
What a good question looks like
Maintainers answer faster when you do the homework. Include:
- The advisory ID and link.
- The exact version you run and how you installed it.
- What you tried: did you upgrade, did the scanner still flag it?
- A specific question, for example "Does this affect the client library or only the server?"
Leave out company secrets, internal hostnames and anything that describes how an attacker could reach your systems.
What you can often answer yourself
Many questions are answerable from the advisory. Look at the affected versions, the patched versions, any listed workaround, and whether the vulnerable component is one you load. Then check whether your code reaches it. If you have an SBOM, you can answer the version question in minutes. See our checklist for reading a vendor security advisory.
If you think you found a new problem
Then it is a report. Use the private channel in the project's policy, give a clear reproduction, and avoid posting details publicly until the maintainers agree.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis help answer "does this apply to us" from your own data, which cuts down the questions you need to send. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is it rude to email a maintainer about an advisory?
It depends on the channel. Many projects, such as Apache, ask that advisory questions go to a public users list, so use that route and keep the message specific.
Where do I send a brand new vulnerability?
To the private route in the project's security policy. Do not post it publicly first.
Sources
Last reviewed: 19 October 2026.
