Evaluate GUAC against Open Source Project Security Baseline

[funnelfiasco]

The OSPS Baseline is a new OpenSSF project to define a level of security for open source projects. We should first evaluate the GUAC repo against it to see where we land. Then we can look at how this information might be used within GUAC.

OSPS Baseline checklist, version: 2025-02-25

Level 1

• OSPS-AC-01.01: When a user attempts to access a sensitive resource in the project's version control system, the system MUST require the user to complete a multi-factor authentication process.
• OSPS-AC-02.01: When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default.
• OSPS-AC-03.01: When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied.
• OSPS-AC-03.02: When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent.
• OSPS-BR-01.01: When a CI/CD pipeline accepts an input parameter, that parameter MUST be sanitized and validated prior to use in the pipeline.
• OSPS-BR-03.01: When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels.
• OSPS-DO-01.01: When the project has made a release, the project documentation MUST include user guides for all basic functionality.
• OSPS-DO-02.01: When the project has made a release, the project documentation MUST include a guide for reporting defects.
• OSPS-GV-02.01: While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.
• OSPS-GV-03.01: While active, the project documentation MUST include an explanation of the contribution process.
• OSPS-LE-02.01: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
• OSPS-LE-02.02: While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
• OSPS-LE-03.01: While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory.
• OSPS-LE-03.02: While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets.
• OSPS-QA-01.01: While active, the project's source code repository MUST be publicly readable at a static URL.
• OSPS-QA-01.02: The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made.
• OSPS-QA-02.01: When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies.
• OSPS-QA-04.01: While active, the project documentation MUST contain a list of any codebases that are considered subprojects or additional repositories.
• OSPS-QA-05.01: While active, the version control system MUST NOT contain generated executable artifacts.
• OSPS-VM-02.01: While active, the project documentation MUST contain security contacts.

Level 2

• OSPS-AC-04.01: When a CI/CD task is executed with no permissions specified, the project's version control system MUST default to the lowest available permissions for all activities in the pipeline.
• OSPS-BR-02.01: When an official release is created, that release MUST be assigned a unique version identifier.
• OSPS-BR-04.01: When an official release is created, that release MUST contain a descriptive log of functional and security modifications.
• OSPS-BR-05.01: When a build and release pipeline ingests dependencies, it MUST use standardized tooling where available.
• OSPS-BR-06.01: When an official release is created, that release MUST be signed or accounted for in a signed manifest including each asset's cryptographic hashes.
• OSPS-DO-06.01: When the project has made a release, the project documentation MUST include a description of how the project selects, obtains, and tracks its dependencies.
• OSPS-GV-01.01: While active, the project documentation MUST include a list of project members with access to sensitive resources.
• OSPS-GV-01.02: While active, the project documentation MUST include descriptions of the roles and responsibilities for members of the project.
• OSPS-GV-03.02: While active, the project documentation MUST include a guide for code contributors that includes requirements for acceptable contributions.
• OSPS-LE-01.01: While active, the version control system MUST require all code contributors to assert that they are legally authorized to make the associated contributions on every commit.
• OSPS-QA-03.01: When a commit is made to the primary branch, any automated status checks for commits MUST pass or be manually bypassed.
• OSPS-QA-06.01: Prior to a commit being accepted, the project's CI/CD pipelines MUST run at least one automated test suite to ensure the changes meet expectations.
• OSPS-SA-01.01: When the project has made a release, the project documentation MUST include design documentation demonstrating all actions and actors within the system.
• OSPS-SA-02.01: When the project has made a release, the project documentation MUST include descriptions of all external software interfaces of the released software assets.
• OSPS-SA-03.01: When the project has made a release, the project MUST perform a security assessment to understand the most likely and impactful potential security problems that could occur within the software.
• OSPS-VM-01.01: While active, the project documentation MUST include a policy for coordinated vulnerability reporting, with a clear timeframe for response.
• OSPS-VM-03.01: While active, the project documentation MUST provide a means for reporting security vulnerabilities privately to the security contacts within the project.
• OSPS-VM-04.01: While active, the project documentation MUST publicly publish data about discovered vulnerabilities.

(Edited to remove Level 3, since we are not currently targeting that)

[funnelfiasco]

Someone can assign this to me for handling the first part. @eddie-knight is working on tooling that will run in a CI job.

[funnelfiasco]

The following have been auto-evaluated by LFX:

• OSPS-AC-01.01
• OSPS-AC-03.02
• OSPS-BR-01.01
• OSPS-GV-02.01
• OSPS-LE-03.02
• OSPS-LE-03.01
• OSPS-QA-01.02
• OSPS-QA-01.01
• OSPS-QA-02.01

[funnelfiasco]

Manually verified by me (with notes where applicable)

Level 1

• OSPS-AC-02.01 — This is how GitHub works.
• OSPS-AC-03.01
• OSPS-BR-03.01
• OSPS-DO-01.01 — Basic functionality is at docs.guac.sh
• OSPS-DO-02.01
• OSPS-GV-03.01 — Documented at https://guac.sh/contributing/
• OSPS-LE-02.01
• OSPS-LE-02.02
• OSPS-QA-05.01
• OSPS-VM-02.01 — Security contacts are in the GUAC readme

Level 2

• OSPS-AC-04.01 — This is how GitHub works
• OSPS-BR-02.01
• OSPS-BR-04.01
• OSPS-BR-05.01
• OSPS-BR-06.01
• OSPS-GV-01.01 — Documented in the contributor ladder
• OSPS-GV-01.02 — Documented in the contributor ladder
• OSPS-LE-01.01
• OSPS-QA-03.01
• OSPS-QA-06.01
• OSPS-VM-03.01
• OSPS-VM-04.01

[funnelfiasco]

Open questions:

• OSPS-QA-04.01 — Do the areas in the contributor ladder count? Notably, it doesn't include sw-id-core. On the other hand, the listing at https://github.com/orgs/guacsec/repositories?type=all could be understood to satisfy this requirement.
• OSPS-DO-06.01 — I'm pretty sure we don't have this documented anywhere.
• OSPS-GV-03.02 — Arguably, we don't have descriptive enough requirements for code contributions (e.g. style)
• OSPS-SA-01.01 — Do we feel like our current docs explain this well enough?
• OSPS-SA-02.01 — I don't think we have this documented anywhere
• OSPS-VM-01.01 — We have security contacts, but no CVD process

[jeffmendoza]

RE: OSPS-QA-04.01

I think we should/can document that the project consists of all repos in the guacsec org. If we end up doing a "contrib" repo or similar, we can list that as an exception.