Skip to content

Security: oxbshw/Open-Workflow-Library

Security

SECURITY.md

Security Policy

This file describes how to report security issues for Open Workflow Library and what guarantees this project makes (and does not make).

Reporting a vulnerability

Do not open a public GitHub issue if your report contains a secret value, a working exploit, or any other content that a public attacker could weaponise.

Preferred reporting paths, in order:

  1. GitHub private vulnerability reporting — if the maintainer has enabled it for this repository, use the "Report a vulnerability" button on the Security tab. This keeps the report private and tied to the repository.
  2. Contact the repository owner via their GitHub profile. Open a minimal placeholder issue (e.g. "Security: I need a private contact channel") that contains no sensitive content and asks the maintainer to follow up off-platform.

If neither option is available, redact the sensitive value before including any logs or repro steps in any public communication.

This project does not currently publish a security contact email. Do not assume one exists.

Leaked credentials

If you believe a credential was committed to this repository, even historically:

  1. Assume it is public and rotate it immediately.
  2. Open a private vulnerability report (see above) with the affected file path and a short description — do not paste the credential value.
  3. Wait for the maintainer to confirm receipt before opening any public discussion.

The audit tool (tools/audit_workflows.py) redacts every match against its secret patterns before anything is written to any report file in this repository. Matches are replaced with [REDACTED]. The current repository state reports 0 possibleSecretFindings.

Disclosure expectations

This project is maintained on a best-effort basis. There is no SLA on acknowledgement, triage, or fix timing. Reporters are encouraged to allow a reasonable window — typically 30 days — between report and any public disclosure.

If you intend to publish a write-up, please coordinate with the maintainer so a fix can land first.

Known safety boundaries

This project is an open-source library of workflow templates and maintainer tooling. The following items are explicitly out of scope and must not be assumed:

  • Production certification.
  • Regulatory compliance (HIPAA, SOC 2, GDPR, PCI DSS, etc.).
  • Clinical, legal, or financial advice. Workflows tagged for healthcare, homecare, legal, finance, or security domains support administrative operations only.
  • Behavioural validation. No workflow in this repository has been imported into n8n or any other framework by the maintainer tooling. Static validation is the only validation this repository performs.
  • Autonomous self-improvement. Repair proposals are emitted but never applied; learning events are recorded but never promoted into the curated wiki automatically.

If you are deploying a workflow from this library, you are responsible for:

  • Replacing every placeholder credential and host with values that fit your environment.
  • Adding authentication and idempotency guarantees on webhook ingress.
  • Capping input sizes on code nodes.
  • Performing your own behavioural testing in a sandbox before connecting any real integration.
  • Meeting any regulatory obligations that apply to your operation.

Workflow template safety

Every workflow under workflows/ and workflows/generated/ is a starting point, not a certified system:

  • Placeholder credentials and placeholder URLs only.
  • Sticky-note safety disclaimers are present on generated outputs.
  • active is false by default on generated n8n workflows.
  • Code nodes are flagged by the static validator for explicit human review.
  • The static validator rejects credential-like fields with non-placeholder values and refuses HTTP hosts outside a documented safe allow-list.

These properties make the templates safer to redistribute. They do not make them safe to deploy without review.

Responsible disclosure

The maintainer commits to acknowledging good-faith reports, fixing high-impact issues as resources permit, and crediting reporters who request credit. The maintainer reserves the right to decline credit or ask for redaction when a credit line would itself expose sensitive information.

There aren't any published security advisories