Open luigigubello opened 1 year ago
Seems like this could be used to enhance the Security Policy check. There's already some work being done to that effect in #2195.
Looking at the spec and some examples, it seems like the vulnerability-reporting
is a required key, but not necessarily the security-policy
nested key. Are these the fields you had in mind?
In my opinion, there's a logical spot for where this logic could go. A simple check if there's a security insight file, and if a security policy field is defined inside that file.
strings.EqualFold(name, "SECURITY-INSIGHTS.yml") && containsSecurityPolicy(name)
At the moment, we just blindly trust the existence of a security.md
file. So I don't think this would change any behavior of the check, but rather just reduce false positives by recognizing another way of declaring a security policy. It probably makes sense to wait until #2195 gets finished, or incorporate it there to avoid conflicting changes.
Hi @spencerschrock, thanks for your comment (and my apologizes for my really sloooow response).
To give more context about SECURITY INSIGHTS and this "issue": this project is part of the OpenSSF Working Group "Identifying Security Threats" (#wg_identifying_security_threats, even if now I would like to move the discussions to #security_insights), and it was born from a question: how can we have something like security.txt
? (easy to read for humans and machines). Then, it evolved to collect more evidence regarding the information provided by the maintainers.
Looking at the spec and some examples, it seems like the vulnerability-reporting is a required key, but not necessarily the security-policy nested key. Are these the fields you had in mind?
At the moment, we just blindly trust the existence of a
security.md
file. So I don't think this would change any behavior of the check, but rather just reduce false positives by recognizing another way of declaring a security policy. It probably makes sense to wait until https://github.com/ossf/scorecard/pull/2195 gets finished, or incorporate it there to avoid conflicting changes.
Yes, the idea is to have enough data provided by maintainers to reduce false-positive of the scanners. Even if we cannot/don't want to trust all the information provided in SECURITY-INSIGHTS.yml, we can at least consider some info (the trust in SECURITY-INSIGHTS.yml should be the same as SECURITY.md because both are in the repo) to reduce false-positive or to provide more information to the final users:
Other interesting info for a scanner or a security researcher, could be:
For example, in SECURITY-INSIGHTS.md
it is mandatory to add security contacts and explicate if the maintainers/project accept security reports. If the project accepts security reports, a security contact and a security policy are required.
if:
properties:
accepts-vulnerability-reports:
const: true
then:
required:
- email-contact
- security-policy
required:
- accepts-vulnerability-reports
All this information could help scanners to reduce false-positive, and they can be aggregated easily in databases or other forms of well-ordered data. Now, humans can extrapolate this info by reading security.md
easily, but for machines and scanners, it is not so easy to scraper a text file like a security policy, SECURITY INSIGHTS could improve the situation.
It probably makes sense to wait until https://github.com/ossf/scorecard/pull/2195 gets finished, or incorporate it there to avoid conflicting changes.
Totally, and I think your comment points me in the right direction. Can I ask you if we can maintain this issue open? I could share updates regularly, the next step should be to try introducing this specification in the OpenSSF repos (at least in some repos), and see if it is good, or if we need to improve the schema.
And sorry again for my late response, unfortunately in the last weeks, I was not able to devote time to this project and work on it, thanks for the patience.
Stale issue message - this issue will be closed in 7 days
This issue is stale because it has been open for 60 days with no activity.
This issue has been marked stale because it has been open for 60 days with no activity.
The security baseline uses SECURITY_INSIGHTS.yml to get metadata of a project's security. Scorecard check will help with the baseline adoption, pointing maintainer to exactly what needs to be in place and how. The baseline is at the OpenSSF level, the goal is to evolve it for Linux Foundation wide adoption. https://github.com/ossf/tac/blob/a90b9838739ac18df43197fdd89f045c1a1e4dc3/process/project-lifecycle.md
Is your feature request related to a problem? Please describe. In the open-source ecosystem, developers can share the code on different platforms (GitHub, Bitbucket, self-hosted, etc), and they have various ways to communicate the same things related to security (e.g. how to report a vulnerability). SECURITY INSIGHTS could help the scorecard to reduce false-positive, by double-checking information on this file, if it is present, being independent on the project hosting platform. SECURITY INSIGHTS can help to offer a tool that supports other platforms (not just GitHub, see issue #40), improving the quality of information, and reducing potential false-positive (tweet).
Describe the solution you'd like SECURITY INSIGHTS is a YAML file that developers can add to their repository, and it contains valuable security-friendly information, that can help contributors, security researchers, and developers to contribute to the project. Hosting platforms have different APIs and features, so this file could be used to reduce false-positive or to get information for every project, not just projects hosted on Github.
Additional context See the slides presented to the CNCF Tag group. GitHub repo: https://github.com/ossf/security-insights-spec
Thanks :rainbow: