Proposal: Expanding Security Benchmarks for Critical OSS in OpenSSF

[fredgan]

Hi everyone,

I've recently noticed a proliferation of security parameter/configuration specifications within our company, such as the "Redis security configuration baseline."

Upon reviewing these specifications, I discovered many rules originate from the CIS Benchmark (https://www.cisecurity.org/cis-benchmarks), which offers valuable benchmarks for various OSS projects like Docker, Kubernetes, MongoDB, and Nginx.

However, there's a concerning gap in coverage for critical OSS projects like Spring Boot, Beego, Jenkins, Etcd, and Zookeeper.

Proposal:

I propose establishing a Working Group (WG) within OpenSSF to develop security configuration benchmarks for these currently unsupported critical OSS projects.

Benefits:

Standardized security baselines for essential OSS components.
Reduced burden on individual companies for creating their own specifications.
Improved overall security posture across the industry.
I believe this initiative would significantly benefit companies and individuals by providing a centralized resource for robust security configurations.

Thank you for your time and consideration.

[SecurityCRob]

@fredgan would you be able to join us on the next TAC call on 23July2024 to discuss your proposal?

[fredgan]

OK，I will. Thanks for your inviting. @SecurityCRob

[sevansdell]

Thank you for presenting today. I'd like to get you scheduled to speak to the OpenSSF Project Alpha/Omega. @scovetta, @bobcallaway. Is working with the ecosystem to get CIS benchmarks (or something similar in security audits) something that already exists/could be added to Alpha / Omega? If not, want to understand why not, and help Fred find a place to land this work in OpenSSF.

[david-a-wheeler]

The OpenSSF Securing Critical Projects Working Group has a Set of Critical Open Source Projects version 1.1, which uses a set of data sources including the Harvard "Census II" study. That might be a reasonable place to look for critical OSS.

There are several different configurations to consider:

1. Build-time
2. As released
3. As used in the field by widely-used systems

The challenge will be ensuring that the configurations are evaluated by those who understand the projects well, and that these improved configurations become widely used (e.g., because they're the default).

Instead of independently releasing configurations, maybe these should work with the key projects to ensure that these projects' documentation & default configurations are more secure, however the project releases them. Then we don't have to try to redirect people to the OpenSSF - they'll just get the better configuration. Anyway, that might be one way to proceed.