Hacker News Reader

Comment by snowwrestler | Hacker News Reader

> To get the merit badge, we also had to document an approval process that ensured changes that hit production were reviewed by another developer.

> This isn’t something we were doing prior to SOC2. We have components that are effectively teams-of-one; getting reviews prior to merging changes for those components would be a drag.

This mindset kind of blows my mind. As a customer, it makes me want to ask all my vendors for SOC2 now.

As a comparison, we have a small in-house team that develops some nonprofit websites; no PR goes to production without being reviewed by another developer.

I’m honestly flabbergasted at such a seemingly blasé attitude about insider threats. It doesn’t have to be a top-secret Chinese operation to subvert your company. It can be as simple as a developer you know well who is nursing some simmering resentment over a perceived slight.

View on HN

None of the companies you trust are secure from insider threats by dint of PR review --- a thing we do, but override for urgent changes in oddball services sometimes, like most companies I've worked with over the past 10 years.

I’m confused, in the post it seemed like you said you don’t do PR reviews, but here it seems like you’re saying you do, except for emergencies.

Read more carefully. Or, stay flabbergasted! Flabbergasting can be very satisfying.

I feel like you’re being unnecessarily confrontational.

You wrote “changes that hit production were reviewed by another developer. This isn’t something we were doing…”

I cited PR as an example of a change and you’re acting like I’m trying to argue that PR reviews alone stop insider threats. (I’m not.)

There are lots of way to change production. To me it looks like you said effectively one person could do so without being checked by another person. To me that sounds like a hole for problems to drive through. And that SOC2 was the impetus for you to tighten it.

If I’m wrong, you can take it as feedback on your writing, I guess. You know what you wanted to write; I’m telling you what I read.

Or you can just treat me like I’m an idiot if you want. I don’t think I’m an idiot, and I’m not the only person you’re being combative with.

This is true. It was a bit uncalled for.

The commenter above constructed a supercilious put-down based on an uncharitable reading of the post, where the most direct and technically accurate response would have required me to cut against the point the post makes, which is that in a showdown between SOC2 and a mature, well-thought-out dev process, the dev process can and should win.

I'm comfortable with what I brought to the thread in response. If you detected contempt, well, you're not wrong. But it's for the comment, not the commenter, who I assume was just having a bad day, like I (in a way) was.

You obviously wanted a more charitable reading from me; please return the favor. I did not set out in bad faith to make you look bad. I read something surprising and took it seriously—dumb me, I guess.

Miss me with this stuff. You chose the words "honestly flabbergasted", not me.

Part of the ethos of "we're not doing stupid stuff for SOC2" and "we're going to be direct about how this stuff works so other people can hopefully benefit" is assuming that we're all reasonable adults who want to understand how SOC2 works, and aren't looking to score dunks off unintended subtext.

Flabbergasted was how I honestly felt. But you’ve more than adequately clarified where I was wrong.

>Consumers, meanwhile, split down the middle between cynics who’re certain it’s worthless and true-believers who think it sets the standard for how security should work.

There are many dependencies in the software supply chain that are maintained by a single person (open source or not),so it seems silly to default assume malicious intent for employees of a software vendor with a good reputation.

There are bad actors that no SOC2 control would catch, and there are good actors (the default) where no SOC2 control affect their behavior.

SOC2 is never part of my decision making, rather, I carefully study the company and product offerings to decide if right fit.

(This is coming from someone who goes thru an annual SOC2 audit)

https://xkcd.com/2347/

It's frustrating because the supercilious "what, you don't do code review!" comments the post attracted put me in the position of having to explain that we do in fact do code review, like every other mature dev shop, but that cuts against the point the post is making, which is that SOC2's understanding of code review is black-and-white and complicated dev projects have occasionally complicated dev processes --- and, importantly, your dev process can and should win the argument with the SOC2 auditor.

The third party dependency point is the best rebuttal I think you could come up with. It's exactly right: in the SOC2 view of how code works, you can't commit a 3rd party dependency without every line of its code being reviewed and approved. Nobody does that. It was my job for 15 years to do that for other people, and nobody came close to 100% coverage. Or 50%. SOC2 demands that you pretend you're achieving that. That's stupid. We're not doing stupid stuff for SOC2.

I reserve the right to be unproductive and standoffish with people going out of their way to misconstrue what this post is saying. I'm grateful that other people can contribute the productivity instead. Thank you!

Reply on news.ycombinator.com