Research sessions and team collaboration

1. What a research session is

A research session is a shared workspace for researchers collaborating on an authorized security program. Depending on the features enabled in your account, it may bring notes, reconnaissance results, tasks, code snippets, files, chat, findings and team activity into one place.

Sessions help researchers coordinate their work, reduce duplicated effort, document technical discoveries and prepare better vulnerability reports.

A session is a collaboration tool, not an expansion of a program's authorization. Joining a session does not grant permission to test additional assets, use prohibited techniques or access information that would otherwise be unavailable to you.

Every participant must follow the program's scope, Rules of Engagement, confidentiality requirements and applicable platform rules, regardless of who created the session or invited them.

The features available in a session may vary. Do not assume that every session supports persistent files, task tracking, code execution, version history, access auditing or automatic reward allocation.

2. Choose the right team structure

Select a team size that fits the scope, complexity and available time for the research. A larger team is not automatically more effective; unclear ownership can create duplicated work and unnecessary risk.

For a solo session, one researcher can manage reconnaissance, validation, evidence and reporting. Keep notes structured so that the work remains understandable if you return to it later.

For a duo, consider dividing responsibilities between complementary tasks, such as asset analysis and manual validation. Agree on how observations will be reviewed before a report is submitted.

For a larger team, assign clear responsibilities for target coverage, technical validation, evidence handling and report preparation. One person may coordinate the work, but every participant remains responsible for their own actions.

Use private team arrangements only with people who are permitted to participate and who understand the program restrictions.

Team size and session membership do not determine whether a finding is valid, eligible for a reward or considered a duplicate. Those decisions depend on the program's applicable criteria.

3. Before inviting teammates

• Confirm that each teammate understands the program scope, exclusions and Rules of Engagement.
• Verify that the program is active and that each planned target remains in scope.
• Agree on the target areas, testing boundaries and conditions that require everyone to stop.
• Define responsibilities so that critical tasks have an owner and overlapping work is intentional.
• Decide how reconnaissance notes, test results and potential findings will be documented.
• Agree on how existing reports and potential duplicates will be checked before submitting new findings.
• Establish how sensitive evidence will be stored, shared and removed when no longer needed.
• Discuss contribution tracking and any proposed reward split before substantial work begins.
• Use only the communication channels and sharing features appropriate for the sensitivity of the material.

4. Establish a session plan

Start with a short plan describing the program, authorized target, research objective, known restrictions and expected deliverables. A clear plan helps the team avoid unrelated testing and makes progress easier to evaluate.

Break the work into manageable tasks. Examples include reviewing documentation, mapping permitted application functionality, validating an observed behavior and preparing a report.

Assign each task to a responsible participant. If two researchers need to work on the same target, define the purpose of each activity to avoid unnecessary overlap.

Record important decisions, including changes to task ownership, discoveries that affect the testing plan and reasons for stopping an activity.

Keep the plan aligned with the current program requirements. If the organization changes scope or pauses testing, update the plan and stop affected tasks.

Use task lists, status fields and assignment features only where they are available. If the platform does not provide them, agree on a simple shared method that preserves the same clarity.

5. Divide tasks without losing coordination

• Assign each task a clear objective, target and expected result.
• Identify one participant responsible for tracking the task's progress and documenting its outcome.
• Mark observations as unverified, under investigation, validated or ready for reporting when your workflow supports those states.
• Share relevant discoveries with teammates before they repeat the same tests.
• Record important negative results when they help prevent repeated work or clarify an application's behavior.
• Avoid running multiple intrusive tests against the same target without a clear technical reason.
• Reassign unfinished tasks explicitly when a teammate becomes unavailable or leaves the session.
• Keep the team's plan updated when a finding changes the priority or direction of the research.

6. Reconnaissance and target coverage

Reconnaissance within a session must remain limited to assets and techniques authorized by the active program. A discovered hostname, endpoint, repository or service is not automatically in scope.

