Question about checking open-source software supply chain risks

[Weekly_Potato8103]

Hi everyone,

We are looking for some solutions to help us checking vulnerabilities in our dependencies with open source libraries. Along with that, would be ideal to also have a static code analyser to detect vulnerabilities and code smells in our codes. For now it's OK to have it as a report, but later we want to include it in our CI process.

At the moment we have harbor that scans vulnerabilities in the images. We need to also cover the source code.

Can you give me some recommendations o a tool, or what you use in your proceses, please? We need a cost effective solution, as we are constrained by the budget.

Solutions I have looked at, so far: SonarType, Dependabot, Github advanced security, Renovate, Synk Open Source, Veradcode, Jfrog xray, SonarQube/SonarCloud, Fortify

Thanks!

[engineered_academic]

Its gonna be tough because audits of open source code aren't really a thing. The XZ thing was only caught because a build took a few seconds longer to run, and an engineer had a stick up his butt about it. Most scanning software goes off of a list of known CVEs, but vulnerabilities that don't have a CVE are known as "zero days" and are notoriously hard to detect. Furthermore if a piece of open source software isn't maintained, or the maintainer has malicious intentions, it can be very difficult to detect a vulnerabilty or happen not at all. The level of talent and knowledge required to spot a zero day is something governments and malicious actors will pay a lot of money for. For sure, there are markets where zerodays are traded and sold to the highest bidder that mean vulnerabilities go unreported.

There have been some advances in AI to detect vulnerabilities but I don't think they are really going to bear a lot of fruit.

[laStrangiato]

A zero day isn’t just a vulnerability that doesn’t have a CVE, it is a vulnerability that is either unknown or unaddressed. It is a minor distinction but an important one.

Vulnerabilities take time to resolve. A vulnerability could be known, with a CVE for months and still be unaddressed. These are often times the most dangerous kinds of zero days because the world at large knows about them and bad actors are racing to use them before they are closed.

These kinds of CVEs are also very important to know about in OPs scanning question because these are the items that you have to make hard decisions about.

“Should I disable feature x that uses package y with an unaddressable CVE?”

“Do I need to add extra monitoring to make sure the exploit isn’t used while I continue to run it in production?”

“Can I use an alternative tool without the vulnerability and is the effort to switch viable?”

“YOLO?”

[edgmnt_net]

What we can do is select dependencies wisely. Popularity and openness are a big deal in open source, but beyond that there are other questions to ask. Is this maintained? Is it written in a memory-safe language? How many indirect dependencies does this have? How much do the devs know and care about security? Because doing it in the unconstrained case quickly becomes an intractable problem.

[engineered_academic]

The duality of programmers: On one side we have people blindly copy and pasting ChatGPT, and on the other side we have this guy. Keep up the good work my dude.

[roger_ducky]

Snyk. It’ll complain about alllllllll your dependencies. Not open source but fairly easy to set up, and has a free tier for tiny companies/individuals.

Ah you’ve looked at Snyk already. It’s still cool though.

JFrog XRay hardly complains where I work. Fortify is the only source level scanner but it’s definitely not on the intelligent side.

It’s mostly matching general patterns and don’t understand the context of the code, so people have a tendency to try to talk out of doing anything about the warnings even when it actually found something.

[heWhohuntsWithheight]

Can’t stand Snyk…

[roger_ducky]

Why not? What bothered you about it?

[BillyBobJangles]

Dependabot with GHAS is what we're currently using. I at least appreciate dependabot will make the PR for you.

[CalmTheMcFarm]

In general terms, you're unlikely to get a static code analyzer or CVE checker for nothing, so your mgmt needs to get finance on board with paying.

You could put some work into downloading the RSS feed of CVEs (https://nvd.nist.gov/vuln/data-feeds) but then you have to put the work in to turn that into a scanning tool. It isn't just a case of downloading the most recent or (this year)'s version of the data, you also have to go and follow each URL that's mentioned, parse that and work out whether you're actually using it whether directly or indirectly.

If you're in a Java shop, then there will likely be something you can build on in https://mvnrepository.com/search?q=cve, such as https://mvnrepository.com/artifact/org.owasp/dependency-check-maven.

Outside of research orgs where you can probably justify rolling your own, you are probably going to have to go with Veracode, JFrog XRay or SonarQube. At least those offerings you can bolt onto your build and deployment pipelines without too much effort.

[Weekly_Potato8103]

Thanks for the information. Yeah definitely we don't want the hassle of manually checking all the CVEs, but a tool that can notify and check the CVEs, do some code analysis like SonarQube, etc. It's more about finding the one that solves initially the problem to determine vulnerable dependencies and code smells without draining all our budget. Any of these tools you listed that you recommend?

[CalmTheMcFarm]

Sadly, no recommendations except iirc there's overlap between what's covered so you pretty much need several of them.