What Proofsec is for
Proofsec is a platform designed to connect security researchers with organizations through security programs, vulnerability reports, collaborative research sessions and rewards where offered.
The platform provides a shared environment for discovering research opportunities, understanding program requirements, coordinating work, documenting findings and communicating with the organizations responsible for affected assets.
Researchers can use available programs to identify authorized testing opportunities, investigate potential vulnerabilities and submit evidence for review. Organizations can define the boundaries of their programs, assess incoming reports and coordinate remediation.
Proofsec is intended to make security research more structured, understandable and traceable. Clear scope definitions, consistent report handling and documented decisions help both researchers and organizations work more effectively.
The platform facilitates interactions between participants, but it does not replace the technical judgment, authorization, operational responsibility or security processes of the people and organizations using it.
A program's published scope, Rules of Engagement and applicable terms take precedence over assumptions, old notes, search results or a target's apparent relationship to an organization.
How the platform is organized
Proofsec is organized around the different activities required to participate in security research. These include discovering programs, conducting research, collaborating with other researchers, submitting findings and managing an organization program.
Each area serves a distinct purpose. Programs describe where and under which conditions research may take place; research sessions support coordinated work; reports communicate technical findings; profiles represent researchers; and organization tools support program administration.
The exact navigation, available controls and level of integration between these areas depend on the functionality released on Proofsec. Documentation describes the intended workflow and should not be interpreted as confirmation that every possible feature is already available.
The platform may evolve over time. New capabilities, updated workflows and changes to account or program management should be understood through the current interface and the applicable documentation.
The main areas
- Programs: Discover security research opportunities, review authorized targets, understand exclusions and testing restrictions, and inspect any published reward conditions.
- Research sessions: Organize collaborative research with teammates and, where supported, coordinate shared notes, files, tasks, chat and findings.
- Findings and reports: Document a potential vulnerability, explain its security impact, provide reproducible evidence and submit it to the relevant program for review.
- Profile and reputation: Present your researcher identity, relevant links and achievements, and review the outcomes or statistics made available by the platform.
- Organization tools: Configure organization information, publish security programs, define scope and Rules of Engagement, and manage incoming reports.
- Account and settings: Manage the account and application preferences exposed by the platform and review available account-security controls.
- Documentation and support: Understand platform workflows, review applicable requirements and find guidance for resolving questions about research or account usage.
User roles and responsibilities
Proofsec serves participants with different responsibilities. Researchers investigate potential vulnerabilities and submit findings, while organizations define the scope they can authorize and evaluate reports concerning their assets.
A researcher is responsible for understanding the program rules before testing, staying within the authorized scope, minimizing unnecessary impact and accurately documenting observed behavior.
An organization is responsible for confirming its authority over listed assets, publishing clear rules, handling reports consistently, protecting confidential information and coordinating remediation.
Team members participating in a shared research session should understand the same scope restrictions and coordinate their activity so that collaboration does not result in duplicated effort or unintended testing.
Access to a feature or workspace does not automatically grant permission to perform every action technically possible within it. Authorization remains dependent on the applicable program and the permissions granted to the participant.
Users should keep account information accurate, protect their credentials and communicate through the appropriate channels when a question or issue requires clarification.
Programs and research opportunities
A security program defines the targets an organization makes available for research and the conditions under which testing is permitted.
Program information should identify in-scope assets, exclusions, testing restrictions, eligible vulnerability categories, reporting requirements and any reward conditions that apply.
Before selecting a target, review the complete program description rather than relying only on its title, summary, tags or apparent relationship to the organization.
A program may impose restrictions on automation, request volume, production systems, account creation, sensitive data access or particular testing techniques. These restrictions remain relevant throughout the research process.
A published reward range is not a guarantee that every submission will receive payment. Eligibility and the final outcome depend on the program's applicable terms and the organization's assessment of the finding.
Programs can change, pause or close. Check the current scope and rules before beginning new work, especially when returning to a target after a period of inactivity.
If an asset, technique or permission is unclear, do not infer authorization. Ask the organization through the designated communication process before proceeding.
The security research lifecycle
A typical research workflow begins with selecting an appropriate program and understanding its authorization boundaries. Research then proceeds through investigation, validation, documentation, report submission, triage and, where applicable, remediation and disclosure.
Each stage has a distinct purpose. Investigation identifies suspicious behavior, validation determines whether the behavior represents a reproducible security issue, documentation makes the issue understandable to another person, and triage evaluates the submission against the program's requirements.
A technically interesting observation is not necessarily a confirmed vulnerability. Reports should explain the security boundary affected, the conditions required to reproduce the behavior and the realistic consequences of exploitation.
Once a report is submitted, the organization may request clarification, reproduce the finding, compare it with existing reports and determine an outcome under the program's criteria.
An accepted finding may lead to remediation, a reward where applicable and a coordinated disclosure process. These outcomes depend on the program and are not guaranteed by submission alone.
Maintaining clear communication throughout the lifecycle reduces uncertainty and helps both parties understand the current status, next steps and outstanding responsibilities.
A typical researcher workflow
- Create an account and complete any verification required by the platform or selected program.
- Review the available programs and select one that matches your interests and technical experience.
- Read the program's scope, exclusions, Rules of Engagement, eligible findings and reward conditions.
- Plan your testing approach and prepare the necessary tools or authorized test accounts.
- Investigate only assets and techniques permitted by the program.
- Validate suspicious behavior with the minimum testing necessary to demonstrate its security impact.
- Document the affected asset, prerequisites, reproduction steps, observed behavior and potential impact.
- Remove unnecessary secrets, personal information and unrelated data from supporting evidence.
- Submit the report through the available program workflow.
- Respond to reasonable triage questions and provide additional relevant evidence when requested.
- Review the organization's decision and any applicable remediation, reward or reputation updates.
Research sessions and collaboration
Collaborative research can help participants divide complex investigations, share observations and review findings from different technical perspectives.
Where research-session functionality is available, use it to coordinate the work associated with a shared target or investigation. Keep the session focused on its intended objective and the applicable program authorization.
Agree on responsibilities before beginning collaborative testing. For example, participants may divide work by application component, vulnerability class, test environment or assigned task.
Communicate discoveries that could affect another participant's work, including potentially disruptive tests, exposed sensitive information or evidence that a target may be outside scope.
Shared notes and files should contain only the information necessary for the investigation. Avoid copying active credentials, private keys, customer records or unrelated confidential material into collaboration spaces.
If the platform supports shared chat, files, tasks or code, use the available access controls and keep collaboration material limited to authorized participants.
Team collaboration does not expand the program's scope. Every participant must operate within the same applicable authorization and restrictions.
Agree on how findings will be documented and submitted, and avoid creating multiple independent submissions for the same discovery unless the program's process requires them.
Findings and security reports
A security report communicates a technical finding to the organization responsible for the affected asset. Its purpose is to help the reviewer understand what is vulnerable, reproduce the issue and assess its impact.
A useful report identifies the affected target, summarizes the issue, describes the prerequisites for reproduction, provides clear steps and explains the observed security consequences.
Include evidence that supports the finding, such as sanitized request and response excerpts, screenshots, relevant logs or a minimal proof of concept where appropriate.
Distinguish observed facts from assumptions. If the impact has not been fully demonstrated, explain what is known and what remains uncertain rather than presenting speculation as confirmed behavior.
Use the minimum evidence necessary to establish the issue. Do not include unrelated personal data, active secrets or large datasets simply to make a report appear more convincing.
A report should be understandable to another technical professional who was not present during the investigation. Clear structure and reproducible steps make triage more efficient.
Organizations may classify reports as accepted, duplicate, informative or rejected, depending on the statuses supported by the platform and the program's workflow. Each outcome should be interpreted in the context of the applicable criteria.
Submission does not guarantee acceptance, a particular severity rating, a reward or a fixed remediation timeline.
Report triage and outcomes
Triage is the process through which an organization reviews a submitted report, evaluates its validity and determines the appropriate next step.
Reviewers may assess reproducibility, affected assets, scope compliance, technical impact, evidence quality and whether the issue has already been reported.
A report may be accepted when the organization confirms that it meets the applicable criteria. An accepted report may then proceed to remediation, severity assessment, reward administration or coordinated disclosure as appropriate.
A duplicate classification generally indicates that the same underlying issue has already been reported or recorded under the program's rules. The organization should explain the decision without disclosing another researcher's confidential information.
An informative outcome may indicate that the submission provides useful security information but does not meet the program's criteria for an eligible vulnerability.
A rejected outcome should include a clear reason, such as insufficient evidence, lack of demonstrated security impact, an out-of-scope target or a finding that does not meet the published requirements.
If new evidence materially changes the assessment, the report may warrant further review under the applicable process.
Researchers should use the program's communication process to clarify a decision rather than assuming that every unfavorable outcome indicates an error or bad faith.
Rewards and reputation
Some programs may offer monetary rewards or other forms of recognition for eligible findings. The applicable program terms determine eligibility, reward ranges and any conditions that must be met.
A reward is not guaranteed simply because a report has been submitted. The organization assesses the finding under its published criteria and determines the outcome according to the applicable terms.
Review reward conditions before beginning research. Pay particular attention to exclusions, duplicate rules, severity criteria and any requirements concerning the affected asset.
Where available, researcher profiles and reputation indicators can help represent experience, contribution history or achievements on the platform.
Reputation-related outcomes depend on the metrics and functionality actually provided by Proofsec. Do not assume that every report status, reward or activity automatically changes a public score.
Build a strong reputation through accurate reporting, reproducible evidence, consistent scope compliance, clear communication and responsible handling of sensitive information.
Avoid exaggerating impact, submitting unsupported claims or repeatedly submitting the same finding without a valid reason. These practices reduce the usefulness of research and can undermine trust.
Organization responsibilities
Organizations using Proofsec must be authorized to represent themselves and to permit testing of the assets listed in their programs.
They are responsible for publishing an accurate scope, identifying exclusions, defining testing restrictions and communicating the requirements researchers must follow.
Organizations should establish a reliable triage process, evaluate findings consistently, provide clear decisions and protect confidential reports and researcher information.
Where rewards are offered, organizations must follow the applicable reward terms and handle payment commitments according to the relevant arrangement.
Organizations remain responsible for investigating and fixing vulnerabilities in their own systems. Using Proofsec does not transfer remediation responsibility to the platform.
They should coordinate disclosure reasonably, communicate material changes to program rules and address outstanding reports and commitments when a program is paused or closed.
The specific commitments applicable to an organization are determined by the Organization Terms, the program description and any other applicable agreement.
Authorization and scope boundaries
Having a Proofsec account does not authorize testing every website, IP address, API, mobile application, cloud resource or other internet-accessible asset.
Authorization is limited to the assets, techniques and activities covered by the specific program and its applicable terms. A target's public availability does not establish permission to test it.
An in-scope domain does not necessarily include every subdomain, connected service, third-party integration or underlying hosting system. Read the exact scope definition.
Do not treat search results, historical program descriptions, old screenshots or informal assumptions as substitutes for the current published rules.
If a target appears vulnerable but is outside the listed scope, do not continue testing merely because the issue seems important. Use an appropriate contact channel to seek clarification or report the concern without unauthorized validation.
If testing unexpectedly exposes sensitive information or begins to affect system availability, stop unnecessary activity and follow the program's reporting instructions.
Clear authorization protects researchers, organizations and the integrity of the research process by establishing what is permitted before testing begins.
Account security and confidentiality
Your Proofsec account may provide access to private reports, collaboration material, organization information or other research-related data. Protect it accordingly.
Use strong, unique authentication credentials and enable additional security controls when available. Keep the email account associated with Proofsec secure as well.
Do not share credentials or allow unauthorized people to use your account. Review available account settings and access controls periodically.
Treat unpublished findings, proof-of-concept code, session notes, shared files and private messages as potentially confidential.
Avoid placing secrets or sensitive evidence in public repositories, unrelated chat channels or other locations where unauthorized people may gain access.
If you suspect account compromise or unauthorized disclosure of research material, secure the affected account or system and report the incident through the appropriate channel.
The exact security controls available depend on the current platform implementation. Consult the account-security documentation for guidance on the controls currently supported.
Platform limitations and availability
Proofsec provides workflows for coordinating security research, but the platform cannot independently guarantee that a target is secure, that a submitted finding is valid or that an organization will remediate an issue by a particular date.
The platform does not automatically grant authorization to test an asset. The relevant organization and program determine the permitted scope and activities.
Not every organization necessarily offers rewards, supports every vulnerability class or uses the same triage and disclosure process.
Features such as messaging, shared files, automated workflows, payment processing, integrations and detailed reputation metrics depend on the functionality available for the relevant account or program.
Do not assume that a feature is available merely because it is described as a possible part of the research workflow. Verify its presence in the current interface or documentation.
Organizations and researchers remain responsible for their own actions, security practices and obligations when using the platform.
Common mistakes to avoid
- Starting testing before reading the complete program scope and Rules of Engagement.
- Assuming that public availability or an organization's use of an asset automatically grants testing permission.
- Ignoring exclusions, third-party restrictions or limits on automated testing.
- Treating a theoretical weakness as a confirmed vulnerability without reproducible evidence.
- Submitting reports that omit the affected asset, reproduction steps or realistic security impact.
- Including active credentials, personal information or unnecessary sensitive data in a report.
- Assuming that submission guarantees acceptance, a particular severity rating or a reward.
- Ignoring triage questions or failing to provide relevant clarification.
- Sharing confidential findings outside the intended collaboration or reporting process.
- Assuming that team membership expands the scope of authorization.
- Relying on outdated program details instead of reviewing the current rules.
- Assuming that Proofsec itself is responsible for fixing a vulnerability in an organization's systems.
Where to go next
- New researchers: Read Getting started to understand account setup, program selection and the first-report workflow.
- Report authors: Read Writing a good security report for guidance on structure, reproduction steps, evidence and impact.
- Collaborating researchers: Read Research sessions and team collaboration for guidance on coordinating work and sharing research material.
- Researchers protecting their accounts: Read Account security for practical account and data-protection guidance.
- Organizations: Read Organization onboarding to prepare an organization account and publish a well-defined security program.
- Program administrators: Review Program scope and rules to define authorization boundaries, testing restrictions and eligibility criteria.
- Legal and policy requirements: Review the applicable Terms of Service, Organization Terms, Rules of Engagement and Privacy Policy.