Live data from Hacker News

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

itpro.com

21–28 of 28 posts

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

#21
post #5

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.

It's way worse than that, because this behavior is recursive.

I'm still wary from the time I tried to make a proof of concept with vue and a graph viewer, made an npm project with 5 dependencies and 2 development dependencies, and discovered I have just pulled 1400 indirect dependencies.

Any kind of dependency management on a project like this will fail. It simply can not be done.

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

#22

Earlier quoted context omitted.

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 lo…

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 sca…

>I would disagree that you can replace scanning tools with just human review though. You need both.

If any of the scanning tools I've used were actually fit for purpose, I might actually agree with you, but they aren't. The amount of noise they generate makes them a distraction and a net negative.

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

#23

Earlier quoted context omitted.

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 sca…

>I would disagree that you can replace scanning tools with just human review though. You need both. If any of the scanning tools I've used were actually fit for purpose, I might actually agree with you, but they aren't. The amount of noise they generate makes them a distraction and a net negative.

Completely agree there's a lot of false positives. On the other hand, having seen the number of actual vulnerabilities in code left after only manual review, it's something that's a necessary evil.

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

#24

Earlier quoted context omitted.

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.

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.

> 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.

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

#25

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.

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 lo…

Unless using (very) old target (at which point is ouch), everything will scream at you for referencing anything related to BinaryFormatter without enabling extra analyzers. It might even be a build error at this point? (either way it's being removed .NET 9 after a lengthy deprecation grace period)

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

#26

Earlier quoted context omitted.

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 sca…

>I would disagree that you can replace scanning tools with just human review though. You need both. If any of the scanning tools I've used were actually fit for purpose, I might actually agree with you, but they aren't. The amount of noise they generate makes them a distraction and a net negative.

Actually, I have a question for you on this. There's a big push towards "shift left" in the industry.

I'm all in favour of empowering developers to deal with stuff earlier, but the amount of false positives these tools generate seem like it would just distract.

I think some kind of review and filtering of them before the average dev sees them would actually work better. Do you have an opinion on that?

Post reply on HN