Hacker News Reader

Comment by tomjen3 | Hacker News Reader

Hard disagree on that. As a programmer we have access to more than most accountants. How hard would it be for most programmers to put in a backdoor they could later claim was a bug?

Criminal convictions are perhaps not the best measure of trustability.

View on HN

> As a programmer we have access to more than most accountants

Do we? What does the average programmer working on internal business applications, b2b services or CMSs have access to that is of any risk?

It's always hard to estimate what the average case is for something like this. But I would guess that the average programmer do have access to "production data". What that contain is obviously industry specific, and the most sensitive industries are (hopefully) well regulated and not average, like health care or finance.

But I would guess that programmers at Tinder/Grindr/$datingSite had access to production data in the early days. Probably many SaaS things, perhaps doing stuff in the HR/recruitment/time reporting area. For B2B I'm guessing many programmers have access to business sensitive data, that competitors would like to get their hands on. At the least I would guess that at least the average backend developer have access to all contact info / emails for all users in services they work on.

Obviously all best practices say that random Joe programmer shouldn't have access to these things, but I don't think that match the _average_ reality.

I think so. Many sites have some sort of sensitive user data that could be exploited. If you work in ecommerce, you likely have access to the payment gateway as well.

> How hard would it be for most programmers to put in a backdoor they could later claim was a bug?

My guess is that is actually pretty fricking hard, as otherwise it'd be happening all the time. I.e. you can maybe make a backdoor to something without monetary consequences (even in a bank most systems don't handle money), but introducing a backdoor to the core system (i.e. a money-dealing one) in such a way that it is not noticed in code reviews or testing AND you can claim plausible deniability seems hard.

This is why all non-trivial applications need to have a code review process and a CI/CD pipeline that ensures that no application goes into production except via that pipeline, and that all code is reviewed prior to deployment. It’s not a guarantee, of course, but it’s a start.

How do you hotfix production? Do you have a special "go fast" flag in the pipeline?

In my experience, the pipeline itself is a negligible amount of time. Directly hotfixing something is a high risk thing that no company I've ever worked for would tolerate.

You don't. You build the ability to roll back to a good state.

If your pipeline doesn't allow you to deploy quickly, fix the pipeline. Nothing should go to production that doesn't go through the pipeline.

> Criminal convictions are perhaps not the best measure of trustability.

Unskillful or unlucky criminals are prosecuted by the law, more careful criminals often defy the law.

Reply on news.ycombinator.com