5 ms·
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 tru
by rohansood15 1mo ago
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.
- matsemann 1mo agoYeah, 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.
- m1keil 1mo agoNo, 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.
- dhamidi 1mo ago> 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.
- ozim 1mo agoIf you have a malicious engineer I bet he will come up with idea to make a PR at a time or in a way that someone will just LGTM the PR.