Shamiq

That's neat -- similar to a short squeeze.

Yea, I'm thinking about cases similar to HTTP parameter pollution, and what the program expectations are. You'd be right to argue environment variables should not be user controlled. :)

Will need to double check some machines to make sure these two don't bite me:

On Unix systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can now be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.

The os/exec package now prevents child processes from being created with any duplicate environment variables. If Cmd.Env contains duplicate environment keys, only the last value in the slice for each duplicate key is used.

Not that far off: https://en.wikipedia.org/wiki/Life_expectancy#/media/File:Li...

triplebyte mentions taking a particular problem from CtCI and solving it within 30min on a whiteboard (pen/paper, plaintext editor).

The email address field in your user form isn't public. you need to add it to text in your description.

dang, this is excellent. thank you so much :)

oh, I scrolled down and only saw the purchase option.

I don't have access to the full article, but the premise is interesting. at what transaction volume would I be better of running my own fgpa hardware?

Awesome project! This is a step in the right direction for better access management.

hah -- i found the same result with gofmt, golint, and go vet

That could be a decent hack to get started. Ideally, I'd like for it to be a feature of hackerone et al, assuming security@ as a service providers become the point of interaction with the external security community.

oh, i know -- i got spoiled working at matasano where we'd usually get the first crack.

I would love a Marauder's Map for bug bounty programs: Show me who is working on what, where they're finding bugs, and help me identify where I can most efficiently spend my time. Lots of 'feel bads' if I report a bug that's already been reported, and thus don't get a payout.

I'm color blind, and the charts you use are unintelligible to me.

Congrats on the launch! Why the choice to build on Kubernetes?

Just stick it up on medium for the time being. you can always figure out a 'real' blog later :).

Alternative is using github pages with something like jekyll.

You've got a point there, but I'd ask why not remove the packages that aren't being used? Here's some of the raw data about which system libraries are lagging in security patches:

  liblwres90 1:9.9.5.dfsg-3ubuntu0.6
  mysql-common 5.5.46-0ubuntu0.14.04.2
  libmysqlclient-dev 5.5.46-0ubuntu0.14.04.2
  libmysqlclient18 5.5.46-0ubuntu0.14.04.2
  rsync 3.1.0-2ubuntu0.1
  bind9-host 1:9.9.5.dfsg-3ubuntu0.6
  libisccc90 1:9.9.5.dfsg-3ubuntu0.6
  libisc95 1:9.9.5.dfsg-3ubuntu0.6
  dnsutils 1:9.9.5.dfsg-3ubuntu0.6
  linux-libc-dev 3.13.0-74.118
  libbind9-90 1:9.9.5.dfsg-3ubuntu0.6
  libxml2 2.9.1+dfsg1-3ubuntu4.6
  libdns100 1:9.9.5.dfsg-3ubuntu0.6
  libxml2-dev 2.9.1+dfsg1-3ubuntu4.6
  libisccfg90 1:9.9.5.dfsg-3ubuntu0.6

Cool idea -- I'll go get the golf clubs!

We'd love to be at the point where Patchwork notifications are ahead of public releases, and get you patched before the vulnerability is widely exploited. In fact, one of the crazy ideas we've been kicking around is how to detect 0days without installing an agent on production machines.

Sure thing! The service pivots around machines as it's core pilar. On a more fundamental level, we consider a machine to be the set of unique packages tracked together. So for your case, you'd spin up a pilot, run the script, then post the data to us. Since it's a new machine, we'll issue it a UUID, and track billing against that UUID. If you change the packages on a machine? That's a-okay! We'll use the same UUID, and bill accordingly :). When it's time to sunset a machine, use our soon to be released API to remove it, and billing stops!

To be totally honest, we're still working out all the wrinkles of how billing would work, what's fair to users, and how to track your usage, so feedback is greatly appreciated!

Great idea! We're looking to build out and extend a callback API so you can have it post data to whichever end point you want. Some integrations I've been toying with are: alerts in a slack channel, SMS notifications, push issues to git, get continuous integration to block unless it's 'ok', have it call my mom and have her yell at me till I patch my servers!

Halite, feel free to ping me about the volume pricing! shamiq@patchworksecurity.com

Hi all! I’m Shamiq, ex-Matasano and co-founder of Patchwork Security. David and I built Patchwork as a devops tool to help manage Open Source Vulnerabilities. We want to drive the time between an available fix and patched infrastructure to zero. We’d love for you to try it out, and let us know what you think!

We’ll be here all day answering comments or you can reach us at shamiq@patchworksecurity.com or david@patchworksecurity.com.

Matt Krisiloff mentioned it'll be sent by EOD today:

https://twitter.com/MattKrisiloff/status/633690502039121920

submit a pull request? find the dev who wrote it and ask if you can help get it patched? file an bug? same thing as finding any other type of bug, really. Just avoid sounding like an ass and you might make traction.

As a corollary: consider creating a better PoC for the bug.

6500 videos -- 4.5 DAYS worth of video if every application stuck to exactly 1 minute each.

that's so fucked. this sucks :<.

I'm afraid of the security implications of another automated, hard to control, hard to see attack surface. I'm all for better infrastructure, but infrastructure is what historical comes under attack first when "shit hits the fan", and this seems like a great target and pipeline.

If you can help me make it secure, I'd love to help you design it.

doesn't this work for you? http://perf.fail/rss.xml