Skip to content

Security: Nagi-Inaba/information-accessibility-skill

SECURITY.md

Security Policy

Supported versions

Security fixes target the current main branch and the latest published release. Older development commits do not receive separate backports. The first published version is the v0.1.0 prerelease; identify installations by their full source commit, not by the package version alone. See supported versions and migration.

Reporting a vulnerability

Do not publish exploit details, credentials, private audit artifacts, local paths, or target-specific evidence in a public issue.

Use Report a vulnerability to send a private report to the repository maintainers. Private vulnerability reporting is enabled and requires GitHub sign-in. If the route is unavailable, open a public issue asking only for a private contact channel; do not include the affected target, exploit, credentials or evidence. No maintainer email address should be inferred from Git history.

For ordinary non-sensitive defects, use the bug report form with synthetic data. GitHub's private reporting guide explains the reporting flow.

Please include:

  • affected version or commit;
  • affected command, script, or artifact type;
  • reproduction steps using synthetic data where possible;
  • expected and actual behavior;
  • security impact and relevant trust boundary.

The maintainers will acknowledge and triage reports as capacity permits; no guaranteed response time or bounty is offered. Coordinate disclosure privately until a fix or mitigation is available. Report receipt, a proposed patch, and a published fix are separate states.

Scope includes network restrictions, filesystem confinement, private evidence redaction, artifact integrity, authorization/fixer boundaries and reviewer/bundle verification. A correct signature authenticates a signed record under the selected trust policy; it does not establish the truth of its accessibility conclusions.

There aren't any published security advisories