5 ms·

> I really really enjoy how I can ship a thing with exactly a certain set of versions Just curious, how do you handle security monitoring and updates when doin

> I really really enjoy how I can ship a thing with exactly a certain set of versions Just curious, how do you handle security monitoring and updates when doing this? I've been exposed to two major approaches: At $FAANG we're on a treadmill where company CI force builds your stuff every time anything in your requirements.txt releases a new version (semver respected, at least) because in the absence of targeted CVE monitoring (which itself won't cover you 100%), that's the only practical way they see to keep up with security updates. If a dependency change breaks your project and you leave it broken for too long, peeps above you start getting autocut tickets. This leads to a lot of ongoing maintenance work for the life of the project because eventually you get forced into newer minor and eventually major versions whether you like it or not. Outside of $FAANG I've gotten a whole lot of mileage building customer software on top of Debian- or Ubuntu-packaged dependencies. This allows me to rely on the distro for security updates without the churn, and I'm only forced to take newer dependencies when the distro version goes EOL. Obviously this constrains my library selection a lot, but if you can do it there's very little maintenance work compared to the other approach. I'd like to hear how others handle this because both approaches obviously have considerable downsides.

rtpg 2y ago
To be honest I'm fortunate enough to where maintenance work by sticking to "the latest and greatest" for application-level stuff is not hard. For system-level stuff in general it's been about relying on Debian or Ubuntu stuff, but then application-level management for the top layer ("the application", so to speak). I've only rarely been in situations where Debian packaging outright meant we couldn't move forward on something (one funny and annoying one was gettext being too old, but gettext is so coupled with libc for some reason that we couldn't just compile a fresh version...) The joys of not having to deal wit the extremes of any problem...
jjnoakes 2y ago
I strive for the latter approach as much as possible. I'm happy doing more work as a developer (like using a slightly older version of libraries or languages) to ensure that I build on a stable base that gets security updates without tons of major version api churn.
zozbot234 2y ago
Keeping up with the 'treadmill' you described is perhaps the main job of a Linux distribution. See, e.g. https://release.debian.org/transitions/ https://release.debian.org/transitions/ for one example of how this can work practically.
jeroenhd 2y ago
Don't forget the third option: don't. Updates are necessary when the customer asks for them. Most customers won't, and if they do, they don't know they need an update if you compile everything statically. Personally, the update story is why I find developing on Windows much easier than developing on Linux. Instead of hundreds of small, independent packages, you can just target the _massive_ Windows API. You can take the "living off the land" approach on Linux too, but it's harder, often relying on magical IOCTLs and magical file paths rather than library function calls. Not that I think the Win32/WinRT API is particularly well-designed, but at least the API is there, guaranteed to be available, and only breaks in extremely rare circumstances.
- lars_francke 2y ago
  I don't know where you reside and what kind of software you build. With the European Cyber Resilience Act coming into full effect late 2027/early 2028 (depends on when it's finally signed) this will not always be an option anymore for a lot of people. a) You'll have to provide SBOMs so you can't (legally) "hide" stuff in your binary b) Security updates are mandatory for known exploitable vulnerabilities and other things, so you can't wait until a customer asks. This will take a few years before it bites (see GDPR) but the fines can be just as bad.
  - repelsteeltje 2y ago
    > [...] "hide" stuff in your binary While legislatively requiring SBOMs is obviously a good idea, it might also unintentionally incentive companies to hide dependencies by rolling their own. Afterall, it's not a "dependency" if it's in the main code base you developed yourself. Not sure how likely this is, but especially in case of network stacks or cryptographic functions that could potentially be disastrous.
    - lars_francke 2y ago
      I agree that there is a chance this could happen. But as a business owner myself it's pretty simple: It's far cheaper for me to take an existing dependency, create SBOMs and patch regularly compared to having to develop and maintain these things myself. But I do get your point that others might make different decisions. But the CRA also has provisions here as you have to do a risk assessment for your product as well and publish the result of that on your documentation and hand rolling crypto should definitely go on there as well. Again... People can just ignore this and probably won't get caught anytime soon....
