jsulinski

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.

Apply at https://angel.co/playdraft/jobs/234940-operations-engineer-s... or shoot us an email: nicolo at playdraft.com.

How does this compare to say, Aerospike, or Honeycomb.io?

I don't fully understand the question.

clair does static analysis

vuls uses a package manager and changelogs

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.

This is a very well-written explanation.

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.

Thank you. I'll definitely be reaching out.

Good point. What I meant was comfort moving away from a major distribution.

NixOS is another distro that looks interesting.

Fixed!

Thanks sir! I redesigned my landing page and made it static; forgot to update the confirmation email link.

The command is a standard 'wget/bash' script that you will receive when you login, but it's pretty simple to grok.

I'll send you a new confirmation email soon.

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.

You're spot on. These are two of the things I intend on working on next.

Thanks for the links.

Absolutely. Huge props to CoreOS and the Kube community for pushing forward with this stuff.

I gave Clair a shout out in the article, and I intend on adding it as an optional scanner to Federacy.

Funny, I'm pretty sure we met before either of us started our existing ventures, when you came to the San Francisco DevOps meetups. :)

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.

Absolutely. I intended this post to identify (some of) the problems/challenges. My next post will focus on how to address them.

Alpine is definitely one of the major points, as well as static binary images and some advice on Dockerfile configuration.

I don't know the answer to this, but I do know that Alpine has some really awesome stuff around vulnerabilities, and I would presume that they react to vulnerabilities more quickly.

However, I intend to validate this presumption in a future project.

That's exactly what I'm trying to highlight. After you take that 'latest' image, if you're not applying updates regularly, you are vulnerable from almost day 1.

This also applies to most of the AWS, Digital Ocean, etc images I have seen as well. I'll be writing more about how to mitigate this in the next article.

Absolutely. Docker and Quay.io both offer scanning for repositories they host, there are open source options like vuls and clair that are a bit more work to set up, and we have a free plan for up to 5 hosts and for open source projects and schools.

Happy to help if you need a hand.

There absolutely is a pattern, but the thing is -- even if the image is updated at build, as soon as you deploy it, vulnerabilities begin to emerge.

To be clear, one of those lines relates to making sure you pull in upstream during image building. This is super important, as it seems that people have assumed their base image will be current and that is not always the case.

I will absolutely release some data. I intend to fully automate this research so that it is current whenever viewed as well.

Not sure about the state of CI/CD in the image building process, I assume it varies wildly. Two of the major points I'll address in my next posts are regarding deprecation in Docker repositories and lines of a Dockerfile important to minimizing vulnerabilities.