Research Methodology

1. Research Standard

PCL research should be technically precise, evidence-backed, and safe to publish. The method must distinguish what was observed, what was inferred, what was reproduced, and what remains unverified.

The public reader should be able to understand risk and remediation without receiving unnecessary operational detail.

2. Method Phases

2.1. Question Framing

Define the research question before collecting evidence.

Good questions are bounded:

• Does this product expose sensitive information under ordinary use?
• Does this configuration create cross-tenant risk?
• Does this crash indicate a memory-safety defect?
• Does this disclosure pattern affect multiple products?

Poor questions are open-ended or offensive:

• How far can this be exploited?
• Can we get shell?
• How many records can be pulled?
• Can this be chained into a full compromise?

2.2. Authorization Mapping

Record the authorization basis before analysis:

• personal device or lab environment;
• vendor-provided test environment;
• bug bounty scope;
• contract scope;
• open-source local reproduction;
• ordinary authorized user account;
• passive public-source analysis.

If the authorization basis cannot be stated clearly, the work should not proceed under PCL.

2.3. Evidence Plan

Before collecting evidence, decide the minimum proof needed. Prefer evidence that validates consequence without increasing target interaction.

Evidence should answer:

• what happened;
• where it happened;
• why it matters;
• whether it is repeatable;
• whether sensitive data was encountered;
• whether the affected party can verify it.

2.4. Validation

Validation may include:

• local reproduction;
• code review of lawfully available source;
• comparison with vendor documentation;
• deterministic logs;
• crash analysis;
• public version metadata;
• controlled test-account comparison;
• vendor confirmation.

Validation must not require unauthorized access, data exfiltration, persistence, or live exploitation.

2.5. Impact Analysis

Impact should be written as consequence, not theatrics.

Prefer:

An authenticated user can retrieve another tenant’s invoice metadata under condition X.

Avoid:

This completely destroys the platform and lets anyone own everything.

Impact should include prerequisites, affected users, likely attacker position, affected security properties, and uncertainty.

2.6. Remediation Analysis

When possible, state practical remediation or mitigation:

• patch version;
• configuration change;
• access-control correction;
• rotation requirement;
• detection logic;
• workaround;
• monitoring recommendation;
• vendor advisory reference.

If remediation is unknown, say so.

2.7. Publication Review

Before publication, review the artifact for:

• evidence provenance;
• authorization boundaries;
• sensitive-data exposure;
• exploitability of details;
• severity accuracy;
• remediation status;
• vendor awareness;
• link stability;
• metadata completeness.

3. Evidence Hierarchy

Prefer evidence in this order:

1. vendor-confirmed remediation or advisory;
2. deterministic local reproduction in an authorized environment;
3. redacted logs or traces;
4. controlled test-account observations;
5. screenshots with sensitive data removed;
6. public records;
7. synthetic examples;
8. reasoned inference clearly marked as inference.

Avoid relying on single screenshots, unverifiable anecdotes, scanner output without validation, or claims that require trust in the researcher’s intent.

4. Reproducibility without Weaponization

A report should be reproducible enough for an authorized defender, vendor, or maintainer to validate. It should not necessarily be reproducible by any unauthenticated public reader against live systems.

Use one of the following detail levels:

Level	Use case	Public detail
Summary	Active exploitation or no patch	high-level conditions and mitigation
Defensive	Patch available or vendor-approved	affected component, conditions, safe evidence
Technical	Low abuse risk or local-only issue	deeper mechanics without payloads
Full	Training/lab/synthetic artifact	complete reproduction in a controlled non-production setting

5. Severity Inputs

PCL severity analysis may consider:

• affected security properties;
• attacker prerequisites;
• attack complexity;
• required privileges;
• user interaction;
• exposure surface;
• affected population;
• safety or operational impact;
• availability of remediation;
• active exploitation;
• public exploit availability;
• CVSS vector and score;
• EPSS probability;
• CISA KEV status;
• vendor severity;
• asset criticality;
• confidence level.

Do not treat any single score as the whole risk decision.

6. Language Standard

Use restrained language:

• write what is known;
• mark assumptions;
• avoid adversarial hype;
• avoid moral judgment about vendors;
• avoid exploit-bragging language;
• avoid unsupported “critical” or “severe” labels;
• use dates instead of vague timing;
• separate facts from recommendations.

7. AI-Assisted Research

AI tools may support drafting, summarization, code review, or consistency checks only when sensitive material is excluded or the tool is approved for that data class.

AI-generated analysis must be verified by a qualified reviewer. Do not publish AI-generated claims, CVSS vectors, affected-version ranges, or remediation guidance without independent validation.

8. Negative Results

A finding is not ready merely because an issue was suspected. PCL may publish negative or inconclusive analysis only when it has public value and does not create confusion or unnecessary vendor burden.

Inconclusive material must be labeled as such.