Record the source of an observation where practical, such as program documentation, an in-scope page or a permitted test result.

Distinguish confirmed assets from possible assets that still require scope verification. Do not treat a guess, search result or third-party reference as authorization.

Coordinate reconnaissance to reduce redundant requests and prevent multiple participants from unintentionally repeating the same activity.

Keep potentially sensitive results private and share only the information needed for the team's work.

Do not collect large amounts of data merely to build a comprehensive inventory. Prefer targeted observations relevant to the authorized research objective.

If reconnaissance reveals a possible third-party system or an ambiguous ownership boundary, pause testing of that asset until authorization is confirmed.

7. Share code, commands and technical notes

Use shared code snippets and technical notes to explain reproducible behavior, document test logic and help teammates understand a finding.

Before sharing code or commands, review them for embedded credentials, API keys, access tokens, private URLs, personal data and other secrets.

Explain the intended target and expected effect of a command. Do not assume that every teammate understands the risks of running it.

Identify commands that modify state, generate significant traffic or could affect real users. Do not run them unless the program explicitly permits the activity and appropriate safeguards are in place.

Prefer small, focused and reproducible examples over scripts that perform broad discovery or execute many unrelated tests.

Do not share malware, stolen credentials, unauthorized persistence tools or code intended to evade program restrictions.

Review copied code before execution. Code received from a teammate or an external source should be treated as untrusted until understood.

Keep technical notes factual. Separate observed results from assumptions, possible explanations and unverified impact.

8. Files, evidence and sensitive material

Share only files that you are authorized to disclose to the session participants. The fact that a file can be uploaded does not mean it is appropriate to share.

Remove unnecessary credentials, tokens, personal information and confidential content before uploading screenshots, logs, source code or other evidence.

Use the least sensitive evidence that still demonstrates the issue. Redacted screenshots, limited response excerpts and synthetic test data are preferable when they establish the same technical point.

Do not upload entire databases, unrelated user records, private keys or bulk exports when a minimal proof is sufficient.

Limit access to sensitive evidence to participants who need it for the authorized research. Do not forward it to unrelated people or external services.

Treat downloaded files and code from other participants as untrusted. Inspect them before opening or executing them, especially if they contain scripts or executable content.

Follow the program's retention and deletion requirements. Remove unnecessary copies when they are no longer needed, while preserving only information that you are authorized and legitimately required to retain.

If you discover that sensitive data has been shared accidentally, stop further distribution, restrict access where possible and notify the relevant people or organization through an appropriate private channel.

9. Use chat responsibly

Use session chat to coordinate research, discuss observations, ask technical questions and document decisions relevant to the session.

Keep messages clear and specific. Include the affected in-scope asset, the observed behavior and the relevant task or finding when that context helps teammates understand the discussion.

Do not post passwords, session cookies, API keys, private keys or unnecessary personal information in chat.

Do not use session chat to threaten teammates, pressure an organization for payment, harass participants or coordinate activity that violates program rules.

Do not assume that chat messages are confidential merely because the session is private. Access, retention, administrative visibility and deletion behavior depend on the platform's actual implementation and applicable policies.

Move highly sensitive material out of ordinary chat when a more appropriate secure reporting method is available.

Keep disagreements factual and focused on the technical work. Avoid personal attacks and unsupported accusations.

10. Validate findings as a team

A potential finding should be reviewed before it is treated as confirmed. The team should understand the reproduction steps, affected asset, relevant prerequisites and observed security impact.

Use the least intrusive verification method that can establish the issue. Avoid expanding access or collecting additional data simply to make the evidence more dramatic.

Where practical, ask a teammate to review the reasoning, reproduce the behavior safely or check whether an alternative explanation fits the evidence.

Record the exact conditions required to reproduce the issue, including account role, relevant configuration and test data when applicable.

Distinguish the vulnerability itself from its potential consequences. Do not claim account takeover, data exposure or privilege escalation unless the available evidence supports that conclusion.

