Show HN: Patchwork – Real-time notifications for OSS vulnerabilities(patchworksecurity.com) |
Show HN: Patchwork – Real-time notifications for OSS vulnerabilities(patchworksecurity.com) |
How do you manage vulnerabilities database?
Do you've a list of OSS that this tool covers? Does it integrate with existing scanning tools like Nexpose (http://www.rapid7.com/products/nexpose/).
Can it scan code repositories?
What information does it capture from the machine? Where is the data center located?
What do you anticipate the bandwidth consumption would be like for this tool?
Any volume discounts?
edit: formatting.
1. We've got agents listening to incoming feeds, and did the work to ingest all the historical vulnerability data we could find.
2. We're focusing on apt installed packages for our initial release.
3 & 4. We haven't built out plugin support for scanning repos and ingesting from other tools. We're looking to get as much info as we can about what data you have to feed into us :), so we can figure out what'll work best!
5. The only machine metadata we're currently using is: hostname (this can be changed by setting the FRIENDLY_NAME environment variable), Operating System, Operating System Version, the tracking UUID for a package. The package data is: package and package version. We're aiming to keep the minimal subset of information we need to provide notifications :).
5. We're using Digital Ocean for our hosting (those guys rock!). Hosts are currently only in SF.
6. Our larger machine package sets are around 200-300kb.
7. How much volume?
I think what I'm more interested in understanding is how is license enforced? Our team is responsible for facilitation of pilots and this I can see useful for those machine but these come and go every few months.
It should be simple enough to intersect the list of a project's dependencies with a list of libraries with known vulnerabilities.
If you provided this as a free service, you'd get a bunch of free advertising from the github badges, like travis-CI. :)
This is a little further down the roadmap, but is definitely something we want to do.
We’ll be here all day answering comments or you can reach us at shamiq@patchworksecurity.com or david@patchworksecurity.com.
Let us know if you run into any problems.
Companies which pay for the service will be notified of the vulnerability before hackers.
Basically you foster a community of hackers while at the same time charging companies protection money from your own hackers.
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.
curl -L https://git.io/cleansweep | sh
sh: 94: curl: Argument list too longhttps://github.com/PatchworkSecurity/cleansweep/issues/8
Could you try running the script again?
curl -V
Also send me an email at david@patchworksecurity.com and I'll get it working for you.
curl -L https://git.io/cleansweep | sh
[edit] I still think it's a great idea, though [/edit]
[1] https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...
He addresses code signing and mitm and connection interruptions.
Edit: The gist of it is no, it's not more insecure than other software distribution methods.
https://github.com/PatchworkSecurity/cleansweep/blob/master/...
The comments explain what is happening at each step.
Piping random shit off the web straight into a shell. Sounds like worst advise. I'm sure the maintainers of this site really know their stuff when it comes to security.
A malicious attacker will love breaking this site and find out who uses which versions.
Install via curl is also, by now, a classic flamewar topic with people who know what they're doing on both sides of the argument and well-trodden arguments all around. Please don't bring topics like that up with indignant denunciation as if you're the first person to encounter an outrage.
We understand your concerns with the current install mechanisms. We're working toward providing multiple options similar similar to sandstorm.io
https://docs.sandstorm.io/en/latest/install/
There is the risk that we become a high value target. Would a solution that allows a user to query the state of a package/version instead of us storing package sets be acceptable? Or do you believe that SchizoDuckie's database approach to be the only way?
Also, don't tell your users to blindly pipe curl to sh, ever.
It would be a much better design if it worked the other way around: Aggregate recent security patches into a database and send those to the servers, and have them do a local compare of vulnerabilities. You could charge for the database access and still keep your business model.
https://patchworksecurity.com/docs/
The current infrastructure segregates the user and machine data. A compromise of both machines would allow an attacker to recreate the mappings between users and their machines. We're hoping that this service will reduce the time your infrastructure is vulnerable because you know immediately when something goes out of date.
Lastly, we wanted to make it really simple for a user to get setup on our service which resulted in the curl | sh idiom. The source code for the script is on GitHub
https://github.com/PatchworkSecurity/cleansweep/blob/master/...
There is definitely value in having an aggregate database with recent security information. We agree that there are certain customers who would prefer / require an on-premise solution. Selling database access is something that we have considered, but haven't looked into deeply.
There is no restriction that the data must come from your local machine. You can integrate with our API to create a machine that has ``all'' packages for Ubuntu version X. We will then notify you when packages are outdated and you can act on that locally. Granted this still leaks the version of Ubuntu you are running, but we will have no insight into what each of your machines are actually running.
Thanks for raising these concerns.
Apt is our starting point but we will expand into things like libraries and Ruby gems.
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!
It looks like Patchwork's script doesn't quite do that, but it does put _most_ of its functionality into functions, and AFAICT there is no particular place in the script where a connection loss could lead to anything bad happening. Admittedly this appears to be a lucky accident rather than following best practice.
Thanks for the link. I've filed an issue and should have this fixed tonight
I don't particularly like curl | sh either, but without sudo, I'm not sure how much it /really/ differs, security wise, from other options.
Edit: real package managers have improved features compared to curl, as outlined in another branch of the comments.
https://patchworksecurity.com/releases.txt
The latest release (2.0.0) has been signed by my key 0x85C64E20