3 ms·

> The current software engineering paradigm has no meaningful answer to this, no matter what "security experts" tell you. In a sane industry this realization wo

by Kalium 4y ago

> The current software engineering paradigm has no meaningful answer to this, no matter what "security experts" tell you. In a sane industry this realization would lead to a change of the paradigm, but people in our industry seem to be only doubling down. On the contrary, I believe we do. The answer is ongoing maintenance. The basic problem is that people persist in looking at software as a fundamentally mechanistic artifact you finish and ship in a static environment. Then you move on to the next thing. This is fundamentally incorrect. Software engineering is a process that takes place in an adversarial, human-driven environment. There is fundamentally no automating this away because human decision-making work is required. Any security expert worth their salt will tell you this. As long as you persist in trying to view software as a fixed artifact in a static environment, you will find there is no meaningful answer. Those who come to terms with the dynamic, human-driven reality will find that there's a well-understood - if inconvenient and expensive - answer.

secabeen 4y ago
So then what do you do with software that doesn't meet this standard? Software that works, that meets a need you have, but that is a fixed artifact, or at least will be in the foreseeable future. Do you refuse to use said software, and instead choose a less useful alternative that is actively developed?
- efsavage 4y ago
  I believe the point is that no software is a fixed artifact. Regardless of the state of its development, it's all reactive to factors outside of its control, whether that's other software, users, hardware, etc.
- Veserv 4y ago
  That is solved with standard engineering practices. If you need to make guarantees about your product that are dependent on another piece of software, then you just have your vendor produce a spec and guarantee conformance to the spec, then you audit that the spec fulfills your fixed needs and audit that the implementation conforms to the spec. Then, if you made a mistake, your liability is limited to your mistakes instead of your mistakes and the mistakes of your dependencies. If, on the other hand, you do not get any guarantees from your dependencies, and you fail to achieve your guarantees then that is entirely on you as you are the one transforming the absence of guarantees into guarantees.
- m_mueller 4y ago
  In fact yes. I‘d choose a maintained lesser library or an in-house implementation over an unmaintained one. This is also the main benefit of python, with its huge standard lib that effectively gives some maintenance guarantees. To give you an example: XLSX parsing. For quite a while, the most performant library ‚xlrd‘ had a big scary unmaintained notice on GitHub, yet people kept recommending and using it, often unnoticed through pandas, because they don’t read docs. I‘d refuse to touch that and instead use openpyxl, and now newer xlrd releases have even completely removed xlsx support.
- Kalium 4y ago
  That's a risk management problem. For how long will the world around this fixed artifact remain constant? How far away is your "foreseeable future" horizon? What happens when you're wrong? I have, in fact, chosen to use actively developed and maintained systems with fewer features than unmaintained EOL'd ones. When you choose software to solve a problem, you're not just choosing software. You're encoding expectations around the problem, the environment, and your needs. If all three of those can be assured to never change then choosing a fixed artifact might be the way forward. Should any of those ever change, then your software will either adapt or become a less suitable solution. How often can an organization really be that certain?
  - staticassertion 4y ago
    That's exactly right - it's about risk. No one has "perfect" operations/ security. They have a threat model and a risk tolerance.
- SamuelAdams 4y ago
  We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device. That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or constantly invest in something that works and does one thing well.
  - bradgessler 4y ago
    I was visiting my parents this summer and they have a Gameboy from 1991 with a Tetris cartridge, which was authored in 1989. They use it regularly and it still works! For over 30 years this device has played Tetris without requiring any software updates.
  - krmboya 4y ago
    Not familiar with such kind of software, but if it were written for, say, Linux, would it need such an expensive rewrite to work with current versions?
    - ithkuil 4y ago
      I still run software I wrote for Linux in 1998. It runs in a LXC container with all the old libraries and it must run in an Xvnc session with a window manager of the era because there is a Qt1 widget that opens a kind of drop down menu that just doesn't work with any modern window managers. I probably wouldn't bother to try to port it to modern versions of Qt or whatnot even if I hadn't lost the source code 15y ago. So yes, it happens, it's possible, it sucks
    - pnutjam 4y ago
      that gameboy cartridge isn't working on a modern system either...
  - Kalium 4y ago
    Not to split hairs, but I think what you've described is constant investment in something that works and does one thing well. The firewalls and management and maintenance are all ongoing costs to manage the risk. Software is never just an artifact. It's a whole system, of which the source code and binaries are some components. If you do not manage those artfacts, the next best option is generally managing the environment.

