Skip to content

Security: robsonsmartins/usbflashprog

Security

SECURITY.md

usbflashprogUSB Flash/EPROM Programmer

A memory device programmer (Flash/EPROM/E2PROM) board and software, connected to PC by USB port.

Security Policy

This document defines the security policy, and how discovered vulnerabilities can be reported.

Supported Versions

This project maintains release versions. Applicable fixes, including security fixes, are performed only in these versions, depending on severity and feasibility.

Version Supported
1.0.0
< 1.0

Reporting a Vulnerability - Private Disclosure Process

Security is of the highest importance and all security vulnerabilities or suspected security vulnerabilities should be reported to us privately, to minimize attacks against current users of this project before they are fixed. Vulnerabilities will be investigated and patched on the next patch release as soon as possible. This information could be kept entirely internal to the project.

If you know of a publicly disclosed security vulnerability for this project, please IMMEDIATELY contact robson at robsonmartins dot com to inform the author.

IMPORTANT: Do not file public issues on GitHub for security vulnerabilities

To report a vulnerability or a security-related issue, please email the private address robson at robsonmartins dot com with the details of the vulnerability. The email will be fielded by us, which is made up of maintainers of this project who have committer and release permissions.

Do not report non-security-impacting bugs through this channel. Use GitHub issues instead.

Proposed Email Content

Provide a descriptive subject line and in the body of the email include the following information:

  • Basic identity information, such as your name and your affiliation or company.
  • Detailed steps to reproduce the vulnerability (POC scripts, screenshots, and compressed packet captures are all helpful to us).
  • Description of the effects of the vulnerability on this project and the related hardware and software configurations, so that us can reproduce it.
  • How the vulnerability affects this project usage and an estimation of the attack surface, if there is one.
  • List other projects or dependencies that were used in conjunction with this project to produce the vulnerability.

When to report a vulnerability

  • When you think this project has a potential security vulnerability.
  • When you suspect a potential vulnerability but you are unsure that it impacts this project.
  • When you know of or suspect a potential vulnerability on another project that is used by this project. For example, this project has a dependency on Raspberry Pi Pico C/C++ SDK, etc.

There aren’t any published security advisories