Hacker News Reader

Comment by jimmychangas | Hacker News Reader

Can you elaborate on what do you think would be a good solution to this problem? In my opinion, having big central sources of libraries makes it easier for security scanning services to operate. Companies hosting libraries locally (e.g. with Sinopia, Nexus, Artifactory) have to proactively monitor them, but most commonly will let them frozen at a specific version and miss all security patches.

View on HN

Really the only "solution" is to ensure that you have some way to establish trust in all the software libraries you use.

For commercially provided libraries that could be a contract specifying security requirements, with some specific measures of how to do that.

For Open source the only real option I can see is to curate your own package repositories and get a level of review that you're comfortable with. Definitely fixing versions and insisting on review before upgrade would help.

The problem with automated scanning is that they can't really find backdoors or just generally insecure code, they can find known vulnerabilities. They could use static analysis to find insecure code, but my experience of SAST tooling is that it takes a lot of manual effort to tune, it's not a pure automated scan option.

That's not to say that automated scanning provides nothing, but that it has limitations.

> curate your own package repositories [and review them]

This is a non-starter. This is even worse than "just run your own mail server".

sure but what's the alternative? Unlike mail servers where there's tonnes of good commercial solutions you can use, I'm not aware of many good options for curated software library repo's

There's tools you can use to add automated scanning to your repo's and pin versions of packages, but that's doesn't really feel like curation to me...

companies like Sourceclear seemed to me to be going down this line but that doesn't seem to be the drive of their offerings any moe.

In the end it all comes down to reviewing code you have to trust. It's just that it's too much for most code, so there has to be something that makes potentially insecure code explicit and dealt with on use and the rest of the code usable without having to trust it.

Reviewing code mitigates a lot the risk but it does not solve everything (ex: vulnerabilities hidden in plain sight).

It also implies that you are compiling everything from source code or you trust the distribution channel of the binaries.

And you do it every time there is an update that you want to use. And you have a system that promptly alert you of vulnerabilities in libraries you use.

Unless you have a handful of modules that are already self contained, it is not practical for most teams.

Reply on news.ycombinator.com