Skip to main content

Disclosure Policy

1. Purpose​

PunchCard Labs accepts good-faith vulnerability reports so security issues can be evaluated, coordinated, and communicated with restraint. This policy exists to establish a predictable intake path, reduce avoidable risk to users and vendors, and preserve trust between reporters, coordinators, and affected parties.

This policy does not authorize testing. It does not cure or approve prior conduct. It does not create a bug bounty program, legal defense, agency relationship, or right to publication.

2. Role of PCL​

PCL is an independent security research and coordination lab. Depending on the case, PCL may act as:

  • a reviewer of researcher-submitted material;
  • a coordinator between a reporter and an affected vendor;
  • a publisher of sanitized advisories or reports;
  • a maintainer of public templates, policy, local tools, and aggregate research data.

PCL is not the owner of third-party systems and cannot grant permission to test them. Authorization must come from the responsible system owner or another party with authority to grant it.

3. What PCL Accepts​

PCL may review reports that meet all of the following conditions:

  1. The reporter acted in good faith.
  2. The reporter had a lawful basis for the observation.
  3. The report does not require PCL to possess weaponized exploit code.
  4. The report does not depend on unauthorized data access.
  5. The report includes enough evidence to evaluate impact without further unsafe activity.
  6. The reporter is willing to coordinate disclosure responsibly.

Examples of generally acceptable material include:

  • passive observations of exposed security-relevant information;
  • vulnerabilities discovered during ordinary authorized use;
  • crash logs, trace summaries, or error messages obtained lawfully;
  • configuration or design flaws with clear security consequence;
  • authorized test results from a documented program scope;
  • vendor-confirmed vulnerabilities suitable for sanitized publication;
  • public-data analysis that identifies systemic defensive risk without targeting individual victims.

4. What PCL Rejects or Limits​

PCL may reject, decline to retain, or refuse to coordinate material involving:

  • exploit payloads or weaponized proof-of-concepts;
  • active exploitation of third-party systems without authorization;
  • denial-of-service activity;
  • credential theft, reuse, spraying, cracking, or stuffing;
  • access to another person’s account or private data;
  • bulk extraction of records;
  • malware, persistence, implants, or evasion;
  • social engineering or physical intrusion;
  • threats, coercion, extortion, bounty pressure, or public shaming;
  • reports submitted mainly to promote a product, service, or exploit;
  • findings that are purely speculative and unsupported by evidence;
  • low-quality automated scan output without validation or impact.

PCL may still preserve minimal intake metadata when needed to document why material was rejected or escalated.

5. Reporter Expectations​

Reporters should:

  • stop testing once a vulnerability or sensitive-data exposure is identified;
  • avoid accessing, copying, modifying, deleting, or disclosing data that is not theirs;
  • avoid service degradation and high-volume testing;
  • avoid privacy violations;
  • submit only the minimum evidence needed for review;
  • encrypt sensitive submissions;
  • disclose whether any third-party data was encountered;
  • identify the authorization basis for the discovery;
  • provide a reasonable coordination window before public disclosure;
  • avoid submitting high volumes of low-quality reports.

If sensitive data was encountered, the report should state that fact at a high level and avoid including the sensitive content unless PCL specifically asks for a minimized, encrypted, redacted sample.

6. Submission Channel​

Send security reports to security@pclsecurity.com.

Sensitive reports should be encrypted with the PGP public key published at /pgp/security.asc.

A complete submission should include:

  • reporter name or handle, if attribution or follow-up is desired;
  • contact method;
  • affected vendor, product, service, domain, component, or version;
  • authorization basis;
  • summary of the issue;
  • observed impact;
  • minimal reproduction context;
  • evidence list;
  • whether sensitive data was encountered;
  • actions already taken;
  • public disclosure status;
  • known deadlines, program rules, or legal constraints;
  • whether the reporter requests anonymity.

Anonymous reports are accepted when they contain enough information to evaluate the issue. Anonymous reporting may limit follow-up, coordination, attribution, or publication accuracy.

7. Intake Workflow​

PCL normally handles incoming reports through the following workflow.

7.1. Receipt​

PCL records the report, checks whether the submission is readable, and determines whether it contains material that should not be retained in ordinary case storage.

