Skip to content

Security: aminhanifm/IssueSafe

Security

SECURITY.md

Security policy

Supported versions

Security fixes are provided for the latest released version. Before the first npm release, fixes land on main.

Version Supported
main / latest Yes
Older releases No

Threat model

IssueSafe assumes a user has a text log that may contain sensitive values and wants to inspect a sanitized copy before sharing it. The browser application processes that text in the current page's memory. It has no backend, authentication, analytics, cloud storage, database, external API, or runtime network request. The CLI reads only the input selected by its caller.

The engine keeps original matched values only long enough to assign stable placeholders during one synchronous analysis. Public results contain offsets, locations, categories, detector IDs, placeholders, decisions, and sanitized text; they do not contain a matched-value field. The mapping is not persisted or exported.

Security-relevant invariants include:

  • complete private-key blocks take precedence over findings inside them;
  • more specific candidates win overlaps before replacements are applied;
  • replacements are non-overlapping and deterministic;
  • Markdown fences are longer than any backtick run in the sanitized log;
  • browser input is rendered with React text nodes, never innerHTML;
  • output files are not overwritten unless --force is explicit;
  • errors do not quote input content.

Non-goals

IssueSafe does not guarantee detection of every secret or identifier. It is not a compliance control, malware sandbox, DLP system, repository scanner, Gitleaks replacement, secret-rotation service, or proof that a document is safe. It does not inspect binary files, archives, browser storage from other applications, remote services, or source history.

False positives and false negatives are expected. Users must review output. Credentials that may have been exposed must be revoked or rotated, not merely removed from a report.

Safe fixtures

Never submit a real credential, private key, cookie, personal log, customer identifier, or production URL in an issue, test, reproduction, screenshot, or pull request. Use:

  • example.invalid hostnames;
  • RFC documentation IP ranges such as 192.0.2.0/24 and 2001:db8::/32;
  • obviously synthetic labels such as fake_, synthetic_, or placeholder_only;
  • the smallest structure needed to demonstrate the bug.

Private-key detector tests must assert on a synthetic marker and must not print block contents in snapshots or failure messages.

Reporting a vulnerability

Do not open a public issue. Use GitHub private vulnerability reporting and include:

  • the affected version or commit;
  • impact and realistic attack conditions;
  • a minimal reproduction containing only synthetic values;
  • suggested mitigation, if known.

You should receive an acknowledgment within seven days. Please allow time for a fix and coordinated disclosure.

There aren't any published security advisories