4 ms·

At my employer, we have a company-wide database of which package is installed in which version on each machine (several ten thousands of them). This allows the

At my employer, we have a company-wide database of which package is installed in which version on each machine (several ten thousands of them). This allows the compliance department to follow known security issues, and they can then open tickets to the affected operating teams stating on which machines the software needs to be upgraded (or mitigations implemented), and they set deadlines based on vulnerability ratings. If the deadlines aren't meant, there's a hierarchical escalation. In the case of the Equifax breach, such a mechanism might have helped. If the developers knew they had to update, but didn't, maybe the ticket from compliance would have given them the right nudge to actually do it.

deleted 6y ago
[deleted]
silly-silly 6y ago
At my employer we do the same thing for pretty much all software shipped to customers. (X thousand packages, across 5 arches, across 5 releases) There is an ongoing effort and it becomes more complex with vendored packages, embedded jars and 'containers'. I'm assuming that the indexing is done at compile time, how far back into your dep tree do you go ?
- perlgeek 6y ago
  It's currently only at the top-level package level, and so the data is simply taken from the package manager. I want it to go one level deeper (we use dh-virtualenv to put several Python packages into one Debian package, but that's only done in a very small part of the company). Of course then there could be C libraries packaged with the Python libraries packaged in a Debian repository, so we'd need another level eventually...