Add DO-01.02 disclaimer requirement

[evankanderson]

Fixes #353

Given that this is attempting to disprove a negative (the software is NOT intended for general use), I'm not sure how we can automatically validate this.

An example of software that might be flagged by this would be https://github.com/sloria/doitlive -- given that this is running an arbitrary shell script, there should probably be a disclaimer to _trust_ the shell script you're running it with (reasonable, but might not be obvious given the propensity of curl | bash - installs...).

[eddie-knight]

@trumant 🤔 This might be a reasonable field to add to security insights.

[trumant]

The underlying intent here seems to have some parallels with CISA's Secure by Design guidance in the "Reduce hardening guide size" section of https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf

Specifically, I think we could improve this by changing the text to something like:

Suggested change

	text: |
	text: |
	The project documentation MUST include guidance on secure usage of the project.
	applicability:
	- Maturity Level 2
	- Maturity Level 3
	recommendation: |
	Document the security-relevant usage and configuration options of the project clearly in a hardening or security guide that is prominently noted in the installation or usage documentation.

Examples of such guidance documents:

• https://v2.helm.sh/docs/securing_installation/
• https://theupdateframework.io/docs/security/
• https://www.openpolicyagent.org/docs/security

WDYT?

[trumant]

From the Secure by Design guidance:

Track and reduce “hardening guide” size. Reduce the size of “hardening guides”
that are included with products and strive to ensure that the size shrinks over time as
new versions of the sofware are released Integrate components of the “hardening
guide” as the default configuration of the product The authoring organizations
CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NL
NCSC-NO | NÚKIB | INCD | KISA | NISC-JP | JPCERT/CC | CSA | CSIRTAMERICAS recognize that shortened hardening guides result from ongoing partnership with existing customers and include eforts by many product teams, including user experience (UX)

• Consider the user experience consequences of security setings. Each new seting
increases the cognitive burden on end users and should be assessed in conjunction
with the business benefit it derives Ideally, a seting should not exist; instead, the most
secure seting should be integrated into the product by default When configuration is
necessary, the default option should be broadly secure against common threats

[eddie-knight]

I think these are good thoughts, but potentially additive.

I think the intent is to signal to users that the project outputs are not ready for sensitive environments.

My thought was that we could have a boolean field in security insights, and potentially extend that check with a scan for boilerplate text in the README.

Although if my understanding is correct, @evankanderson, I'd be curious to see a recent example of this in practice.

[funnelfiasco]

Marking "request changes" because of the .gitignore and CONTRIBUTING.md changes in this PR.

As for the substance, I'm not fully sure how I feel about this. "Designed only for use in non-sensitive contexts" is, I'd argue, the default state, so I don't like the idea of obligating 90% (made up number) of projects to include a statement to that effect. I'm also not sure I have an idea of how we could flip it around. Maybe we're trying too hard here and the actual thing we're asking for is something along the lines of "When the project has made a release, the project documentation MUST include a list of supported use cases" or something along those lines?

[funnelfiasco]

This and CONTRIBUTING.md changes should be in a separate PR for clarity (although they are both good changes!)