Skip to content

Latest commit

 

History

History
100 lines (75 loc) · 6.9 KB

SECURITY.md

File metadata and controls

100 lines (75 loc) · 6.9 KB
Raw

Security Policy

Reporting a Vulnerability

To report a security issue, please email [email protected] with a description of the issue, steps required to reproduce the issue, affected versions and, if known, mitigations for the issue.

Our contributors are comprised of volunteers so we cannot guarantee a specific response time, but someone from our team will reply and address the issue as soon as possible.

Security Review

We perform regular reviews inline with the information provided below. All releases go through these reviews but multiple people in the project team prior to release as part of our quality and security review.

Basics

Basic Project Website Content

FLOSS license

Documentation

Other

Change control

Public VCS repo

Unique versioning numbering

Release notes

Reporting

Bug reporting process

Vulnerability report process

  • Have a vulnerability report process - ✅ Included in CONTRIBUTING.md
  • Private vulnerability if supported must include info how to send - ✅ N/A (allowed) - no private vulnerability reporting set up but proposed
  • Initial response time for vulnerability submitted in last 6 months must be <= 14 days - ✅ N/A (allowed) - no vulnerabilities have yet been reported. Response times for bugs and other issues have been <14 days, post-graduation development will be by volunteers and open source developer community, so we can't guarantee a time to resolution.

Quality

Working build system

  • Must provide a working build system - ✅ IF is a locally running NodeJS app. We do provide a devcontainer for eays environment setup. Installation is simply achieved using npm i @grnsft/if.

Automated test suite

  • Have at least one automated test suite and documentation how to run it - ✅ We have a comprehensive set of unit tests and a library of becnhmark manifest files that act as integration tests. These can be run locally, and they are executed as part of our CI/CD on any PRs into main.

New functionaility testing

  • Formal/informal policy for adding tests for new features - ✅ Test suite in CI/CD checks for breaking changes in PRs. Any new feature must include unit tests and an example manifest that demonstrates usage.
  • Evidence of policy being adhered to - ✅

Warning flags

Security

Secure development knowledge

  • At least one primary developer who knows how to design secure software - ✅ Manushak and Narek are both primary developers and have broad experience.
  • At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them - ✅

Use basic good cryptographic practices

Secured delivery against man-in-the-middle (MITM) attacks

  • Delivery mechanisms that counters MITM - ✅ n/a
  • Cyrptographic hash NOT retrived over HTTP - ✅ n/a

Publicly known vulnerabilities fixed

  • No unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 day - ✅ no such vulnerabilities

Other security issues

  • Public repo doesnt leak private credential - ✅ does not do that.

Analysis

Static code analysis

  • At least one FLOSS static code analysis tool - ✅ CodeQL is integrated into our CI/CD.
  • All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed - ✅ We have not yet had any exploitable vulnerabilities reported, but the GSF team will respond promptly to any disclosed issues.

Dynamic code analysis

  • All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. - ✅ We have not yet had any exploitable vulnerabilities reported, but the GSF team will respond promptly to any disclosed issues.