4 ms·

It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsof

It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

hellokittycity 4y ago
This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.
- lenkite 4y ago
  Well, software developers will need 2/3 years of legal training also then.
- consp 4y ago
  I would love a world where that would happen; and also get years of testing, proof of concept time and funding to make all that actually happen. Not counting on it thoug since cost would skyrocket.
- ByteJockey 4y ago
  For this to work, you'd need most of the code to be written by people who are paid (i.e. professionals). In my experience somewhere between 50-80% of code at most places is stuff pulled off maven/npm/github/etc written by people who are completely uncompensated, and possibly as hobby projects. You could censure devs pulling in unverified code, but so far as I can tell, the vast majority of devs are really bad at reading code. I'm doubtful it would change anything. This seems like something that should maybe covered in a computer science curriculum, but most colleges seem to have an aversion to becoming "job training" centers. If they don't start teaching it, I'm not sure how you can expect people to have training in it. Do we need a training course outside the traditional university system?
- zarkov99 4y ago
  The problem with this idea has been the same for 40 years: unlike in other fields of engineering in Software there is no bedrock of empirical science from which we can derive objective, reasonable standards. It is all opinion in CS and no doubt the most obnoxious, useless methodologists would be the ones with the strongest opinions about how others should build things.
flohofwoe 4y ago
That's 70% of CVEs, not 70% of all bugs, which is a massive difference. Most programmers don't deal with CVE worthy bugs on a daily basis, no matter what programming language they use.
- eventhorizonpl 4y ago
  It's fact that it's easiest to cause a CVE bug in a language that you manually manage memory. So it's true that most likely JavaScript programmers may not cause them too often ;)
  - flohofwoe 4y ago
    Anectodal, but: I had been working on a mixed C/C++ code base which grew over around 20 years to about 1mloc, with a team of programmers varying between 5 and 20, and we had to deal with memory corruption issues around once or twice a year, and those could be solved relatively quickly (even more quickly with modern memory debugging tools like the memory debugger/profiler in Visual Studio). At the same time, the bug database for the project had a "throughput" of about 5..10 bugs per day (for the programming team, many more for the entire team). The amount of memory related bugs relative to "regular" bugs is infinitesimal even in a C/C++ code base. Of course I realize that the code base had "sleeper bugs" that hadn't showed up yet, and a memory safe language would have helped to prevent those. But I just wanted to point out that memory corruption issues are just not a daily topic in most C/C++ projects. In the end, safety comes down to the sandbox your code runs in (for instance operating system processes, or Javascript VMs). Should those sandboxes be written in Rust? Most likely yes. Should everything else be written in Rust? Nah...
  - nerdponx 4y ago
    Case in point, no? How many companies need to use a programming language with manual memory management?
eventhorizonpl 4y ago
@hellokittycity There are ideas like that https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos-wanted-every-worker-to-have-a-permanent-publicly-available-job-performance-file https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos...
- hellokittycity 4y ago
  This exactly.. we need to be able to have accountability. Agreed
AshamedCaptain 4y ago
70% of all security issues is not 70% of all bugs. For the large majority of software products, security issues are an infinitesimal minority of bugs, and arguably, for a significant chunk of software products, security issues are not even critical.
- eventhorizonpl 4y ago
  - AshamedCaptain 4y ago
    I should have said: for a significant chunk of software products, there cannot even be security issues at all. If you disagree, just look around, preferably outside a "network service" mindset.
