Skip to content

Add DO-01.02 disclaimer requirement #356

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add DO-01.02 disclaimer requirement #356

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
docs/versions/devel.md
docs/versions/devel-checklist.md
.DS_Store

# generated output from go run ./... compile
Expand Down
9 changes: 6 additions & 3 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,17 @@

## Contributing to the Controls:

Currently, all the baseline controls are in `baseline.yaml`; follow the structure
[in the README](./README.md#baseline-structure) when proposing new entries.
Currently, all the baseline controls are in [`baseline/OSPS-$FAMILY.yaml`](./baseline/);
follow the structure [in the README](./README.md#baseline-structure) when proposing
new entries.

## Contributing to the Tooling:

The baseline is published to https://baseline.openssf.org/ (via GitHub Pages) via
Jekyll (a static site generator) using scripts from `./cmd` and formatting from
`./docs`, using GitHub Actions.
`./docs`, using [GitHub Actions](./.github/workflows/web-publish.yml). Changes
to the baseline will be published to the `devel` version until a new version is
[explicitly published](./docs/maintenance.md#osps-baseline-maintenance-process).

## PR guidelines

Expand Down
14 changes: 14 additions & 0 deletions baseline/OSPS-DO.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,20 @@ controls:
project, explaining how to install, configure, and use the project's
features. If there are any known dangerous or destructive actions
available, include highly-visible warnings.
- id: OSPS-DO-01.02
text: |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

If the project is designed only for use in non-sensitive contexts, the
project MUST indicate these restrictions in prominently alongside
usage instructions.
applicability:
- Maturity Level 2
- Maturity Level 3
recommendation: |
Some projects may not be designed or intended for use in
security-sensitive contexts (for example, when dealing with untrusted
inputs or privacy-sensitive data). To prevent accidental misuse,
a prominent disclaimer should be included alongside usage
documentation.

- id: OSPS-DO-02
title: |
Expand Down
Loading