5 ms·

Why software 'security debt' is becoming a serious problem for developers

20 points by Beggers1960 3y ago

jollofricepeas 3y ago
This is marketing for Veracode which is crap by the way. You can’t assess for risk without knowing anything about the environment, compensating controls and business logic. Veracode is a check-the-box enterprise compliance tool that reduces engineering productivity and corporate profitability. Yes, vulnerability management is an important problem but Veracode is not the solution not even close.
- redrove 3y ago
  My org almost bought Veracode for $1mil/yr. I'm happy they backed out last minute cause it looked like shit.
  - cassianoleal 3y ago
    I have used Veracode. Its SCA scan picks up fewer CVEs than whatever open-source tool the GitlabCI uses.
- Spivak 3y ago
  Are there any good enterprise check-the-box compliance tools? Because having good security doesn't obviate needing to box-check for our certifications.
  - candiddevmike 3y ago
    Even worse, sometimes the good tools don't check the box because they lack some pointless certification or the CISO "doesn't recognize the name".
  - PeterisP 3y ago
    I have seen SonarQube do somewhat okay in this role; you may need some configuring for its detections to set what matters for you, but that applies for everything, doesn't it?
- pryelluw 3y ago
  The OP is clearly a puppet account that just spams links from that website (which itself is mostly IT spam). Wish there was a way to hide submissions from certain posters …
- HideousKojima 3y ago
  About two years ago I was assigned to investigate several security tools, Veracode was one of them. For every tool I was able to get an actual demo/trial of, I tested them with a simple piece of code: 10 lines of C# that contained hardcoded credentials and a blatantly obvious SQL injection vulnerability. None of the tools I tried were able to detect both (though some would detect one or the other). IIRC (I tried a lot of different tools and wasn't able to get demos of all of them so it's hard to remember which did what) Veracode choked on any code using C# 8+ features like the simplified using blocks, which my 10 lines of vulnerable code used. My recommendation to my manager and others was that for the price being asked for most of these tools, we could instead hire two or more devs to do nothing but code review and manually search for vulnerabilities and do a better job. Instead they went with Veracode, and the first thing I got got after we implemented it was three emails for false positives that didn't properly identify the code file and line number where the supposed vulnerabilities occurred, meaning I had to waste several hours communicating with the team that ran the scan to figure out where this supposedly occured. I specifically remember two of the false positives were about my use of Serilog, saying my code was vulnerable to log injection. Even though Serilog isn't vulnerable to that if you use structured logging (which my code was). I even did several log injections and verified that they didn't actually work. Edit: Looking at the reports it generated, I see it also failed to detect usage of the actually highly vulnerable BinaryFormatter class which I have seen used several times by our offshore teams. That's something that could be detected with a simple string search and they didn't detect it.
  - MattPalmer1086 3y ago
    No idea how good Veracode is in practice. It's been considered in at least 3 places I've worked and never been selected. I would disagree that you can replace scanning tools with just human review though. You need both. Static analysis and software composition analysis are good at flagging possible problems, but there's a lot of noise. You ideally want an application security engineer to be reviewing the code and scan results. And also conducting threat modelling with the devs, so you prevent problems even earlier.
    - HideousKojima 3y ago
PeterisP 3y ago
Automated detection of risky code can be very useful, but it inherently lacks the capacity to differentiate whether a particular case of bad practice actually is a flaw or not. For a simplified example, usage of eval() in many dynamic languages is potentially risky and could result in a total takeover of the application, so these tools will generally flag it as 'critical' - even if in that particular case this 'eval' is run on data that can't possibly be affected by any user-controlled input (in that case it was used in a slightly weird design for code generation to save on copypasta) and does not have any security risk. Anecdotally, when I have done triage on such analysis, perhaps 5-10% of things the tools marked as 'critical' (i.e. potentially critical) were flaws which might have had some actual impact and need to be fixed. So when some vendor says in an article like this "The study found nearly two-thirds (63%) of the applications scanned had flaws in the first-party code", keep that in mind - they're generally treating all detections as real, but it's rarely the case. But on the other hand, it may well be the case that it's simpler to have a process to just clean up all suspicious places in the code; just as the simplest way to avoid use-after-free errors is to use a garbage-collected language instead of just trying to ensure that every single memory allocation in C is correctly implemented.
- chrisweekly 3y ago
  Yes, this. See also https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/
- miohtama 3y ago
  Veracode is a compliance solution, not a security solution. You buy it to have it as an insurance when your software gets hacked due to poor software engineering and you leak identities of millions of people. You can claim that “we had a process in place for secure software development” no matter if the tool does something useful or not. CISO and CEO do not get fired, users cannot sure, life goes on. To use such compliance solution may be also top-down requirement like in the case of SolarWinds after they caused the hacking of the half of the US government: https://investors.solarwinds.com/news/news-details/2023/SolarWinds-Announces-Its-Next-Generation-Build-System-Aligns-with-NIST-Secure-Software-Development-Framework/default.aspx https://investors.solarwinds.com/news/news-details/2023/Sola...
