search

ossf / package-analysis

Open Source Package Analysis
Apache License 2.0
730 stars 51 forks source link

SECURITY-INSIGHTS.yml implementation #460

Open luigigubello opened 1 year ago

luigigubello commented 1 year ago

Hi :wave: as a project in the working group "Identifying Security Threats", we are working on the SECURITY-INSIGHTS.yml specification. SECURITY INSIGHTS would like to provide information regarding security posture and practices in place in an open-source project in both human-readable and machine-readable format (YAML). The original idea was to create something like security.txt, but containing more information and evidence. In the last months, we collected feedback from OpenSSF Slack channels and the community (Twitter), and now we have a first version that should be enough mature to be used. We would like to introduce this specification in some of the OpenSSF repositories (list at the bottom) to see how the community welcomes this news and how we can improve the specification. So, could we introduce SECURITY-INSIGHTS.yml in this repo? I can proceed to fill out the YAML (here is a sample) and prepare a PR by asking you for a review. Introducing this specification in the repo of OpenSSF might help to spread it into the community.

Repos where would be nice to introduce SECURITY-INSIGHTS.yml :

Let me know :)

calebbrown commented 1 year ago

I'm generally not opposed to this idea, but I do wonder about the practicality of tracking project-release, commit-hash (for the project) and tool-version (for security tools).

How are devs expected to keep these in sync with reality? What does it mean if the information is stale?

luigigubello commented 1 year ago

How are devs expected to keep these in sync with reality? What does it mean if the information is stale?

They don't need. In the SECURITY-INGHTS.yml schema, there is the key expiration-date which should be at most a year later than the key last-reviewed (date). In the schema, there are the following keys:

  1. last-update: date of the last time that the SECURITY-INSIGHTS.yml was updated, excluding the properties commit-hash and last-reviewed (e.g. the security policy link has changed over time).
  2. last-reviewed: the date of the last time the SECURITY-INSIGHTS.yml was reviewed. Updating this property could require updating the property commit-hash. The number of reviews per year is arbitrary, but it is highly recommended 1 review per year, even if there are no particular changes.
  3. expiration-date: expiration date for the SECURITY-INSIGHTS.yml. At most a year later the last-reviewed date. After a review, the expiration date can be updated (this is based on the security.txt approach).
  4. commit-hash: the commit helps readers to know respect to which commit (moment) the SECURITY-INSIGHTS has filled out. This detail can be helpful in case of hacks or incidents, because before that specific commit at least one maintainer has made a review of the SECURITY-INSIGHTS (and ideally they have confirmed some security standards in place).
  5. project-release: as above, but less precise, but more user-friendly.
  6. tool-version: in combination with the commit-hash, it can be helpful because if the used tool is open source (or accessible), if the used tool configuration is public, accessible, or just replicable, everyone should be able to get the same output from the tool on that specific commit (e.g. fuzzing tests). This helps to make SECURITY-INSIGHTS, and so the project, more trustable.

So maintainers don't need to update the file for every edit that they do, maintaining SECURITY-INSIGHTS aligned with the current situation and standards of a project helps, but a review/update per year can be enough, especially for small projects. This specification should help the community to know security posture and communication channels in the first place.

I should write a FAQs doc, I will work on it :) thanks for the questions 🙌

luigigubello commented 1 year ago

I'm generally not opposed to this idea

And if it is okay for you and other maintainers, I can prepare the PR for this repo, and ask for a review :)

maxfisher-g commented 1 year ago

Hi Luigi, yes we're happy for you to prepare a PR for us to review