Support for SECURITY INSIGHTS

[luigigubello]

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 🌈

[spencerschrock]

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.

[luigigubello]

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 #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:

1. Is this project accepting vulnerability reports? (I know, quite sure everyone should accept vulnerability reports, but maybe not)
2. If so, what is the security contact? And the security policy?

Other interesting info for a scanner or a security researcher, could be:

3. What are the official distribution points? (this could help to reduce typo-squatting risks, it is not so uncommon that persons not related to a project share the project on various distribution channels, e.g. Snap)
4. Has this project been tested/analyzed by an independent third-party authority? (critical open-source projects pay third-party companies for vulnerability assessments or PT, but we don't have a canonical way to share these reports, which are - should be - definitely highly trustable)
5. Is this project using third-party packages? Does this project have SBOM files? (SBOM seems to be the right way, but it is not still so popular in no-enterprise projects and the projects that have an SBOM file share it in various locations)
6. Does this project have a public bug bounty program? (this is information that independent security researchers could find interesting)
7. Does this project accept pull-requests generated by bots or automated tools? (it is normal to automate tests, but scanners could generate a lot of noise and false-positive, and this could be frustrating for maintainers)

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 #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.

[github-actions]

Stale issue message - this issue will be closed in 7 days

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[github-actions]

This issue has been marked stale because it has been open for 60 days with no activity.

[Danajoyluck]

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