solidninja 2y ago
What are the significant downsides of the first approach in your experience?
- Scramblejams 2y ago
  > This leads to a lot of ongoing maintenance work for the life of the project because eventually you get forced into newer minor and eventually major versions whether you like it or not. Remember, the desire here is simply to keep up with security updates from dependencies. There is no customer requirement to be using the latest dependencies, but this approach requires you to eventually adopt them and that creates a bunch of work throughout the entire lifecycle of the project.

rtpg 2y ago

To be honest I'm fortunate enough to where maintenance work by sticking to "the latest and greatest" for application-level stuff is not hard. For system-level stuff in general it's been about relying on Debian or Ubuntu stuff, but then application-level management for the top layer ("the application", so to speak). I've only rarely been in situations where Debian packaging outright meant we couldn't move forward on something (one funny and annoying one was gettext being too old, but gettext is so coupled with libc for some reason that we couldn't just compile a fresh version...) The joys of not having to deal wit the extremes of any problem...

jjnoakes 2y ago

I strive for the latter approach as much as possible. I'm happy doing more work as a developer (like using a slightly older version of libraries or languages) to ensure that I build on a stable base that gets security updates without tons of major version api churn.

zozbot234 2y ago

Keeping up with the 'treadmill' you described is perhaps the main job of a Linux distribution. See, e.g. https://release.debian.org/transitions/ https://release.debian.org/transitions/ for one example of how this can work practically.

jeroenhd 2y ago

Don't forget the third option: don't. Updates are necessary when the customer asks for them. Most customers won't, and if they do, they don't know they need an update if you compile everything statically. Personally, the update story is why I find developing on Windows much easier than developing on Linux. Instead of hundreds of small, independent packages, you can just target the _massive_ Windows API. You can take the "living off the land" approach on Linux too, but it's harder, often relying on magical IOCTLs and magical file paths rather than library function calls. Not that I think the Win32/WinRT API is particularly well-designed, but at least the API is there, guaranteed to be available, and only breaks in extremely rare circumstances.

lars_francke 2y ago
I don't know where you reside and what kind of software you build. With the European Cyber Resilience Act coming into full effect late 2027/early 2028 (depends on when it's finally signed) this will not always be an option anymore for a lot of people. a) You'll have to provide SBOMs so you can't (legally) "hide" stuff in your binary b) Security updates are mandatory for known exploitable vulnerabilities and other things, so you can't wait until a customer asks. This will take a few years before it bites (see GDPR) but the fines can be just as bad.
- repelsteeltje 2y ago
  > [...] "hide" stuff in your binary While legislatively requiring SBOMs is obviously a good idea, it might also unintentionally incentive companies to hide dependencies by rolling their own. Afterall, it's not a "dependency" if it's in the main code base you developed yourself. Not sure how likely this is, but especially in case of network stacks or cryptographic functions that could potentially be disastrous.
  - lars_francke 2y ago
    I agree that there is a chance this could happen. But as a business owner myself it's pretty simple: It's far cheaper for me to take an existing dependency, create SBOMs and patch regularly compared to having to develop and maintain these things myself. But I do get your point that others might make different decisions. But the CRA also has provisions here as you have to do a risk assessment for your product as well and publish the result of that on your documentation and hand rolling crypto should definitely go on there as well. Again... People can just ignore this and probably won't get caught anytime soon....

solidninja 2y ago

What are the significant downsides of the first approach in your experience?

Scramblejams 2y ago
> This leads to a lot of ongoing maintenance work for the life of the project because eventually you get forced into newer minor and eventually major versions whether you like it or not. Remember, the desire here is simply to keep up with security updates from dependencies. There is no customer requirement to be using the latest dependencies, but this approach requires you to eventually adopt them and that creates a bunch of work throughout the entire lifecycle of the project.