mrits 3y ago
When I stared in professional software there was almost an extreme paranoia of adding new libraries. Now we have 20 year olds adding whatever they want via NPM.
- bennyelv 3y ago
  Neither of those is the right answer! I'm dealing with the fallout of 10 years of "add whatever you want", and it's a unsolvable problem given the state of the system. The answer is devops: You build your system in a way that it's nearly effortless to test and deploy, then you can upgrade your dependency tree continually with minimal effort.
  - candiddevmike 3y ago
    The problem is adding/changing a dependency should be a big deal: there should be validation and risk assessments performed against it, and this process should happen every time the library is updated. This isn't fun to do, and is a serious time sink, so it becomes a deterrent every time you want to update a library.
    - bennyelv 3y ago
      Fair point - it should do. However if you've already accepted the risk that a 3rd party dependency might contain a vulnerability that has been undiscovered and you don't do any deep analysis of them, then you're still making your system more secure by at least getting the fixes for known vulnerabilities out of the door.
    - jjav 3y ago
      > adding/changing a dependency should be a big deal This! In hindsight, I miss the days when adding just a single third party library took months of engineering and legal reviews and executive approvals. It forced us to be careful and only request external libraries when absolutely needed (and then think twice again). Imagine going to your security team and saying that you'll walk out to the street, stop random people and the first one who claims they know how to program, you'll allow them to commit a bunch of code, with zero review, into your production codebase. Nobody would allow that! But we allow what is in reality the exact same thing by pulling in hundreds (if not thousands) of external dependencies without any clue what they do or if the code is any good. All if running in your production systems handling customer data.
ngneer 3y ago
Odds are against security. While it is natural to want to automate, programs have a hard time understanding and reasoning about other programs.
jtdev 3y ago
[dead]
throwawaaarrgh 3y ago
Lol, I haven't noticed software developers caring about security any more than they used to. 99% of them don't care, and 1% of them are responsible for 75% of secure code. Moreover, there is no consequence if they write insecure code, just like there's no consequence if they write unreliable code. They get the same paycheck regardless of the outcome.
farukmanon12 3y ago
[dead]
mahbran10 3y ago
[dead]

20 points by Beggers1960 3y ago

This is marketing for Veracode which is crap by the way. You can’t assess for risk without knowing anything about the environment, compensating controls and business logic. Veracode is a check-the-box enterprise compliance tool that reduces engineering productivity and corporate profitability. Yes, vulnerability management is an important problem but Veracode is not the solution not even close.

redrove 3y ago
My org almost bought Veracode for $1mil/yr. I'm happy they backed out last minute cause it looked like shit.
- cassianoleal 3y ago
  I have used Veracode. Its SCA scan picks up fewer CVEs than whatever open-source tool the GitlabCI uses.
Spivak 3y ago
Are there any good enterprise check-the-box compliance tools? Because having good security doesn't obviate needing to box-check for our certifications.
- candiddevmike 3y ago
  Even worse, sometimes the good tools don't check the box because they lack some pointless certification or the CISO "doesn't recognize the name".
- PeterisP 3y ago
  I have seen SonarQube do somewhat okay in this role; you may need some configuring for its detections to set what matters for you, but that applies for everything, doesn't it?
pryelluw 3y ago
The OP is clearly a puppet account that just spams links from that website (which itself is mostly IT spam). Wish there was a way to hide submissions from certain posters …
HideousKojima 3y ago
About two years ago I was assigned to investigate several security tools, Veracode was one of them. For every tool I was able to get an actual demo/trial of, I tested them with a simple piece of code: 10 lines of C# that contained hardcoded credentials and a blatantly obvious SQL injection vulnerability. None of the tools I tried were able to detect both (though some would detect one or the other). IIRC (I tried a lot of different tools and wasn't able to get demos of all of them so it's hard to remember which did what) Veracode choked on any code using C# 8+ features like the simplified using blocks, which my 10 lines of vulnerable code used. My recommendation to my manager and others was that for the price being asked for most of these tools, we could instead hire two or more devs to do nothing but code review and manually search for vulnerabilities and do a better job. Instead they went with Veracode, and the first thing I got got after we implemented it was three emails for false positives that didn't properly identify the code file and line number where the supposed vulnerabilities occurred, meaning I had to waste several hours communicating with the team that ran the scan to figure out where this supposedly occured. I specifically remember two of the false positives were about my use of Serilog, saying my code was vulnerable to log injection. Even though Serilog isn't vulnerable to that if you use structured logging (which my code was). I even did several log injections and verified that they didn't actually work. Edit: Looking at the reports it generated, I see it also failed to detect usage of the actually highly vulnerable BinaryFormatter class which I have seen used several times by our offshore teams. That's something that could be detected with a simple string search and they didn't detect it.
- MattPalmer1086 3y ago
  No idea how good Veracode is in practice. It's been considered in at least 3 places I've worked and never been selected. I would disagree that you can replace scanning tools with just human review though. You need both. Static analysis and software composition analysis are good at flagging possible problems, but there's a lot of noise. You ideally want an application security engineer to be reviewing the code and scan results. And also conducting threat modelling with the devs, so you prevent problems even earlier.
  - HideousKojima 3y ago

