Reporting a directory listing for a package repository as a vulnerability is clearly not valid. Reporting lack of a captcha for a registration / login form is also clearly not valid. Captchas make websites less accessible and are a privacy/security issue when it's third party.
Conversation
Replying to
It is fair and helpful that you set your own criteria! I wanted to suggest that publishing a policy listing the things you do want to receive could help limit the noise so that you could keep your security e-mail open. Also, you can auto-close irrelevant by pointing to the policy
1
Replying to
It's not our own criteria. It's basic critical thinking.
We do have a security.txt and it's the opposite of helpful because it's likely what's attracting these people to the site since they associate it with being able to get paid bug bounties for low effort reports.
1
1
Likely removing the security@ emails and security.txt we've published. They're completely unhelpful and only take away security resources from handling actual security improvements and bug reports including valid AOSP security bug reports we receive on a somewhat regular basis.
1
1
The security.txt standard is the problem, not the solution. By including it we ended up on lists of sites including a security.txt which is attracting grifters who would not be sending this kind of spam to our actual issue tracker. I wish we could undo ever publishing those.
1
Replying to
Sorry to hear that. I failed to spot the security.txt file at first pass (#fatfingers). We chose to publish a strict policy and state "We currently do not offer a reward in the form of money or giveaways, we will offer a place on our Acknowledgments page".
1
Replying to
grapheneos.org/contact states the following:
The security@grapheneos.org address is for reporting high priority security issues related to GrapheneOS. Please don't send other kinds of emails to this address. It is not a way of increasing the priority of emails that are not...
1
2
... security reports. Your emails will be treated as a much lower priority if you misuse this address.
It's clearly only for high priority security reports and yet we have received hundreds of emails at the address without a single one ever being a high priority security report.
1
1
It's only for things that are high enough priority that they should be privately reported. Most issues should just be publicly reported on our issue tracker. If someone genuinely thought we were missing a rate limit for a service the right place to report it is the issue tracker.
1
We've never had someone report a vulnerability in our own software or service. We've had multiple valid reports of AOSP security issues, some of which were serious, and some of which are still pending resolution upstream. We try to ship our own fixes early in some cases though.
1
security@ emails and security.txt have been the opposite of helpful because it just attracts people making invalid reports. We have an issue tracker for each of our services, each of our standalone projects and for GrapheneOS as an OS which is where we want most bug reports.
This was our attempt at providing an official place for people to report issues they genuinely believe are high priority and should not be disclosed publicly before there's a fix. It's counterproductive when it's wasting on our time and energy instead of doing useful work.
1
1
Replying to
If I had a podcast I would invite you on to cover this topic. I can see there is a need for awareness on this topic! I've also seen companies receive automated GDPR #deleteme notices. There are certainly fractions trying to make a buck on ab(using) valid tools.
1