Skip to content

Security: lumiboi/plimsoll

Security

SECURITY.md

Security

Reporting a vulnerability in plimsoll

Use GitHub's private vulnerability reporting on this repository: Security → Report a vulnerability. That opens a private advisory visible only to the maintainers.

There is no dedicated security mailbox for this project. If private reporting is unavailable to you, open a normal issue that describes the problem without a working payload and ask for a private channel.

What is in scope for this repository: the CLI and library (schema validation, canonicalization, canary handling, scoring), the corpus and fixtures, and the skill instructions. A plausible report explains what an attacker gains — for example, a canary that plimsoll canary scan fails to catch, a redaction path that leaks a value into a report, or corpus content that would cause an agent to act outside a sandbox.

Expect an acknowledgement within a week. Please give us a reasonable window before publishing.

Using plimsoll against a target

Test only systems you are authorized to test. The target file requires an authorization block naming who authorized the work and what is in scope; it is a prompt for that conversation, not a substitute for having it.

Do not point the corpus at a third-party product, a hosted assistant you do not own, or a shared workspace belonging to someone else. "It was only a prompt" is not a defense, and neither is "the tool told me to".

Defaults to keep:

  • Run against local, sandbox or staging instances. Reproduce production findings elsewhere; plimsoll evaluate warns when a target declares production.
  • Mock the high-risk tools. A message in an SMTP sink proves the path as well as a message in someone's inbox and creates no incident.
  • Use synthetic secrets and synthetic data. plimsoll canary new produces values that are obviously fake and unique per run.
  • Stop escalating once a finding is demonstrated. The smallest harmless action that validates it is the right one.
  • Never chain a finding into persistence, lateral movement, destructive writes, privilege escalation on real infrastructure, or real financial transactions.

Handling real secrets

If a review turns up a real credential — in a system prompt, a log, a repository — stop testing that path and treat it as an incident: report it through the owner's process, get it rotated, and record only a redacted fingerprint.

Never paste a real credential into a target file, a corpus case, a fixture, an issue or a report. plimsoll.canaries.redact strips canaries and credential-shaped strings from anything the report writer emits, and detect_real_secrets returns a hash prefix rather than the value, but neither is a reason to have the secret in hand in the first place.

Generated reports may quote excerpts of a target's context; reports/ is ignored by git for that reason. Review before sharing.

Content of this repository

The corpus contains adversarial text. It is written to test boundaries, not to produce harmful content: payloads ask for configuration blocks and mock sends, addresses use the reserved .invalid suffix, and secrets are synthetic. If you add a case, keep it that way.

There aren't any published security advisories