quietbritishjim 4y ago
Ha! Fair point. Two counter points: * As other comments have mentioned, security bugs matter more in some products than others. (E.g. think of a desktop application connecting to an organisation's own database.) * That includes a whole lot of code (maybe the majority) which is either C or C++ from before C++11, given that the bugs were tracked in the period 2006 - 2018. Never mind a hypothetical Rust-without-lifetimes.
tetromino_ 4y ago
Both you and parent are correct. Memory safety issues in c++ code are common, but very often they don't manifest as segfaults. Malloc assertion failures or occasional data corruption in edge cases or "impossible" behavior are more typical symptoms.
- cudgy 4y ago
  Memory issues are rare in every C++ project I’ve ever worked on when compared to much more common bugs in expected functionality (the biggest category), bugs introduced by new or updated libraries, or operating system deprecations, etc. Overall, the aversion to C++ and other non-GC languages is overly stated in the industry by vendors looking desperate for a problem to solve to validate using their new language or as a solution for companies that want to hire large armies of sub-par developers to bang on keyboards.

It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

hellokittycity 4y ago

This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.

lenkite 4y ago
Well, software developers will need 2/3 years of legal training also then.
consp 4y ago
I would love a world where that would happen; and also get years of testing, proof of concept time and funding to make all that actually happen. Not counting on it thoug since cost would skyrocket.
ByteJockey 4y ago
For this to work, you'd need most of the code to be written by people who are paid (i.e. professionals). In my experience somewhere between 50-80% of code at most places is stuff pulled off maven/npm/github/etc written by people who are completely uncompensated, and possibly as hobby projects. You could censure devs pulling in unverified code, but so far as I can tell, the vast majority of devs are really bad at reading code. I'm doubtful it would change anything. This seems like something that should maybe covered in a computer science curriculum, but most colleges seem to have an aversion to becoming "job training" centers. If they don't start teaching it, I'm not sure how you can expect people to have training in it. Do we need a training course outside the traditional university system?
zarkov99 4y ago
The problem with this idea has been the same for 40 years: unlike in other fields of engineering in Software there is no bedrock of empirical science from which we can derive objective, reasonable standards. It is all opinion in CS and no doubt the most obnoxious, useless methodologists would be the ones with the strongest opinions about how others should build things.

flohofwoe 4y ago

That's 70% of CVEs, not 70% of all bugs, which is a massive difference. Most programmers don't deal with CVE worthy bugs on a daily basis, no matter what programming language they use.

eventhorizonpl 4y ago
It's fact that it's easiest to cause a CVE bug in a language that you manually manage memory. So it's true that most likely JavaScript programmers may not cause them too often ;)
- flohofwoe 4y ago
  Anectodal, but: I had been working on a mixed C/C++ code base which grew over around 20 years to about 1mloc, with a team of programmers varying between 5 and 20, and we had to deal with memory corruption issues around once or twice a year, and those could be solved relatively quickly (even more quickly with modern memory debugging tools like the memory debugger/profiler in Visual Studio). At the same time, the bug database for the project had a "throughput" of about 5..10 bugs per day (for the programming team, many more for the entire team). The amount of memory related bugs relative to "regular" bugs is infinitesimal even in a C/C++ code base. Of course I realize that the code base had "sleeper bugs" that hadn't showed up yet, and a memory safe language would have helped to prevent those. But I just wanted to point out that memory corruption issues are just not a daily topic in most C/C++ projects. In the end, safety comes down to the sandbox your code runs in (for instance operating system processes, or Javascript VMs). Should those sandboxes be written in Rust? Most likely yes. Should everything else be written in Rust? Nah...
- nerdponx 4y ago
  Case in point, no? How many companies need to use a programming language with manual memory management?

eventhorizonpl 4y ago

@hellokittycity There are ideas like that https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos-wanted-every-worker-to-have-a-permanent-publicly-available-job-performance-file https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos...

hellokittycity 4y ago
This exactly.. we need to be able to have accountability. Agreed

AshamedCaptain 4y ago

70% of all security issues is not 70% of all bugs. For the large majority of software products, security issues are an infinitesimal minority of bugs, and arguably, for a significant chunk of software products, security issues are not even critical.

eventhorizonpl 4y ago
- AshamedCaptain 4y ago
  I should have said: for a significant chunk of software products, there cannot even be security issues at all. If you disagree, just look around, preferably outside a "network service" mindset.

quietbritishjim 4y ago

Ha! Fair point. Two counter points: * As other comments have mentioned, security bugs matter more in some products than others. (E.g. think of a desktop application connecting to an organisation's own database.) * That includes a whole lot of code (maybe the majority) which is either C or C++ from before C++11, given that the bugs were tracked in the period 2006 - 2018. Never mind a hypothetical Rust-without-lifetimes.

tetromino_ 4y ago

Both you and parent are correct. Memory safety issues in c++ code are common, but very often they don't manifest as segfaults. Malloc assertion failures or occasional data corruption in edge cases or "impossible" behavior are more typical symptoms.

cudgy 4y ago
Memory issues are rare in every C++ project I’ve ever worked on when compared to much more common bugs in expected functionality (the biggest category), bugs introduced by new or updated libraries, or operating system deprecations, etc. Overall, the aversion to C++ and other non-GC languages is overly stated in the industry by vendors looking desperate for a problem to solve to validate using their new language or as a solution for companies that want to hire large armies of sub-par developers to bang on keyboards.