Security Tracker
I believe I mentioned this in passing with @businessdad and @Linc
In my personal opinion it would be a good idea to have a security tracker.
Given the sensitive nature of security issues as has been mentioned by Linc, and I agree, security issues need to be submitted confidentially amongst trusted parties.
This has be happening quite well recently. However there lacks a formal process, and critically a tracker to keep track of outstanding issues, and interface for which to do it.
Not only is important that security issues are address in a timely manner. It is also import to be seen to addressing these issues (with divulging the sensitive materials).
I'm not proposing a bespoke solution, but to to search for existing software that would fit the bill. Something that allows the person who has found the security exploit to submit that information, to be shared.
Where I think the being seen to care would fit in, would be (perhaps controversially), to grade the open security issues and then declare then information publicly. I understand this is a big deal, but on the other hand it provides confidence that things will be dealt with, and I think they will be dealt with in a timely manner.
This shows trust, and this should be hopefully reciprocated.
Also formally making people aware they need to update, in core would be a good feature to have eventually.
grep is your friend.
Comments
I think it would be a very good idea. It's always a pain to admit that there are holes in a product, but keeping the users informed (without disclosing the exact details) shows sense of responsibility. It would also give the reporter the feeling that the contribution was acknowledged and is being taken care of. Another good side effect is that such disclosures would be less likely to appear in places like ExploitDB, which usually contain all the steps to reproduce them, available publicly.
My shop | About Me
Good points
grep is your friend.
Any suggestions as to software?
grep is your friend.
You could use Asana. Have an external form. Then use the API to create a task, and a guest user with task only permissions.
https://asana.com/guide/learn/basics/permissions
grep is your friend.
Good input, thanks. I'm raising this with the rest of the team. My preferred solution would be a private GitHub issue tracker.
I don't know enough about private GitHub to know how it would work. Worth investigating anyway.
grep is your friend.
A normal repo, just without the code and with a whitelist of users who can see it.
The problem with that is they can see all the issues. You might not want that.
grep is your friend.
Or would you handle issue submission some other way?
grep is your friend.
I would continue to handle submission via email as we currently do. The issue tracker I see as purely organizational. I don't want anyone needing to create special accounts to tell us about a security issue. Some of those folks don't exactly want to be known.
Yes but can they submit to the tracker? I'm not saying they want to to be know but their anonymity is their purgative.
It somewhat defeats the purpose of having a tracker, if nobody is aware of it.
The reason for suggesting the tracker was to foster cooperation, in a sand-boxed way. Not to to tell you how to mange projects internally.
grep is your friend.
Also if I submit a security issue, it reasonable to comment, help, make suggestions, step to repeat, etc.
grep is your friend.
I think the proper way to cooperate would be over email to support at vanillaforums.com. Having an additional management system with its own login that's only used when a security issue is reported sounds like managerial overhead that will go unused when the rubber hits the road.
You had a bad experience reporting via private message here, and I apologize for that. We now run reports thru our support team to make sure there is another group keeping watch and making sure the developers respond in a timely way.
The purpose of the tracker, from my perspective, is simply to increase visibility between developers and make sure a process is followed. Better communication is what we need, not another piece of special software.
I don't have a problem cooperating over email, but you can send that email to the tracker, or invite an email on a issue. Therefore it is kept together rather than risk getting lost.
I wasn't suggesting separate logins, necessarily.
grep is your friend.
People who summit security report are valuable to you, including them in the process is no bad thing.
Then eventually you could invite them as a security team contributor.
The sense there is no process is a sense of futility from the outside.
grep is your friend.
The emails to support are collected in a private category on the .com Help forum, so they do get collected & managed as 1 ticket already that has an open or resolved status. So, I think maybe we're already doing what you're requesting as far as coordinated feedback to the reporter now. My thoughts were about how to better internally manage those issues because I don't think we're quite "there" yet.
So that user can follow the progress of the security issue? the one that submitted the issue?
Why not create a github issue from it. Then use the webhooks to post back to the ticket.
I think the person that submits the issue has some right to know what step you are taking on the issue, especially if they have provided detailed information themselves. They may be able to assist further.
grep is your friend.
In other words they share, you share. Give and take, in private mutual conversation.
grep is your friend.
I think that is the responsibility of the developer handling the security issue and it's at their discretion to reveal information to the reporter and work with them depending on who they are.
What if they report vulnerability X, and that causes us to uncover more serious problems Y & Z when we start investigating the issue? I don't want to leak further problems until they are solved.
Support tickets are a good way to close the feedback loop to the reporter. I do not, however, think reporting a security issue gives someone the automatic right to sit in on our entire process for fixing it.
I let you be the judge of that, but is some cases it might be worthwhile depending on the nature of the report, and what they have to offer.
grep is your friend.