7.2. Authorization Screen​

PCL assesses whether the report describes a lawful or authorized observation. If authorization is unclear, PCL may request clarification or decline further handling.

7.3. Safety Screen​

PCL checks whether the report contains sensitive data, exploit material, active abuse evidence, or details that require immediate restriction.

7.4. Technical Triage​

PCL evaluates the technical claim, affected surface, reproducibility, severity, evidence quality, and likely remediation path using non-invasive methods where possible.

7.5. Coordination Decision​

PCL decides whether to coordinate with a vendor, refer to another coordinator, request more information, reject the report, or prepare a sanitized public artifact.

7.6. Publication Decision​

Publication is considered only after evidence review, coordination review, redaction review, and final release approval.

8. Evidence Standard​

PCL prefers evidence that is precise, minimal, and safe to retain. Useful evidence includes:

  • sanitized request and response metadata;
  • redacted screenshots;
  • version strings;
  • crash or stack summaries;
  • configuration excerpts with secrets removed;
  • logs with identifiers removed;
  • hash values or counts instead of raw records;
  • vendor references;
  • reproduction steps limited to authorized environments;
  • mitigation or patch references.

PCL does not need exploit chains, persistence mechanisms, shell access, credential dumps, private user records, or bulk data to understand most reports.

9. Coordination Model​

When PCL coordinates with an affected vendor or maintainer, PCL aims to:

  • provide a clear summary;
  • identify affected components;
  • provide minimized evidence;
  • separate confirmed facts from assumptions;
  • ask for validation, remediation status, and preferred publication timing;
  • avoid unnecessarily disclosing reporter identity;
  • preserve a record of communications;
  • keep the public advisory accurate and restrained.

PCL cannot guarantee that a vendor will respond, accept the report, remediate, issue a CVE, pay a bounty, or approve public credit.

10. Publication Timing​

PCL does not use a single rigid disclosure deadline for all cases. Timing depends on severity, evidence confidence, remediation availability, vendor responsiveness, user risk, exploitation status, legal constraints, multi-party coordination complexity, and public safety.

PCL may delay publication when additional time is likely to reduce user risk. PCL may accelerate publication when users face imminent harm, active exploitation is known, remediation is available, or a vendor has already disclosed the issue.

A publication decision should document the rationale.

11. Public Advisory Content​

A public advisory should normally include:

  • advisory identifier;
  • title;
  • affected vendor and product;
  • affected versions or conditions;
  • summary;
  • impact;
  • severity rationale;
  • remediation or mitigation;
  • coordination timeline;
  • credits, if approved;
  • references;
  • limitations and uncertainty.

A public advisory should not include unnecessary exploit mechanics, sensitive artifacts, private correspondence, unredacted data, or operational details that materially increase exploitation risk before remediation is broadly available.

12. Reporter Credit​

Reporter credit is discretionary. PCL may withhold or anonymize credit when:

  • the reporter requests anonymity;
  • the authorization basis is unclear;
  • the report involved policy violations;
  • credit would expose a minor or vulnerable person;
  • credit would reveal sensitive employment, contractual, or legal context;
  • a vendor or coordinator has a legitimate safety concern.

13. Compensation​

PCL does not operate a bug bounty program. Submission does not create entitlement to payment, reward, employment, access, public credit, advisory authorship, or continued engagement.

If a report is covered by a vendor’s bounty program, that program’s rules apply between the reporter and the vendor. PCL does not guarantee bounty eligibility.

14. Abuse, Escalation, and Refusal​

PCL may refuse or terminate engagement when a reporter:

  • threatens public disclosure to obtain money, access, employment, or acknowledgment;
  • continues unauthorized testing after being told to stop;
  • submits weaponized exploit material;
  • sends unnecessary sensitive data;
  • misrepresents identity, affiliation, or authorization;
  • harasses vendors, users, researchers, or PCL personnel;
  • attempts to use PCL as cover for unauthorized activity.

Where required or necessary to prevent harm, PCL may preserve records and notify affected parties, coordinators, platform operators, or appropriate authorities.

15. Changes​

PCL may revise this policy as its process, legal environment, or publication model changes. The current version applies to new submissions. Existing cases may be transitioned to a newer version when doing so improves clarity or safety.