We definitely don't want to discourage you from contributing. It also doesn't necessarily have to be money, you could stake reputation you've previously earned.
The dupes problem is super important, in my opinion, because it's currently an unpleasant experience for both sides. Not getting paid out for valid work that has simply been reported before (but not disclosed) can make doing this kind of research as a freelancer unfeasible, while triaging duplicate reports burns time for dev teams.
We've tried to build out in-scope/out-of-scope functionality that makes it super simple to keep your scopes current (could even update automatically via API). We definitely want to build out additional functionality that makes publicly acknowledging known, 'won't fix', and non-impactful issues super easy, perhaps by pulling most of the information from a duplicate report. Do you think that’d be useful?
The other thing we want to really focus on is the disclosure process, and encouraging companies to do it as often and soon as possible.
I agree with you, they aren't very informative. We're big fans of BugCrowd's work in this area, and intend to adopt their VRT, though we're still considering how to make P1/P2/P3/P4 more clear/descriptive at a glance.
We're also still brainstorming and looking for good ideas on how to handle duplicate reports. At this point, we're tackling it by vetting researchers and helping with the ones who ignore 'Known Issues' and out of scope limitations. Like HackerOne, we're very interested in encouraging companies to disclose their vulnerabilities, because these disclosures are important to their users, the people who may build on top of any service they offer, and the researchers who are being given public credit.
In regard to a company marking a bug a duplicate to avoid bounties, those are definitely not the type of companies we want to work with. I'm not sure that technical solutions to mitigate that sort of behavior is necessary when we can curate those who have access to the platform. We’re going to keep a high quality of researchers and companies -- and it goes both ways.
Our Vulnerability Disclosure Policy Template, which is based primarily on Chris Evan's work @ Dropbox, and is inspired by a bunch of other well-written programs too, puts full control of payments/recognition into the hands of the company. I think our best recourse on this issue is to simply not include bad actors.
Do you have any ideas for other ways we can limit dupes? Or how to really effectively communicate what is out of scope or a known issue?
Hah, yeah, this stuff is hard and acquisitions make it even harder.
I think you started a month after I left. We built a lot at MoPub in a short period of time and when we were acquired I had a mile-long backlog. The Twitter security team was great though and built a war-room during integration. We worked some intense hours leading up to the IPO and over the Holidays, and I’m proud of the work we all did. We migrated a sprawling stack that supported what was then the largest mobile ad exchange and billions of sub-second auctions over just a few weeks. Most of the MoPub team transitioned to other projects and teams quickly though and I left not that long after.
Totally agree that it starts at the top. If the C-level doesn’t care, there just won’t be the resources it takes to build good, secure software. We intend to focus on supporting companies who do care, and we think this focus will also impact how companies using Federacy interact with researchers. We want outside researchers to be viewed as allies, not as a burden.
Have any thoughts on how we can best accomplish this?
Draft | Operations/Backend/SRE/DevOps Engineers | New York, NY | Onsite | Full-time | Salary: $135-$170k
Do you...
Enjoy building scalable, distributed systems with automation and modern tools?
Love telemetry and monitoring and view them as a means of validating success as much as diagnosing problems?
Know how to apply best practices to enable building of a resilient system across multiple geographic regions, as well as within a single zone?
Have enough determination to solve the vexing issues -- and the prudence to leave the non-pertinent challenges for later?
Have a "buck stops here" attitude, and feel personal responsibility for the availability and success of projects you contribute to?
Draft
DRAFT (get.playdraft.com) is the first truly mobile sports fantasy game. On DRAFT you can do quick head-to-head drafts with your friends (or random opponents), or draft in groups, leagues or tournaments. And you can even win real money doing it.
Team
We're proud of our flexible, collaborative atmosphere that stresses quality and efficiency over sheer velocity. We're looking for people who value integrity and humility, and take pride in the work they do. Our hierarchy is very flat and everyone is empowered to make or contribute to important decisions.
Scale
We were recently acquired by Paddy Power Betfair (ISE: PPB) and are preparing for a significant increase in users as a result of cross-promotion and the start of the NFL season. Accordingly, we’re looking for a few talented operations and back-end engineers to form the core infrastructure team to help us scale, build new features, and improve our engineering tools.
The conversion of package version numbers to vulnerabilities is perilous and incredibly complicated. That's one of the most significant challenges that we want to solve, which is even more pressing considering how badly the CVE ecosystem is breaking down.
That's correct, vuls queries the package manager for installed packages, versions, and changelogs. It then compares the CVEs found in the changelogs to NVD.
There are certainly flaws in this approach; it's one of the reasons we intend to support multiple scanners. We started with vuls because clair wasn't released yet and we wanted to support more than containers.
The only exception is when people have access to the underlying container, willing or not. Then these vulnerable binaries can lead to a vulnerable container.
This is also why the subjectivity in CVE rating is such a significant problem.
To add a bit of detail here, one of the most surprising things I found that I'm saving for my next post is: 24% of recent vulnerabilities in the NVD have no rating, and that doesn't even include the ones that weren't posted to NVD at all.
On top of this, the fact that the rating systems used by the different vendors/sources of vulnerabilities are quite different, and like you mentioned, the implicit subjectivism... it's a mess. But a solvable one! That's what I'm working on.
Absolutely agree. I did see some bad practices in the Docker community that I expect to see elsewhere as well. Specifically: reliance on deprecated images and not updating images during build. Thoughts?
I didn't address the implications of software vulnerabilities in respect to other mitigation techniques, however, as it's far outside the scope of the article. I probably should at least add a second addendum though. I'll work on this soon. Thanks!
I did some market research before I started working on Federacy (which began as frustrations I encountered at mopub/twitter). It seems that very few companies sub-hundreds of employees and thousands of servers have a security specialist, and almost no one is running vulnerability analysis in a real way.
CentOS/RHEL have a very small footprint in the open source community, it seems. I was pretty surprised by this because they have such significant corporate backing, a lot of enterprise software is RHEL only, and they may be the only linux distribution currently support SCAP (required by FISMA for federal agencies).
In order, I would opt for: binary image, alpine, then debian. There are other choices like CoreOS, FreeBSD, etc. if you are comfortable moving away from linux.
The dupes problem is super important, in my opinion, because it's currently an unpleasant experience for both sides. Not getting paid out for valid work that has simply been reported before (but not disclosed) can make doing this kind of research as a freelancer unfeasible, while triaging duplicate reports burns time for dev teams.
We've tried to build out in-scope/out-of-scope functionality that makes it super simple to keep your scopes current (could even update automatically via API). We definitely want to build out additional functionality that makes publicly acknowledging known, 'won't fix', and non-impactful issues super easy, perhaps by pulling most of the information from a duplicate report. Do you think that’d be useful?
The other thing we want to really focus on is the disclosure process, and encouraging companies to do it as often and soon as possible.