Reputation and report outcomes

1. Reputation is not a reward

Reputation is a platform signal associated with research activity, report quality and report outcomes. It can help communicate a researcher's contribution and reliability, but it is not money, does not guarantee a future reward and should not be treated as a substitute for an organization's decision.

A strong reputation should reflect consistent, well-documented research rather than submission volume alone. Accurate findings, clear communication, respect for program scope and responsible handling of sensitive information are important indicators of research quality.

The platform's published rules and current implementation determine exactly how reputation is calculated, which activities affect it and whether individual outcomes carry different weights.

Do not assume that every accepted report automatically produces the same reputation change, or that every rejected report necessarily reduces reputation. Any such effect depends on the rules that Proofsec actually implements and publishes.

2. What reputation is intended to communicate

A reputation system can help researchers understand their contribution history and help other participants assess research experience. It should be interpreted alongside the details of a person's work rather than as a complete measure of technical ability.

Potentially relevant signals include the quality and reproducibility of reports, the validity of findings, adherence to program rules, communication during triage and the consistency of a researcher's contributions.

A single score cannot capture every aspect of security research. A researcher may specialize in a particular vulnerability class, contribute through collaboration or submit a complex finding that takes time to validate.

Organizations should evaluate each report on its own technical merits. A high reputation score does not make a report automatically valid, and a low or new account reputation does not establish that a technically sound report is incorrect.

3. Common report outcomes

A report outcome communicates how the organization or applicable reporting workflow has assessed a submission. Exact status names and available transitions may vary according to the program and the platform's implementation.

• Accepted: the report has met the applicable acceptance criteria. This does not necessarily mean that a reward has been approved or paid.
• Duplicate: the issue has already been reported or is otherwise considered known under the program's duplicate policy. The decision may depend on whether the underlying cause and affected behavior are materially the same.
• Informative: the submission may contain useful information, but it does not qualify as an eligible vulnerability under the program's criteria or does not establish the required security impact.
• Rejected: the report does not meet the program's requirements, cannot be validated as submitted or is declined for another reason under the applicable rules.
• Needs more information: additional evidence, clarification or reproduction details are required before the reviewer can make a decision, where this status is supported.
• Under review: the report is being assessed and a final determination has not yet been made, where this status is supported.

4. Accepted reports

An accepted report generally means the organization has determined that the submission meets its relevant acceptance criteria. The precise meaning depends on the program's rules and the decision recorded by the reviewer.

Acceptance may follow validation of the vulnerability, confirmation of the affected asset, assessment of the impact and a determination that the issue is eligible under the program.

After acceptance, the organization may continue with remediation, coordinate a fix, assess disclosure timing or handle a reward if the program offers one.

Acceptance does not necessarily mean that remediation is complete, that the issue has been publicly disclosed or that payment is immediate. These are separate stages unless the program explicitly defines them otherwise.

Keep the report's evidence and communications accurate. If you later discover that a reproduction step, impact statement or technical assumption was incorrect, inform the reviewer and provide the correction.

5. Duplicate reports

A duplicate outcome generally means that the organization considers the underlying issue to have been reported previously or to be otherwise known under its duplicate policy.

Two reports may describe the same root cause even when they use different wording, reproduction steps or affected endpoints. Conversely, similar symptoms do not always mean that two findings are duplicates if they arise from distinct causes or create materially different security impacts.

Duplicate handling and reward eligibility depend on the program's published rules. Proofsec's general guidance does not establish which submission receives priority or whether a particular duplicate can receive recognition.

Before submitting a report, review any known-issue information the program makes available and check for related submissions where the program permits that activity. Do not attempt to access confidential reports or internal organizational records.

If your report is marked as a duplicate and you believe the decision overlooks a distinct root cause or material impact, explain the technical difference and provide concise supporting evidence through the available review process.

6. Informative reports

An informative outcome can indicate that a submission contains an observation worth recording but does not establish an eligible security vulnerability under the program's criteria.

Examples may include a hardening recommendation without demonstrated impact, a theoretical concern without a reproducible security consequence, behavior explicitly excluded by the program or an observation that does not cross a meaningful security boundary.

