dchanm

We're working something similar at Patchwork (https://patchworksecurity.com/) . You tell us what packages are installed and we notify you when a new security update is released. Right now we're focusing on distro package managers, but plan to add support for monitoring upstreams like nginx.

The big issue we see with RSS / mailing lists is a problem of discoverability and noise. Not all software has an easy to digest format for security changes. We want to do the scraping / parsing once and make it consumable by others. General lists such as OSS and distro specific security announce lists tend to have more noise. Most people only care about packages installed on their machines, which is why we filter our results based on your set of packages.

Hi,

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?

Pakiti looks like an interesting tool. Development seems to have slowed down in 2013, but the feature set might have been stable by then. We'll definitely look into this. Thanks deadfece!

Hi yaworsk,

We're working on improving our API documentation. You can develop against our API and not use the supplied client.

https://patchworksecurity.com/docs/

I believe this issue is fixed now.

https://github.com/PatchworkSecurity/cleansweep/issues/8

Could you try running the script again?

"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."

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.

Hi k33n,

Thanks for sharing what you learned. We will look into integrating with existing security tools.

In the meantime, we believe that providing a security notifications API to users is valuable.

Hi mmaunder, e-mail notifications are our current callback mechanism but that will expand. The goal of our API is to allow you to consume the vulnerability data in a way that is more beneficial to you e.g Slack, CI. You could have a workflow where a new build is spun up on callback, packages updated, tests run and deployed

Apt is our starting point but we will expand into things like libraries and Ruby gems.

Hi DoubleMalt,

Thanks for the link. I've filed an issue and should have this fixed tonight

https://github.com/PatchworkSecurity/cleansweep/issues/7

Hi halite!

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?

Hi, our roadmap includes hooking into CI where your CI can ask our API Is the current project state vulnerable? yes) Here are a list of dependencies you need to update, run your test again no) Good, proceed with deploy

This is a little further down the roadmap, but is definitely something we want to do.

Hi, can you tell me the version of curl you're running with

curl -V

Also send me an email at [email protected] and I'll get it working for you.

If you want to be extra cautious you can verify that the script hasn't changed with our release key

https://patchworksecurity.com/releases.txt

The latest release (2.0.0) has been signed by my key 0x85C64E20

Hi, the shell script is an implementation of our API. You can implement your own client against our API endpoints. This gives you complete control of what package data you send to us. If you only care about OpenSSL, you can create a machine with only OpenSSL and we will notify you when that is out of date.

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/...

Hi, we decided to make it easy to setup the tool and run it. The source code is available on GitHub

https://github.com/PatchworkSecurity/cleansweep/blob/master/...

The comments explain what is happening at each step.

Hey, I’m David, the other co-founder of Patchwork Security. I was working on AppSec at Mozilla when Shellshock came out, then the next variant and the next. The OpSec team diligently followed new developments, but there had to be a better way than following a bunch of mailing-lists or watching HN for the next named vulnerability. Shamiq and I designed Patchwork to notify users of relevant packages in their infrastructure rather than the firehose approach reporting every new vulnerable package.

Let us know if you run into any problems.