Depends on what you mean by "audit".

I look at the GitHub repo.

• How many stars?
• Last commit?
• Open issues
• Contributer count

Do I read the whole code base? Of course not. But this is way more than I can do with closed source software.

I rely on Debian repo maintainers to do this for me

Nah. My security is entirely based on vibes and gambling

depends like for known projecte like curl i wont because i know its fine but if its a new project i heard about i do audit the source and if i dont know the lang its in i ask someone that does

If it's a project with a couple hundred thousands of downloads a week then no, i trust that it's been looked at by more savvy people than myself.

If it's a niche project that barely anyone uses or comes from a source i consider to be less reputable then i will skim it

No, so I only use well known widely used open source programs. If I'm doing a code review I'm getting paid to do it.

I don't have the know how to do so, so I go off of what others have said about it. It's at-least got a better chance of being safe than closed source software where people are FULLY guessing at if its safe or not, rather than what we have with at-least 1 person having poured over it that doesn't have ties to the creator.

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.

Let me put it this way: I audit open source software more than I audit closed source software.

some yes, I'm currently using hyde for hyprland and I've been tinkering with almost every script that holds the project together

I don't audit the code, but I do somewhat audit the project. I look at:

• recent commits
• variety of contributors
• engagement in issues and pull requests by maintainers

I think that catches the worst issues, but it's far from an audit, which would require digging through the code and looking for code smells.

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.

For personal use? I never do anything that would qualify as "auditing" the code. I might glance at it, but mostly out of curiosity. If I'm contributing then I'll get to know the code as much as is needed for the thing I'm contributing, but still far from a proper audit. I think the idea that the open-source community is keeping a close eye on each other's code is a bit of a myth. No one has the time, unless someone has the money to pay for an audit.

I don't know whether corporations audit the open-source code they use, but in my experience it would be pretty hard to convince the typical executive that this is something worth investing in, like cybersecurity in general. They'd rather wait until disaster strikes then pay more.

If I can read it in around an afternoon, and it’s not a big enough project that I can safely assume many other people have already done so, then I will !

But I don’t think it qualifies as “auditing”, for now I only have a bachelor’s in CS and I don’t know as much as I’d like about cybersecurity yet.

I know lemmy hates AI but auditing open source code seems like something it could be pretty good at. Maybe that's something that may start happening more.

Of course I do bro, who doesnt have 6 thousand years of spare time every time they run dnf update to go check on 1 million lines of code changed? Amateurs around here..

It's not feasible. A project can have 10s or 100s of thousand lines of code and it takes months to really understand what's going on. Sometimes you need domain specific knowledge.

I read through those installers that do a curl gitbub... | bash. Otherwise I do what amounts to a "vibe check". How many forks and stars does it have? How many contributors? What is the release cycle like?

I generally look over the project repo and site to see if there's any flags raised like those I talk about here.

Upon that, I glance over the codebase, check it's maintained and will look for certain signs like tests and (for apps with a web UI) the main template files used for things like if care has been taken not to include random analytics or external files by default. I'll get a feel for the quality of the code and maintenance during this. I generally wouldn't do a full audit or anything though. With modern software it's hard to fully track and understand a project, especially when it'll rely on many other dependencies. There's always an element of trust, and that's the case regardless of being FOSS or not. It's just that FOSS provides more opportunities for folks to see the code when needed/desired.

I do not. But then again, I don’t audit the code of the closed source software I use either.

I do not, but I sleep soundly knowing there are people that do, and that FOSS lets them do it. I will read code on occasion, if I'm curious about technical solutions or whatnot, but that hardly qualifies as auditing.

I do not audit code line by line, bit by bit. However, I do due diligence in making sure that the code is from reputable sources, see what other users report, I'll do a search for any unresolved issues et al. I can code on a very basic level, but I do not possess the intelligence to audit a particular app's code. Beyond my 'due diligence' I rely on the generosity of others who are more intelligent than I and who can spot problems. I have a lot of respect and admiration for dev teams. They produce software that is useful, fun, engaging, and it just works.

I trust the community, but not blindly. I trust those who have a proven track record, and I proxy that trust through them whenever possible. I trust the standards and quality of the Debian organization and by extension I trust the packages they maintain and curate. If I have to install something from source that is outside a major distribution then my trust might be reduced. I might do some cursory research on the history of the project and the people behind it, I might look closer at the code. Or I might not. A lot of software doesn't require much trust. A web app running in its own limited user on a well-secured and up-to-date VPS or VM, in the unlikely event it turned out to be a malicious backdoor, it is simply an annoyance and it will be purged. In its own limited user, there's not that much it can do and it can't really hide. If I'm off the beaten track in something that requires a bit more trust, something security related, or something that I'm going to run it as root, or it's going to be running as a core part of my network, I'll go further. Maybe I "audit" in the sense that I check the bug tracker and for CVEs to understand how seriously they take potential security issues.

Yeah if that malicious software I ran that I didn't think required a lot of trust, happens to have snuck in a way to use a bunch of 0-day exploits and gets root access and gets into the rest of my network and starts injecting itself into my hardware persistently then I'm going to have a really bad day probably followed by a really bad year. That's a given. It's a risk that is always present, I'm a single guy homelabbing a bunch of fun stuff, I'm no match for a sophisticated and likely targeted nation-state level attack, and I'm never going to be. If On the other hand if I get hacked and ransomwared along with 10,000 other people from some compromised project that I trusted a little too much at least I'll consider myself in good company, give the hackers credit where credit is due, and I'll try to learn from the experience. But I will say they'd better be really sneaky, do their attack quickly and it had better be very sophisticated, because I'm not stupid either and I do pay pretty close attention to changes to my network and to any new software I'm running in particular.

I'm unlikely to do a full code audit, unless something about it doesn't pass the 'sniff test'. I will often go over the main code flows, the issue tracker, mailing lists and comments, positive or negative, from users on other forums.

I mean, if you're not doing that, what are you doing, just installing it and using it??!? Where's the fun in that? (I mean this at least semi seriously, you learn a lot about the software you're running if you put in some effort to learn about it)

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.

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.

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.