These examples are not universal exclusions. The applicable program rules and the facts of the report determine the outcome.

When a report is marked informative, review the explanation to understand whether the issue lacked demonstrated impact, fell outside eligibility requirements or was otherwise not accepted as a vulnerability.

Use the decision to improve future submissions, but do not assume that every informative report reflects poor research. A technically accurate observation can still fall outside a program's reward criteria.

7. Rejected reports

A report may be rejected because the target is out of scope, the issue is ineligible, the claimed impact is unsupported, the reproduction steps do not work, the behavior is expected or the submission does not meet another program requirement.

A rejection is a decision about the submitted finding under the applicable rules. It does not automatically prove that the researcher lacks technical skill or that all related observations are invalid.

Read the reviewer's explanation carefully. Identify the specific reason for the decision rather than assuming that the rejection was caused by a single general factor.

If additional evidence can resolve a misunderstanding, provide it through the existing report or review channel where permitted. Do not create multiple submissions for the same issue merely to obtain a different outcome.

If the report is correctly rejected, record the lesson and adjust your future testing or reporting approach. Repeatedly resubmitting unchanged findings is unlikely to improve the technical quality of the submission.

8. Reports that need more information

A reviewer may request more information when the issue appears plausible but the available evidence is insufficient to validate it or assess its impact.

A useful response addresses the specific question raised. Provide the missing reproduction step, relevant request and response details, prerequisites, affected account context or other evidence necessary to resolve the uncertainty.

Keep the response focused. Do not upload complete datasets, unrelated logs, unnecessary personal information or additional secrets simply because a reviewer requested clarification.

If you cannot reproduce the issue consistently, explain the conditions under which it occurred, what you have verified and what remains uncertain. Clear limitations are more useful than overstated claims.

Respond within any deadline specified by the program. If you need more time, communicate that through the designated channel rather than leaving the request unanswered without explanation.

9. What makes a high-quality report

A high-quality report allows another person to understand the security issue, reproduce it under the stated conditions and evaluate its realistic impact without unnecessary investigation.

• Clear title: summarize the vulnerability and affected component without exaggerating the impact.
• Accurate scope: identify the exact in-scope asset and relevant endpoint, feature or application.
• Concise summary: explain the underlying security weakness and why it matters.
• Reproducible steps: provide an ordered sequence of actions and the prerequisites needed to reproduce the behavior.
• Expected versus actual behavior: describe the intended security boundary and what occurred instead.
• Evidence: include relevant requests, responses, screenshots, logs or a minimal proof of concept where permitted.
• Impact analysis: explain the realistic consequences supported by the evidence.
• Severity rationale: connect the proposed severity to the affected data, privileges, prerequisites and likely consequences.
• Limitations: disclose assumptions, environmental dependencies and any behavior you could not verify.
• Data minimization: remove unrelated personal information, credentials, tokens and confidential data from the submission.
• Professional communication: use precise language, respond constructively to questions and correct mistakes promptly.

10. Validate findings before submission

Scanner output, unusual application behavior and theoretical attack paths can provide useful leads, but they do not automatically establish a vulnerability.

Where the program permits verification, reproduce the issue using the least intrusive method that demonstrates the relevant security boundary failure.

Confirm that the behavior is not explained by expected functionality, a documented limitation, a test configuration or a prerequisite that changes the security impact.

Avoid testing beyond the point needed to establish the issue. Do not access unrelated records, affect other users, modify production data or continue exploiting a system merely to make the report appear more severe.

If the evidence remains inconclusive, describe the observation accurately and explain what you were able to verify rather than presenting speculation as confirmed exploitation.

11. Severity and impact

Severity communicates the significance of a vulnerability under the criteria used by a program. It should be based on demonstrated or reasonably supported impact, not on the vulnerability name alone.

Relevant considerations may include the sensitivity of affected data, privileges required, attacker prerequisites, scope of affected users or systems, exploitability and the consequences of successful exploitation.

A vulnerability category does not determine severity by itself. Two findings involving the same general weakness may have different severity because their affected assets, prerequisites and consequences differ.