Do not repeat a test that could modify data or affect service availability merely to obtain a second confirmation if the first observation already establishes the issue.

If validation reveals that the issue is not reproducible or the original interpretation was incorrect, update the notes and avoid submitting an unsupported report.

11. Avoid duplicate work and reports

Before preparing a report, check the session's existing findings and relevant program information for a potentially identical issue, where those records are available to you.

Compare the underlying cause, affected functionality and security impact rather than relying only on titles or endpoint names. Two different symptoms may share one root cause, while similar symptoms may have different causes.

Coordinate with teammates who are investigating related behavior. Agree on whether the observations belong in one report or should be documented separately.

Do not submit multiple reports for the same issue solely to increase the chance of receiving credit or a reward.

If the team discovers that a finding duplicates an existing report, document the relationship and follow the program's reporting instructions.

Proofsec or the organization may make the final determination about duplicates under the applicable program rules. A team's internal assessment does not guarantee a particular triage outcome.

12. Prepare and submit a joint report

A joint report should present one coherent technical explanation rather than a collection of disconnected observations.

Identify the affected asset, prerequisites, reproduction steps, expected behavior, actual behavior, security impact and supporting evidence.

Remove secrets and unnecessary personal or confidential data from the report. Use redaction or synthetic examples where possible.

Record each participant's contribution accurately, including discovery, validation, reproduction, analysis and report preparation where relevant.

Have another team member review the report for technical accuracy, clarity, scope compliance and unsupported claims before submission.

Submit through the channel specified by the program. Do not assume that a session message or shared note counts as a formal report.

After submission, keep the report private and direct follow-up questions through the designated channel.

Do not continue exploiting the vulnerability while waiting for triage, clarification or a reward decision.

13. Contributions, ownership and attribution

Discuss contribution expectations before substantial work begins, particularly when several researchers may contribute to the same finding.

Keep a factual record of meaningful contributions where practical. Useful records may include task assignments, technical notes, validation results and report revisions, subject to the platform's available features.

Do not claim another researcher's discovery as your own or omit a teammate's material contribution to obtain an advantage.

Agree on how authorship and credit should be represented in the submitted report, subject to the program's rules and the platform's capabilities.

Participation in a session alone does not automatically establish authorship of every finding produced by the team.

If contributions are disputed, preserve relevant records and use the available platform or program review process instead of altering evidence or making public accusations.

14. Reward splits and payment expectations

If a program offers monetary rewards, discuss any proposed split before the team submits a joint report. Clear expectations reduce disputes after a finding is accepted.

Specify the participants covered by the agreement, the intended allocation, how contributions will be considered and how changes to team membership will be handled.

Record the agreement in an appropriate place where the platform supports it. If the platform does not provide a formal allocation feature, do not assume that a chat message automatically changes the program's payment process.

Confirm whether the organization permits team submissions and whether it defines specific rules for reward eligibility, attribution or allocation.

Do not represent an informal agreement as an official Proofsec payout arrangement unless the platform explicitly supports and confirms that arrangement.

Proofsec's role in reward decisions and payment handling depends on the applicable program terms and the features actually available. Do not assume that Proofsec automatically divides, holds or transfers rewards.

A submitted report, an internal team agreement or an accepted finding does not by itself guarantee a reward. The program's eligibility criteria and final decision apply.

Resolve allocation disagreements privately and preserve relevant records. Do not threaten teammates, withhold necessary security information or publish confidential findings to pressure another participant.

15. Respect scope throughout collaboration

Every participant must independently respect the active program's scope and restrictions. A teammate cannot authorize testing merely by requesting it or sharing a target.

Do not test a new asset because another participant found it during reconnaissance. Verify its authorization first.

Do not use a session to coordinate prohibited denial-of-service activity, phishing, unauthorized credential use, destructive testing or access to third-party systems.

