Clarify inappropriate use text in concise guide for evaluating secure software

[david-a-wheeler]

The concise guide to developing secure software says "Software with many users or large users may be inappropriate for your use." This doesn't seem to be clear enough, and there was a discussion here:
#832 (comment)

Perhaps replace it with something like this:

"Choose software that is a good solution for your problem, don't choose it merely because it's used by large companies or because it's the latest fad; avoid Hype Driven Development.

This is an issue, not a PR, because we're in the middle of reorganizing the concise guide & don't want to lose this idea.

[david-a-wheeler]

Background discussion:

I was thinking about the point of You are not Google: "if you’re using a technology that originated at a large company, but your use case is very different, it’s unlikely that you arrived there deliberately; no, it’s more likely you got there through a ritualistic belief that imitating the giants would bring the same riches."

Basically, while software with many users is often capable, it might not be a good match for your use case. You need to choose software relevant to your problem, not just choosing some software because it's the latest fad. The text is an attempt to counter fad-driven development aka Hype Driven Development.

I'm quite open to finding another way to say it.

[gkunz]

Thanks, @david-a-wheeler. This indeed clarifies the intention of the recommendation. I agree that the aspect of "technical fit" is quite relevant for the evaluation and selection process. For instance: besides a better technical fit to a problem at hand, it may also be easier to work with a smaller community to evolve the upstream code to address ones use cases.

On the other hand, would you say that it is a valid generalization that projects with many large users can potentially address security issues more quickly? So, as these guides are written primarily in the context of security, should we add such a remark to this recommendation as well?

[david-a-wheeler]

On the other hand, would you say that it is a valid generalization that projects with many large users can potentially address security issues more quickly? So, as these guides are written primarily in the context of security, should we add such a remark to this recommendation as well?

I suspect that's often the case, though there is no guarantee. So that's probably worth mentioning somewhere.

Of course, they tend to have more functionality (which could have vulnerabilitites).

This isn't easy to make simple :-). Short answer: Yes, we should mention it, but not stress it too hard. Any suggestions on how to capture that idea?

[gkunz]

Ok, so reading the existing text again, I realize that the point I wanted to make is already included the subsequent sentence. In total the recommendation would thus read as:

Choose software that is a good solution for your problem, don't choose it merely because it's used by large companies or because it's the latest fad; avoid Hype Driven Development. However, widely used software is more likely to offer useful information on how to use it securely, and more people will care about its security. Check if a similar name is more popular - that could indicate a typosquatting attack.

That being said, aren't we actually talking about 2 different recommendations:

1. Choose software that is a good solution for your problem. Avoid Hype Driven Development: Don't choose it merely because it's used by large companies or because it's the latest fad.

2. Adoption: Widely used software is more likely to offer useful information on how to use it securely, and more people will care about its security.

[david-a-wheeler]

That's fair. Would you prefer to split this into 2 points?

[gkunz]

yes, I would prefer splitting this into 2. I'll be on (Easter) vacation this week, but I would take the task to propose an update once the restructuring PR has landed.