Provide a severity rationale that connects the technical behavior to a realistic outcome. Distinguish direct evidence from possible downstream consequences and explain any important assumptions.

The organization or designated reviewer may assign a different severity from the one proposed by the researcher. Use the program's published methodology where one is available.

12. Scope compliance and research conduct

Report quality includes the way the research was conducted, not just the final technical result. A technically valid observation does not authorize testing methods that the program prohibits.

Verify scope and restrictions before testing, use only permitted techniques and stop when authorization becomes unclear or is withdrawn.

Avoid denial-of-service activity, destructive changes, unauthorized social engineering, unnecessary data access and testing of third-party systems unless the applicable program explicitly permits the activity.

Handle sensitive information carefully and report unexpected exposure promptly. Retain only the evidence needed for the report and follow applicable confidentiality and data-handling requirements.

Respectful, accurate communication helps reviewers assess findings efficiently. It does not replace technical evidence, but it makes the review process more effective.

13. How research quality can affect reputation

A reputation system may use report outcomes or other activity signals to summarize a researcher's contributions. The exact inputs, weighting and effects depend on Proofsec's published rules and actual implementation.

Where supported by the platform, meaningful contributions may include validated findings, reproducible reports, accurate impact analysis and constructive participation in the review process.

Submission volume alone is not a reliable measure of quality. A large number of speculative, incomplete or out-of-scope reports does not necessarily represent more valuable research than a smaller number of carefully validated findings.

Do not assume that duplicate, informative, rejected or accepted outcomes have fixed numerical effects unless Proofsec explicitly documents those effects.

Reputation should be interpreted in context. A new researcher may have limited history, and a specialist may contribute high-value findings in a narrow area. Neither situation can be fully represented by a single score.

14. Maintain a reliable research history

A useful research history is accurate, consistent and supported by evidence. Keep personal research notes that record the relevant target, testing conditions, observed behavior and the reasoning behind your conclusions.

Separate confirmed facts from hypotheses. If a test fails to reproduce an earlier observation, record that result instead of silently retaining an unsupported claim.

When a report contains a mistake, correct it promptly through the available reporting channel. Honest correction helps prevent reviewers from relying on inaccurate information.

Do not fabricate evidence, manipulate outcomes, create misleading accounts, claim credit for another researcher's work or attempt to influence a reputation system through artificial activity.

Where collaboration is permitted, make contributions and shared work clear. Follow the program's rules concerning attribution, team participation, confidentiality and reward allocation.

15. Reviews and disputed decisions

If you believe a report decision is incorrect, use the review, appeal or communication process available for that program. The available process and any deadline depend on the applicable program rules and platform functionality.

A useful review request identifies the decision being challenged, explains the specific point of disagreement and provides evidence relevant to that point.

For a disputed duplicate, explain the difference in root cause, affected behavior or impact. For a disputed severity decision, connect the technical evidence to the relevant severity criteria. For a rejected report, address the stated reason for rejection directly.

Keep the discussion professional and focused on verifiable facts. Avoid threats, repeated submissions of unchanged material, pressure for payment or public disclosure used as leverage.

A review does not guarantee that the original decision will change. The reviewer may uphold the decision, revise it or request additional information, depending on the available process.

16. Corrections to reputation and report records

Records may need correction when a report outcome is changed, a technical error is identified, duplicate handling is revised or an instance of abuse is confirmed.

If you believe your reputation or report history is inaccurate, provide the relevant report reference, explain what appears to be wrong and include supporting information through the available support or review channel.

Do not assume that every decision automatically changes reputation immediately. The timing and behavior of any update depend on Proofsec's implementation.

Where a platform error or confirmed abuse affects a record, corrections should follow the applicable procedures and maintain an accurate history of the decision where appropriate.

A correction request should concern the accuracy or proper application of the rules. It should not be used to pressure reviewers into changing a technically supported outcome.

17. Rewards and reputation are separate

Reputation and financial rewards serve different purposes. Reputation is a platform signal, while a reward is governed by the program's eligibility criteria, reward terms and payment process.