If the program changes its scope or an organization requests that testing stop, notify the team and pause affected work.

If a teammate begins an unauthorized activity, do not join, extend or conceal it. Stop contributing to the activity and raise the issue through an appropriate channel.

For detailed restrictions, consult the program's current rules and the Proofsec Rules of Engagement document.

16. Handle disagreements constructively

Disagreements may concern technical interpretation, task ownership, report authorship, duplicate findings or proposed reward allocation.

Start by identifying the specific point of disagreement and reviewing the available evidence, task history, agreed responsibilities and applicable program terms.

Distinguish documented facts from recollections and assumptions. Do not modify notes or selectively remove records to influence the outcome.

Use the platform's available review or support process when direct discussion does not resolve the issue.

Do not threaten teammates, retaliate against participants, interfere with another person's account or report, or disclose confidential material as leverage.

If the disagreement raises a security concern or reveals a potential violation, stop the affected activity and report the concern through an appropriate private channel.

17. Leaving or closing a session

Before leaving a session, update or hand over any active tasks that other participants depend on, where the platform's workflow allows it.

Communicate the status of unfinished work, outstanding validation questions and any relevant restrictions without disclosing unnecessary sensitive information.

Keep only notes, files and evidence that you are authorized to retain. Session membership does not grant indefinite permission to retain or reuse shared material.

Do not copy the entire session archive or download other participants' work merely because access may be removed later.

If you leave a team, stop using shared credentials, access tokens or other resources that you are no longer authorized to use.

Respect confidentiality obligations after leaving the session. Do not publish findings, code, internal discussions or evidence without the required authorization.

If you created the session, follow the platform's available procedures for transferring coordination responsibilities or closing the workspace.

Do not assume that leaving a session deletes messages, files or records from the platform. Retention and deletion behavior depend on the implemented features and applicable policies.

18. Security and account protection

• Use a unique, strong password for your Proofsec account and protect the email account used for recovery.
• Do not share your Proofsec login credentials with teammates.
• Avoid accessing sessions from untrusted devices or leaving an authenticated session unattended.
• Verify recipients before sharing files, code or sensitive research notes.
• Review shared material for secrets before uploading it.
• Report suspected unauthorized session access or account compromise promptly.
• Do not attempt to access another participant's private sessions, files or messages without authorization.
• Use additional account security controls where they are available.

19. Common collaboration mistakes

• Assuming that joining a session grants permission to test every target discussed by the team.
• Starting the same test simultaneously without coordinating responsibilities.
• Sharing raw logs or screenshots that expose personal information or credentials.
• Treating an unverified hypothesis as a confirmed vulnerability.
• Submitting a joint report without checking for duplicates or agreeing on attribution.
• Assuming that a session automatically manages reward allocation or guarantees payment.
• Continuing testing after the program changes scope or requests a pause.
• Copying shared evidence after leaving the session without checking retention and authorization requirements.
• Using chat or public disclosure to pressure a teammate or organization during a dispute.

20. Session workflow checklist

• Confirm the active program, authorized assets and applicable restrictions.
• Invite only appropriate participants and agree on responsibilities.
• Create a clear research plan and divide work into manageable tasks.
• Coordinate reconnaissance and share only relevant observations.
• Keep code, files, chat and evidence free of unnecessary secrets.
• Validate findings safely and distinguish facts from hypotheses.
• Check for related findings and potential duplicates before reporting.
• Review the joint report for accuracy, impact, scope and confidentiality.
• Document contributions and clarify any reward split before submission.
• Keep reports private and follow the organization's instructions after submission.
• Hand over unfinished work and retain only authorized material when leaving.

21. Final principle

Effective collaboration depends on clear authorization, deliberate task ownership, accurate documentation, secure information sharing and honest attribution.

A session should make research more organized without increasing the risk to systems, users or teammates.

When scope, evidence handling, contribution ownership or reward allocation is unclear, pause the disputed activity and clarify expectations before proceeding.