by Kalium 4y ago

secabeen 4y ago

So then what do you do with software that doesn't meet this standard? Software that works, that meets a need you have, but that is a fixed artifact, or at least will be in the foreseeable future. Do you refuse to use said software, and instead choose a less useful alternative that is actively developed?

efsavage 4y ago
I believe the point is that no software is a fixed artifact. Regardless of the state of its development, it's all reactive to factors outside of its control, whether that's other software, users, hardware, etc.
Veserv 4y ago
That is solved with standard engineering practices. If you need to make guarantees about your product that are dependent on another piece of software, then you just have your vendor produce a spec and guarantee conformance to the spec, then you audit that the spec fulfills your fixed needs and audit that the implementation conforms to the spec. Then, if you made a mistake, your liability is limited to your mistakes instead of your mistakes and the mistakes of your dependencies. If, on the other hand, you do not get any guarantees from your dependencies, and you fail to achieve your guarantees then that is entirely on you as you are the one transforming the absence of guarantees into guarantees.
m_mueller 4y ago
In fact yes. I‘d choose a maintained lesser library or an in-house implementation over an unmaintained one. This is also the main benefit of python, with its huge standard lib that effectively gives some maintenance guarantees. To give you an example: XLSX parsing. For quite a while, the most performant library ‚xlrd‘ had a big scary unmaintained notice on GitHub, yet people kept recommending and using it, often unnoticed through pandas, because they don’t read docs. I‘d refuse to touch that and instead use openpyxl, and now newer xlrd releases have even completely removed xlsx support.
Kalium 4y ago
That's a risk management problem. For how long will the world around this fixed artifact remain constant? How far away is your "foreseeable future" horizon? What happens when you're wrong? I have, in fact, chosen to use actively developed and maintained systems with fewer features than unmaintained EOL'd ones. When you choose software to solve a problem, you're not just choosing software. You're encoding expectations around the problem, the environment, and your needs. If all three of those can be assured to never change then choosing a fixed artifact might be the way forward. Should any of those ever change, then your software will either adapt or become a less suitable solution. How often can an organization really be that certain?
- staticassertion 4y ago
  That's exactly right - it's about risk. No one has "perfect" operations/ security. They have a threat model and a risk tolerance.
SamuelAdams 4y ago
We see this all the time in healthcare. MRI imaging machine that cost 500k 20 years ago still works fine but only on Windows XP. Cost to rewrite the software for windows 10 is more than 500k so rather than paying for that instead they firewall the shit out of it so it can only talk to some printing / output device. That’s just one example. Medical machines are expensive as hell and companies don’t want to rebuy or constantly invest in something that works and does one thing well.
- bradgessler 4y ago
  I was visiting my parents this summer and they have a Gameboy from 1991 with a Tetris cartridge, which was authored in 1989. They use it regularly and it still works! For over 30 years this device has played Tetris without requiring any software updates.
- krmboya 4y ago
  Not familiar with such kind of software, but if it were written for, say, Linux, would it need such an expensive rewrite to work with current versions?
  - ithkuil 4y ago
    I still run software I wrote for Linux in 1998. It runs in a LXC container with all the old libraries and it must run in an Xvnc session with a window manager of the era because there is a Qt1 widget that opens a kind of drop down menu that just doesn't work with any modern window managers. I probably wouldn't bother to try to port it to modern versions of Qt or whatnot even if I hadn't lost the source code 15y ago. So yes, it happens, it's possible, it sucks
  - pnutjam 4y ago
    that gameboy cartridge isn't working on a modern system either...
- Kalium 4y ago
  Not to split hairs, but I think what you've described is constant investment in something that works and does one thing well. The firewalls and management and maintenance are all ongoing costs to manage the risk. Software is never just an artifact. It's a whole system, of which the source code and binaries are some components. If you do not manage those artfacts, the next best option is generally managing the environment.