PeterisP 3y ago

Automated detection of risky code can be very useful, but it inherently lacks the capacity to differentiate whether a particular case of bad practice actually is a flaw or not. For a simplified example, usage of eval() in many dynamic languages is potentially risky and could result in a total takeover of the application, so these tools will generally flag it as 'critical' - even if in that particular case this 'eval' is run on data that can't possibly be affected by any user-controlled input (in that case it was used in a slightly weird design for code generation to save on copypasta) and does not have any security risk. Anecdotally, when I have done triage on such analysis, perhaps 5-10% of things the tools marked as 'critical' (i.e. potentially critical) were flaws which might have had some actual impact and need to be fixed. So when some vendor says in an article like this "The study found nearly two-thirds (63%) of the applications scanned had flaws in the first-party code", keep that in mind - they're generally treating all detections as real, but it's rarely the case. But on the other hand, it may well be the case that it's simpler to have a process to just clean up all suspicious places in the code; just as the simplest way to avoid use-after-free errors is to use a garbage-collected language instead of just trying to ensure that every single memory allocation in C is correctly implemented.

chrisweekly 3y ago
Yes, this. See also https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/
miohtama 3y ago
Veracode is a compliance solution, not a security solution. You buy it to have it as an insurance when your software gets hacked due to poor software engineering and you leak identities of millions of people. You can claim that “we had a process in place for secure software development” no matter if the tool does something useful or not. CISO and CEO do not get fired, users cannot sure, life goes on. To use such compliance solution may be also top-down requirement like in the case of SolarWinds after they caused the hacking of the half of the US government: https://investors.solarwinds.com/news/news-details/2023/SolarWinds-Announces-Its-Next-Generation-Build-System-Aligns-with-NIST-Secure-Software-Development-Framework/default.aspx https://investors.solarwinds.com/news/news-details/2023/Sola...

mrits 3y ago

When I stared in professional software there was almost an extreme paranoia of adding new libraries. Now we have 20 year olds adding whatever they want via NPM.

bennyelv 3y ago
Neither of those is the right answer! I'm dealing with the fallout of 10 years of "add whatever you want", and it's a unsolvable problem given the state of the system. The answer is devops: You build your system in a way that it's nearly effortless to test and deploy, then you can upgrade your dependency tree continually with minimal effort.
- candiddevmike 3y ago
  The problem is adding/changing a dependency should be a big deal: there should be validation and risk assessments performed against it, and this process should happen every time the library is updated. This isn't fun to do, and is a serious time sink, so it becomes a deterrent every time you want to update a library.
  - bennyelv 3y ago
    Fair point - it should do. However if you've already accepted the risk that a 3rd party dependency might contain a vulnerability that has been undiscovered and you don't do any deep analysis of them, then you're still making your system more secure by at least getting the fixes for known vulnerabilities out of the door.
  - jjav 3y ago
    > adding/changing a dependency should be a big deal This! In hindsight, I miss the days when adding just a single third party library took months of engineering and legal reviews and executive approvals. It forced us to be careful and only request external libraries when absolutely needed (and then think twice again). Imagine going to your security team and saying that you'll walk out to the street, stop random people and the first one who claims they know how to program, you'll allow them to commit a bunch of code, with zero review, into your production codebase. Nobody would allow that! But we allow what is in reality the exact same thing by pulling in hundreds (if not thousands) of external dependencies without any clue what they do or if the code is any good. All if running in your production systems handling customer data.

ngneer 3y ago

Odds are against security. While it is natural to want to automate, programs have a hard time understanding and reasoning about other programs.

jtdev 3y ago

[dead]

throwawaaarrgh 3y ago

Lol, I haven't noticed software developers caring about security any more than they used to. 99% of them don't care, and 1% of them are responsible for 75% of secure code. Moreover, there is no consequence if they write insecure code, just like there's no consequence if they write unreliable code. They get the same paycheck regardless of the outcome.

farukmanon12 3y ago

[dead]

mahbran10 3y ago

[dead]