Is "just don't commit secrets" technically bad advice?

No — it's correct advice. The research question isn't whether it's true, it's whether telling someone true advice changes their behavior when following it has a real recurring cost and skipping it has a perceived-low individual risk. Multiple independent research threads say that gap predicts rejection.

What is Cormac Herley's "rational rejection" argument?

Herley's 2009 paper argues that users and practitioners aren't ignorant when they ignore security advice — they're making a locally rational trade-off. If the cumulative time cost of following a piece of advice, multiplied across every time they'd need to follow it, exceeds their expected loss from the risk it prevents, rejecting the advice is the individually rational choice, even though it may be costly in aggregate across an organization.

Does giving developers better, more usable security tools fully solve this?

It helps significantly but doesn't fully solve it. Research comparing cryptographic API usability found that simpler APIs reduced developer errors but did not eliminate insecure code — meaning tool design lowers the failure rate, but the underlying behavioral pattern (prioritizing the task's stated functional goal over an unstated security requirement) still needs to be designed around, not assumed away.

Why Telling Developers Not to Commit Secrets Doesn’t Work

The advice everyone already knows

“Don’t commit secrets” is not a secret. It’s in every onboarding doc, every security training deck, every postmortem template. And it keeps not working — this site’s own coverage of a 2023 USENIX Security study found nearly a third of surveyed developers had leaked a secret firsthand despite near-universal awareness of the rule. That’s not an isolated finding. Three separate, independent research threads — security economics, cryptographic API usability, and behavioral study design — all converge on the same underlying mechanism for why correct advice fails to change behavior.

Rejecting advice can be the rational choice, not a mistake

Cormac Herley’s So Long, and No Thanks for the Externalities: The Rational Rejection of Security Advice by Users (NSPW 2009) reframes the whole problem. Herley argues that when the cumulative cost of following a piece of security advice — repeated every single time it applies — exceeds the individual’s expected loss from the risk it prevents, rejecting the advice is the rational choice for that person, even if it’s costly in aggregate. Security advice, he argues, routinely ignores its own externalities: it prices in the harm of the breach, but not the total time cost imposed on every person who follows the advice correctly, forever.

Apply that directly to secrets: a developer debugging a broken local build who copies a teammate’s .env file is trading a small, deferred, someone-else’s-problem risk (a credential sits in plaintext) against an immediate, certain cost (getting blocked right now). Herley’s model predicts exactly that trade gets made, over and over, regardless of how many times the policy document says not to.

Four-step research chain: security advice imposes a real recurring cost, developers rationally reject advice whose cost exceeds its perceived individual benefit, usable tooling reduces but does not eliminate the resulting mistakes, so the fix is making the secure path cost less than the insecure one.

Usable tools help — and still don’t close the gap alone

If the fix were simply “give developers better cryptographic tools,” Acar et al.’s research comparing the usability of cryptographic APIs (IEEE S&P 2017) is the study that tested that directly. Its conclusion is more sobering than a tooling pitch would like: simpler, more usable APIs measurably reduced the errors developers made, but did not eliminate insecure code — documentation gaps and unclear defaults kept producing mistakes even among developers using the “easy” option. Usability moves the failure rate; it doesn’t zero it out on its own.

Even skilled people deprioritize security unless it’s the stated task

Naiakshina et al.’s qualitative study on password storage (CCS 2017) adds the piece that explains when the trade-off in Herley’s model tips toward insecurity. Studying CS students building an authentication feature, the researchers found functionality was consistently prioritized over security unless security was explicitly named as a requirement in the task itself — participants capable of implementing secure storage still defaulted to the fastest working approach when the task was framed as “make login work,” not “make login work securely.” A secret dropped into a .env file to unblock a build is the same pattern: the task was framed as “get this running,” and security was never made part of that frame.

Where this actually points

Put the three findings together and the intervention point becomes clear. Herley says the secure path needs to cost less than the insecure one, not just be technically available. Acar says better tooling narrows the gap but won’t close it through usability alone. Naiakshina says the secure option has to be the path of least resistance by default, because task framing under pressure won’t reliably surface it as a requirement on its own.

That’s the design target envseal is built around: committing an encrypted vault is not a slower path than committing a plaintext .env — it’s the same git add, the same workflow, with the encryption handled underneath. It doesn’t rely on a developer remembering to choose the secure option under pressure, because there isn’t a slower, separate secure option to choose. And because task framing under pressure won’t reliably flag a pasted credential as a security decision either, Secret Sentinel catches what gets typed into a Jira ticket or Confluence page in exactly that moment — a detection layer that doesn’t depend on anyone remembering the policy at 2 a.m.