I do sometimes, when I know the tech stack. (I wonder if GitHub Copilot could help in other situations?)

For example, I've been learning more about FreshRSS and Wallabag (especially now that Pocket is shutting down).

In any case, with open source, I trust that someone looks at it.

I implicitly trust FOSS more than closed source but because that trust has been earned through millions of FOSS projects.

On occasion, I will dive deep into a codebase especially if I have a bug and I think I can fix it.

You can't do this with closed source or even source available code because there is no guarantee that the code you have is the code that's been compiled.

I usually just look for CVEs. The biggest red flag is if there's 0 CVEs. The yellow flag is if the CVEs exist, but they don't have a prominent notice on their site about it.

Best case is they have a lot of CVEs, they have detailed notices on their sites that were published very shortly after the CVE was published, and they have an bug bounty program setup.

I vet lesser known projects, but yea I do end up just taking credibility for granted for larger projects. I assume that with those projects, the maintainers team with pull access is doing that vetting before they accept a pull.

About as much as I trust other drivers on the road.

As in I give it the benefit of the doubt but if something seems off I take precautions while monitoring and if it seems dangerous I do my best to avoid it.

In reality it means that I rarely check it but if anything seems off I remove it and if I have the time and energy I further check the actual code.

My general approach is minimalism, so I don't use that many unknown/small projects to begin with.

nope.

If it looks sketchy I'll look at it and not trust the binaries. I'm not going to catch anything subtle, but if it sets up a reverse shell, I can notice that shit.

It depends on the provenance of the code and who (if anyone) is downstream.

A project that's packaged in multiple distros is more likely to be reliable than a project that only exists on github and provides its own binary builds.

Nah not really...most of the time I'm at least doing a light metadata check, like who's the maintainer & main contributors, any trusted folks have starred the repo, how active is development and release frequency, search issues with "vulnerability"/"cve" see how contributors communicate on those, previous cve track record.

With real code audits... I could only ever be using a handful of programs, let alone the thought of me fully auditing the whole linux kernel before I trust it 😄

Focusing on "mission critical" apps feels pretty useless imho, because it doesn't really matter which of the thousands of programs on your system executes malicious code, no? Like sure, the app you use for handling super sensitive data might be secure and audited...then you get fucked by some obscure compression library silently loaded by a bunch of your programs.

Having gone through the approval process at a large company to add an open source project to it's whitelist, it was surprisingly easy. They mostly wanted to know numbers. How long has it been around, when was the last update, number of downloads, what does it do, etc. They mostly just wanted to make sure it was still being maintained.

In their eyes, they also don't audit closed source software. There might also have been an antivirus scan run against the code, but that seemed more like a checkbox than something that would actually help.

Packaged products ready to use? No.
Libraries which I use in my own projects? I at least have a quick look at the implementation, often a more detailed analysis if issues pop up.

Depends on how the project and how long they have been around.

I don’t know enough about programming to do it myself so I like to look at what the community says. This is one thing we’re AI could be very helpful no?

I don't because I don't have the necessary depth of skill.

But I don't say I "blindly" trust anyone who says they're FOSS. I read reviews, I do what I can to understand who is behind the project. I try to use software (FOSS or otherwise) in a way that minimizes impact to my system as a whole if something goes south. While I can't audit code meaningfully, I can setup unique credentials for everything and use good network management practices and other things to create firebreaks.

Well my husband’s work place does audit the code they deploy but they have a big problem with contractors just downloading random shit and putting it on production systems without following proper review and in violation of policy.

The phrase fucking Deloitte is a daily occurrence.

Full code audit is very time consuming. It's impossible to audit all software someone uses. However if I know nothing about project, I do a short look at the code to understand if it follows best practices or not and make some assumptions about the code quality. The problem is that I can't do this if I'm unfamiliar with the programming language the project is written in, so in most cases I try to avoid such projects.

No, I pretty much only look at the number of contributors (more is better)