An accepted report does not necessarily qualify for payment. A program may exclude certain issue classes, apply a specific severity threshold, treat duplicates differently or impose other conditions.

Likewise, the existence or absence of a reward does not independently establish the technical quality of a report or the researcher's overall skill.

Review the program's current reward terms and the outcome recorded for your submission. If you have a payment question, use the designated program or support channel and avoid sharing unnecessary financial information in a public discussion.

18. Confidentiality and disclosure

A report may contain confidential technical details, personal data, credentials or information about systems that have not yet been secured. Handle this material according to the program's confidentiality and disclosure rules.

Do not publish a report, proof of concept, sensitive evidence or identifying details about affected users before disclosure is permitted under the applicable rules and agreements.

If you believe a disclosure timeline or confidentiality instruction is unclear, request clarification through the designated channel before publishing.

Reputation concerns, an unresolved reward dispute or disagreement with a reviewer do not automatically authorize public disclosure. Follow the applicable rules and legal requirements.

19. Misuse of reputation systems

Reputation systems are useful only when their underlying records remain reliable. Attempts to manipulate scores or misrepresent research activity can undermine trust between researchers and organizations.

Do not fabricate vulnerabilities, submit knowingly false evidence, impersonate another researcher, misrepresent contributions, manipulate platform interactions or use multiple accounts to create misleading activity.

Do not harass reviewers, threaten organizations, publish private report information to pressure a decision or attempt to obtain another user's confidential research history.

Suspected manipulation or abuse may be reviewed under the applicable platform rules. Any resulting action should depend on the evidence, the relevant rules and the platform's actual enforcement procedures.

If you identify a possible reputation-record error or abuse, report the specific concern through the available support channel rather than attempting to correct it through further manipulation.

20. Practical workflow for researchers

• Read the program's scope, eligibility requirements and Rules of Engagement.
• Identify the exact asset and confirm that your planned test is permitted.
• Investigate the suspected weakness using a controlled, low-impact method.
• Verify the issue and its realistic impact without accessing unnecessary data.
• Check relevant program guidance and known-issue information where available.
• Write a concise report with reproducible steps, supporting evidence and a reasoned impact assessment.
• Submit through the designated reporting channel and retain only appropriate research notes.
• Respond to reviewer questions with relevant evidence and accurate explanations.
• Review the final outcome and correct any mistakes in your own records.
• Use feedback to improve future research without treating a single decision as a complete measure of your ability.

21. Common mistakes to avoid

• Treating reputation as money or assuming it guarantees future rewards.
• Assuming every accepted report must receive a reward or a fixed reputation increase.
• Submitting automated alerts without confirming the underlying behavior.
• Overstating impact or presenting unverified consequences as established facts.
• Ignoring scope, eligibility requirements or testing restrictions.
• Submitting duplicate reports without explaining any meaningful technical difference.
• Responding defensively to reviewer questions instead of addressing the evidence.
• Creating multiple submissions to challenge an unchanged decision.
• Disclosing confidential findings to pressure an organization.
• Assuming that a rejected or informative report automatically proves poor research quality.
• Trying to manipulate scores, report outcomes or researcher attribution.

22. Researcher checklist

• I verified that the target is in scope and my testing method is permitted.
• I reproduced the behavior or clearly stated the limits of my verification.
• I can explain the security impact without relying on unsupported assumptions.
• My report includes clear reproduction steps and relevant evidence.
• I removed unrelated personal data, credentials and secrets from the submission.
• I reviewed the program's eligibility, duplicate and reward terms.
• I will respond to triage questions constructively and correct factual mistakes.
• I understand that reputation, report acceptance, severity and payment are separate matters.
• I will use the available review process if I have evidence that a decision is incorrect.
• I will follow confidentiality and disclosure requirements.

23. Related guidance

Review Programs and Scope before testing a target, Getting Started for the overall research workflow and Account Security for protecting your account and research material.

For a specific finding, the applicable program rules determine scope, eligibility, reward terms and disclosure conditions. This guide explains general concepts and does not override those rules.

The exact reputation calculation, score changes, available report statuses and review mechanisms depend on the functionality and rules Proofsec actually implements and publishes.