Securing the Supply Chain of Nothing | Hacker News Reader

Securing the Supply Chain of Nothing

swagitda.com

46 pointsahamez24 comments

I'm not going to argue that the NSA report is amazing or terribly well-written, but re-reading it with the principle of charity nullifys many of these rebuttals.

For one example, from the rebuttal:

> If there is concern that their user credentials will beget malefaction and mistakes, then why discourage service accounts2, which are inherently decoupled from specific user identities?

But then looking at the text from the document itself:

> Minimize and regularly audit service accounts,

> The use of service accounts, like non-human privileged accounts used to run automated processes, should be minimized and carefully audited. Every service account login should be logged. These logs should include date and time and the origin of login. Service accounts should follow the “least privileged” policy. All service accounts should be regularly reviewed to assure they are still needed, and unnecessary accounts removed.

I don't think the document is saying to avoid service accounts in favor of something silly like shared passwords. It's saying to use the fewest you can get away with, delete unused ones, and regularly audit access to them.

Yes, agreed. The report itself is not unreasonable. The article sets up a lot of straw men and demolishes them.

>> enterprises would likely be better off with no documentation at all and just reading the source code.

That, from the article, is quite a statement. Unsurprisingly, no explanation is offered.

Not the OP, but bad/not up-to-date documentation is worse than no documentation at all, as it might take you on the wrong paths while saying that that's the correct way to do it.

Documentation that explains historical context is sometimes useful. The part that gets you is assuming it to be current. It might help to put dates on things?

Documentation at a high level should exist as to what a system does and roughly how it works. Feature changes and so on need to be documented somewhere. The high level design aspects and change.

Detailed documentation on software is a waste of time in my opinion. The software itself is indeed the best guide to how it actually works.

Having no documentation at all is not good.

keep the space shuttle flying, do not simplify this code

Safety critical systems is a whole discipline I'd love to know more about.

that's a comment from the kubernetes codebase that has been at the center of 'docs vs self-document code vs linters' debates

https://github.com/kubernetes/kubernetes/blob/ec2e767e593953...

and strong agree, safety-critical code is fascinating; I mostly pick my tools for productivity, can't imagine how different my stack would be if it connected to dangerous equipment

Didnt know that, thanks! The comment in that code does a pretty good job of explaining why the code looks the way it does.

You've just volunteered to write the docs!

In fact, I kind of did. Agile saved me from it. Like literally, I pointed out we need a comprehensive business requitemtns doc for a project. The answer was it will be covered under the individual user stories in Jira...

Same for documentation, when you change the code, change the documentation.

Nitpick to the footnote about Pokémon: Harden is not a no-op. It increases the user’s defense stat. What makes wild Metapod helpless is that they only know Harden, rather than also having attacking moves.

Nitpick squared (and for fun), once metapod runs out of PP for harden (i think it has 30pp), it falls back on the move all pokemon technically know when they're out of moves: struggle. Which _is_ an attack move, albiet one that isn't very good (since it hurts the attacker more than the opponent), and from a practical standpoint you rarely get to the point of using struggle (though I do have vauge memories of using struggle to beat the Rock Gym onyx, since it's Bide move doesn't do damage when you only use Harden against it). The nitpick here being that Metapod does kinda know an attack move

*This is all pulled straight from memories of playing Blue Version

I agree 100% with this statement (and with the article in general):

    “Basic hygiene” is arguably better than any of these bolt-on option, including things like:

    * Knowing what dependencies are present
    * Being purposeful about what goes into your software
    * Choosing a tech stack you can understand and maintain
    * Choosing tools that are appropriate for the software you are building

It's true in security in general, that really sticking to basic hygiene would mitigate a lot of more advanced threats. We haven't had much success over the decades though in getting people to stick to it.

A bit OT, but I find it somewhat counterproductive that the link that gets (close to) HN's front-page is not "NSA Releases New Security Guidelines" but instead "Random Developer X Thinks New Security Guidelines are Total Garbage".

Like, I get how story submission and voting works on HN, but I think the effect that the first news about the guidelines arrive with immediate negative framing is not really helpful to evaluating them.

This article is just an extended developer moan about having to do security. Honestly, the recommendations in it are quite sane. I doubt anyone would do everything in it.

Many of the items in it are not prescriptive, and are just examples of mitigations, but he seems to think that all of them are required.

He bemoans that "non vendor tooling" isn't covered (whatever that is) and then talks about entire product categories like IDS, AV and DAST. Ummm... you dislike using commercial intrusion detection systems, anti virus and dynamic application scanning tools? You want to write your own?

He attacks the report for wanting static analysis on code before it's checked in, and then immediately moans that there's no consideration for integrating static analysis into dev workflows and getting fast feedback. Hint: faster analysis that runs in the IDE solves both problems.

He thinks 30 years of SCM systems mean the threat of modification of code has gone away. I got news for him...

TL;DR straw man moan about security from someone who doesn't understand it.

Nicely said.

This is written by a) a woman, and b) someone who works in information security.

My bad, I didn't check who wrote it.

I assumed it was written from a developer perspective, as the arguments seem poorly made from an infosec perspective.

To give some context here, I currently work on SDLC and dev security. Supply chain attacks are high on the agenda right now.

I don't have a problem with this set of recommended practices. And that's all they are. These are things to consider and only constitute guidance, which may be out of date. It says all this in the intro.

Weird perspective from an infosec person. Controls are like brakes - they let the car go faster.

There’s a lack of context as well… while intelligence agencies have a perspective fueled by lots of cash, many companies are working over their heads and adopting a “hold my beer” attitude with customer data.

Reply on news.ycombinator.com