All these things help (a lot) - but there is another consideration that we can keep in mind. There would seem to be little reason (other than bad intent) to target a distro unlikely to be a ‘production server’ distro - and worse, one with a relatively knowledgeable user base. In other words, it would probably take quite a bit of effort, with little hope of return, to implement much in a PKGBUILD.
Generally the untargeted do pretty well! 
So what made you use endeavour, vs pure Arch? Or why use endeavour vs Arch in your opinion?
EndeavourOS is pure Arch, with a really nice forum.1 
The best thing about EndeavourOS, apart from this forum, is the conscious decision by its dev team to stay as close to upstream as possible. If that ever changed, I would stop using EndeavourOS. There is already Manjaro for those who like that, and EndeavourOS should not try to out-Manjaro Manjaro.
1 and some custom theming, a tiny custom repo, and a GUI installer.
To be honest, I know things like flatpaks are very unpopular with more seasoned Arch user types, but I really think if we are talking about making more software available to novice users, ‘app store’ type tools with sandboxing built in sound like a good solution. I have seen complaints of how exactly Flatpak implements sandboxing, I also am aware of the issues with Snaps and their proprietary nature, but I am eager to see the development of more fine grained sandboxing with good defaults (all preferably without any proprietary backends, of course).
Sandboxing is also great for circumstances when software comes from a ‘trustworthy’ big name company, which you know to be anything but user and privacy respecting. If you have to run it for work, then having the option to seal that off from as much of your system as possible is very welcome. I don’t care if Steve Balmer and Bill Gates themselves deliver their software to me on a golden platter and verify that no third party intercepted it…I’d prefer to have it running in Faraday cage in a tin foil bunker.
Personally, I would gladly put up with some bloat in terms of dependency overlap to have at least some semblance of sandboxing built in. Not trying to go off topic here, but I bring it up because I can definitely see the point of having the AUR built and operated how it is and the benefit of developing the skills to check package builds yourself. Likewise, I can see the benefits of having a system set up that does some of the security legwork for more novice users. Not every user will have the time or interest in making the transition to that level of technical ability. If your distro does not want these types of users, that’s perfectly ok, but for all the other distros out there that welcome less technical users, sanboxing might just be the way to go.
You might have a look at aura which scans the PKGBUILD to detect obvious issues.
Tying that into a clone of the AUR could be possible, so suspicious PKGBUILDs could be automatically flagged.
Interesting, huh.
Relevant section from the Aura Guidebook:
@Kresimir is totally correct it is up to the user to look after his system, AUR is for Arch users like everything Arch is kiss if you use it you should respect it.
You should use it the correct way that means no helpers, inspect it, build the package manually, and most importantly vote for the package up or down.
As I mentioned above, I do not think it is wise to rely on aura as its algorithm is open-source and is probably easily fooled by someone malicious. While it may be useful to detect the most obvious of problems, it is no replacement for manual inspection by the user. And there is danger of creating a false sense of security.
In general, the AUR and automation do not mix well (even using helpers like yay is slightly pushing it, it is just that the convenience of it outweighs any potential concerns). The system is designed to be used by users who understand it, and within that context, it is perfectly safe. Those who are unwilling to invest the very minimum of effort required to understand the AUR are probably just better off not using it. This is not elitism, but pragmatism.
I’m not arguing against the user being responsible for their system.
I was just pointing out a tool which could be used to help highlight suspicious packages. For example, I could set up a git hook which runs the checker every time a repo is updated and alert me so I can go in and check the package, then flag it as necessary.
The security issues with the AUR are greatly overstated. They reflect more on how security conscious Arch users are than on the actual security of what is contained in the AUR.
In my opinion, AUR is the most secure community maintained package source of all the major distros. The PKGBUILDs are totally transparent and simple enough to be easily read.
On the other hand, most other distros use some form of binary packages which are inherently unsafe because you have no idea what is inside them. flatpaks, snaps, appimages, debs, rpms, etc. For the most part, there is no easy way to tell what is inside. In these cases, you need to put absolute trust in the packager. Unless it is packaged directly by whoever writes/publishes the software, this is a much bigger risk than most people understand.
I am always amused when people come from an Ubuntu-based distro and refuse to use the AUR because it is insecure but gladly used 25 ppa’s when they were Ubuntu.
Containerized software doesn’t really solve this issue. It is still a binary package. About the only advantage(in this context) is that the access is sometimes controllable and transparent. Flatpak is probably the best at this but it is of limited usefulness because the controls aren’t granular enough.
In the end, AUR puts you in control of your security while most other formats puts the packager in charge.
@all could you calm down a bit… it is totally O.K. to have different opinions on the topic, but we like it civil here 
I really must develop the know how to be able to easily read/scan pkbuilds. I use very few AUR packages, because most software I use is on the official repos. Beyond checking the source of packages, I don’t really know what to look for. I think that just means my bash skills aren’t advanced enough.
Theoretically though, if in future Flatpak or its descendants are built to offer more fine grained access control and more secure sandboxing, wouldn’t this limit the damage software can do, or at least how far the compromise can spread?
I pretty much only use flatpak for proprietary software, where even if I could ‘trust’ the binary, I basically don’t trust the product but still need to use the software somehow. Not that it really fundamentally changes the problems with flatpaks, but I like using flatseal to be able to visually assess the permissions of any flatpaks I have installed. That kind of at-a-glance interface for a proper granular sandbox would be beautiful.
You still have no idea what’s inside the package though, so that issue would not be solved. With the AUR, you know exactly what goes into the package, because you’re the packager.
But yes, good sandboxing can make it harmless, but that means imposing a lot of restrictions on the software – no direct network access, no direct storage access, no direct access to any hardware, etc… Which limits the usefulness of a lot of software.
In my opinion, this is the most important part so if you only check one thing, this is a good start. 
The next would be to make sure there are no invocations of su or sudo
Another good thing to do is turn on the package diff menu in yay and have it show you the diffs when AUR packages are updated. This will show you what changed between one version and the next so instead of having to review the whole thing each time you can see just the changed lines which will usually only be the version and the checksums.
I already linked my list of things to look for when installing packages from the AUR twice in this thread, so I won’t do it again, just scroll up a bit
(it’s post no. 6)
Very handy advice, will look into this.
Oh, oops, yes! I will read through this.