Like, can I expect that every docker image I pull has been audited for at least obvious and intentional backdoors? What about if I update a trusted image, and some time down the line the original posters account is breached? Has the code had an in-depth audit that at-least indicates that it's /somewhat/ resilient to being poked with a sharp stick?
2Factor at least improves security, but my security model must still rely on the Dockerfile maintainer not getting breached - I've never met any of the maintaners, and cannot independently verify their operational security at all.
I know there's at least some foil covering my hair right now, but the security of these kinds of services means anyone who's using them is effectively building a whole bunch of infrastructure right on top of a handful of houses of cards.
If anyone has any solutions that would solve this, I'd be interested in hearing and maybe implementing them. I've long thought of some sort of centralized community driven independent code-review/pentest notes to at least provide some level of assurance, but I don't think there'd be enough interest to hit critical mass, and the project would just die out.
It'll only be a matter of time before there's a huge breach as a result of tainted software ending up in a popular docker build, github repo, or packaged into a mainstream Linux distro repo.
I have no idea if distros inspect package source, last time I googled it, I couldn't find any indication either way.
That said, a lot of open source software actually follows pretty good security practice in general, and is eyeballed by some smart people, and so you generally get a little better quality than you'd get from a bunch of devs locked up in a cathedral that don't have to fear people pointing out their embarrassingly insecure bugs. But all that does not stop kernel.org from getting compromised, which has happened. So, don't count on auditing, but the code isn't terrible, but that also doesn't mean anything.
The best practice I've found to deal with that is to run old-yet-supported-and-patched software and hope it's old enough that if there's something wrong with it, hopefully somebody has caught it. You don't really get that benefit if there's one single source for all the source/build artifacts, but it can work for artifacts that have many mirrors and have good signing practices.
On your end, you need to check for and update known-vulnerable versions of software. You have to do that for any software, but especially OSS, where there is no sales or support associate that's going to e-mail you to tell you to update your applications. You can easily be running OSS software which is known to be vulnerable.
Speaking of, are there any UI/UX design resources (books, tutorials, blog posts, etc.) on for modern authentication flows (2FA, OAuth, etc.)?
I've been searching for a while and can't seem to find anything substantial. All the design discussion I can find is around protocols/handshakes/security, but nothing about UI/UX best practices and possibilities.
https://meta.discourse.org/t/webauthn-support/126454?u=falco
U2F is not.
