3 ms·

I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above. Never mind that s

I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above. Never mind that some of them involved vulnerabilities in some part of the bluetooth stack (servers in our datacenter don't even have bluetooth). But they just didn't care

ptx 2mo ago
This does make some sense if it's considered a valid fix to document that you have verified that Bluetooth is disabled on the servers and therefore not vulnerable. But that assumes that the scanning tool can be told about this kind of fix, so that it stops warning about it, which I guess it might not.
SoftTalker 2mo ago
So run apt full-upgrade and get the new bluetooth driver. Why bother with a fight over something that isn't even used? Just do the quickest thing to get it off your plate.
- icedchai 2mo ago
  This might cause other problems, problems of the "if it's not broken, don't fix it" variety. Upgrading everything only to break something else, in a previously stable configuration, isn't worth it.
  - pixl97 2mo ago
    Really the days of "Lets run this stable configuration forever" are gone. Getting rid of as much stuff in your OS and software stack as possible should be the security teams ultimate goal, so you have less to upgrade in the end. But actual security updates just come out at a tremendous rate, and you need a QA system that checks as much as it can before prod is upgraded.
    - icedchai 2mo ago
      I do agree with more frequent upgrades, but it has to be part of the culture. The longer you wait, the harder it gets. Unfortunately, I have worked in some heavily tech-debt-laden environments where upgrading anything required an act of god. I've logged on to production servers with 1500+ days of uptime at multiple companies. Nothing had been updated since well before that time. At one place, I recall encountering a 10+ year old dependency. On top of that, they were still using Python 2.7. This wasn't that long ago.
      - vrighter 2mo ago
        in our case, updates were done on a staggered schedule, automatically, and rebooted at a particular agreed upon downtime window. dev, then test, then live machines. I had to explain multiple times to them, for example, that I have updated the system, but the reboot is scheduled for 3 days from now.
- vrighter 2mo ago
  yeah that didn't work. Some apps required particular runtimes to use. We installed those versions in /opt and used them only for the apps that absolutely needed them. Scanner still said "there's an old shared library in that directory"

ptx 2mo ago

This does make some sense if it's considered a valid fix to document that you have verified that Bluetooth is disabled on the servers and therefore not vulnerable. But that assumes that the scanning tool can be told about this kind of fix, so that it stops warning about it, which I guess it might not.

SoftTalker 2mo ago

So run apt full-upgrade and get the new bluetooth driver. Why bother with a fight over something that isn't even used? Just do the quickest thing to get it off your plate.

icedchai 2mo ago
This might cause other problems, problems of the "if it's not broken, don't fix it" variety. Upgrading everything only to break something else, in a previously stable configuration, isn't worth it.
- pixl97 2mo ago
  Really the days of "Lets run this stable configuration forever" are gone. Getting rid of as much stuff in your OS and software stack as possible should be the security teams ultimate goal, so you have less to upgrade in the end. But actual security updates just come out at a tremendous rate, and you need a QA system that checks as much as it can before prod is upgraded.
  - icedchai 2mo ago
    I do agree with more frequent upgrades, but it has to be part of the culture. The longer you wait, the harder it gets. Unfortunately, I have worked in some heavily tech-debt-laden environments where upgrading anything required an act of god. I've logged on to production servers with 1500+ days of uptime at multiple companies. Nothing had been updated since well before that time. At one place, I recall encountering a 10+ year old dependency. On top of that, they were still using Python 2.7. This wasn't that long ago.
    - vrighter 2mo ago
      in our case, updates were done on a staggered schedule, automatically, and rebooted at a particular agreed upon downtime window. dev, then test, then live machines. I had to explain multiple times to them, for example, that I have updated the system, but the reboot is scheduled for 3 days from now.
vrighter 2mo ago
yeah that didn't work. Some apps required particular runtimes to use. We installed those versions in /opt and used them only for the apps that absolutely needed them. Scanner still said "there's an old shared library in that directory"