So an engineer who knows your codebase and tests can sneak in malicious code/backdoors because you're high trust.

And I am guessing you'll extend that high trust to your agents/'orbs' next. And I am sure you'll find an auditor who'll go with it coz frankly most don't care.

I am not surprised there are folks willing to do this, but I am surprised that you feel you must brag about it. And you ARE bragging when you title the post the way you did. Good luck.

No, that's not a brag but a suggestion to take things into context and not apply soc2 as a cookie cutter solution where a 20k employee enterprise and a 20 people startup must share commonalities.

In a 20 people startup it's very likely that most engineers have access to production anyway and can inject malicious stuff directly, so PRs stop no one really.

> So an engineer who knows your codebase and tests can sneak in malicious code/backdoors because you're high trust.

What is the alternative? Bumping a dependency in a PR and getting a LGTM can also introduce a backdoor.

That's another form of high trust: your trusting the publisher of the dependency.

High trust comes with high responsibility, which is easier to enforce when the trusted party is an individual on your team with generally aligned incentives, rather than an organization or unpaid individual on the internet serving many.

Yeah, saying it's verified with tests is kinda moot when the code change can just modify the same tests or verifications that will be run on it.