Cybersecurity works inherently with risk scenarios. Your comparison is flawed because you state that there is an absolute security hygiene standard.

First of all it’s risk analysis :) On top of identifying threats (which I assume is what you mean by “scenarios”), one must assess the likelyhood of those threats and what potential impact they have.

Risk analysis, however is not the core of cybersecurity: that’s just the part security consultants are tasked with (and, consequently, the part pros talk more about, and newbies fill their mouths with).

The core of cybersecurity (and of security in general) is striking a balance between cost and benefit, which is an inherently an executive decision (you’ll hear “between usability and security” - that’s just what people say when they want to downplay “cost” to push others to move towards “security”).

That is exactly like managing your health. You I could get a comprehensive health checkup every couple months: that would possibly catch a cancer in its early stages (here’s your “risk scenario”) and wouldn’t have serious health repercussions, but I don’t because it’s not worth the money/time/hassle (cost-benefit analysis).

Exactly like one does with health, there are security measures you adopt just because you are sure they have a benefit (just that it exists) their cost is very reasonable (ie. low in absolute terms and specifically compared to how much a full risk analysis would cost): did you do a full risk analysis before deciding your PC should have a password? Before setting up a screensaver that locks your screen?

There are two common ways to implement token management. The most common one I am aware of is actually the text based one.

Yeah, the two I’ve my OP seems to point

Even a lot of cloud services save passwords as environment variables after a vault got unlocked via IAM.

Environment variables have their attack surface, which is way smaller than that of a text file stored in your home directory.

That’s because the risk assessment is: If a perpetrator has access to these files the whole system is already corrupted - any encryption that gets decrypted locally is therefore also compromised.

I’m not sure what “the whole system” refers to in “If a perpetrator has access to these files the whole system is already corrupted”.

If the system is my PC, then the reasoning is backwards: the secrets get compromised if (they are not secured and) my PC is breached, not the other way round. On top of that, while basically a lot of breaches may expose the files in your home directory (say, a website gaining read access through your browser, or you accidentally starting a badly written/configured webserver, or you disposing of your old drive, or your PC being stolen, or… many others), a lot fewer compromise properly kept secrets (say, password-protected ssh keys).

If the system is my Codeberg account, then that’s the whole reason I should secure my secrets. (Admittedly, neither of these make much sense, but I don’t know what else the system could be).

Besides that, I must say “who cares? we’re fucked anyway” is quite the lazy threat assessment :D

The second approach is to implement the OS level secret manager and what you’re implicitly asking for from my understanding.

There are a lots of secrets management tools that have little to do with the OS (I’d even say most of them are): bitwarden and all other password managers, ssh keys and ssh-agent, sops, etc.

While I agree that this would be the “cleaner” solution it’s also destroying cross platform compatibility or increasing maintenance load linear to the amount of platforms used, with a huge jump for the second one: I now need a test pipeline with an OS different than what I’m using.

I don’t get the point… It would seem you are trying to tell me that secure tools are impossible to build (when you yourself have talked of “vaults that get unlocked via IAM”) or that I should just use insecure tools (which… is my own decision to make)?

If you took offense because I called those forjego CLIs “dumb” I do apologize (are you the dev of one of those?).