Bug Bounty Participation by Employees

Bug bounty participation by employees refers to situations where an employee discovers and reports security vulnerabilities in the employer’s systems under an authorised bug-bounty programme. A bug bounty programme generally permits security researchers to test specified systems, identify vulnerabilities, and report them to the organisation in accordance with defined rules.

Employee participation can be beneficial because employees often understand the organisation’s systems better than external researchers. However, it creates important employment, cybersecurity, confidentiality, intellectual-property, conflict-of-interest and disciplinary issues.

An employer should clearly distinguish between:

1. Authorised security testing – testing expressly permitted by the employer.
2. Unauthorised hacking – accessing systems, data or accounts outside the employee’s permission.
3. Internal vulnerability reporting – reporting a security weakness through the employer’s internal process.
4. External bug bounty participation – an employee testing another organisation’s system through an authorised third-party programme.
5. Testing involving employer information – using confidential information obtained through employment to participate in another bounty programme.

1. Authorisation is the central issue

Employees normally have access to company computers and databases for work purposes. That does not automatically mean that they are authorised to conduct independent security testing on every system or database.

A bug-bounty policy should specify:

• which systems may be tested;
• what testing techniques are permitted;
• prohibited activities;
• whether employees may participate;
• whether company devices may be used;
• whether company information can be used;
• how vulnerabilities must be reported;
• whether employees can receive monetary rewards;
• ownership of the bounty payment;
• confidentiality obligations; and
• disciplinary consequences for testing outside the permitted scope.

2. Employee bug bounty testing should have express permission

An employee should ideally obtain written approval before participating in an external programme where there is any connection with the employer's systems, information or business.

For example, an employee discovering a vulnerability in the employer's website while performing authorised security testing is materially different from an employee using administrative credentials to access a restricted database merely because those credentials are available to them.

3. Scope of the bug bounty matters

Bug-bounty programmes usually establish a defined scope. Employees must remain within that scope.

For example, permission to test:

example.com

does not necessarily authorise testing:

• another company-owned domain;
• internal databases;
• employee accounts;
• cloud infrastructure;
• third-party services;
• production data; or
• another subsidiary's systems.

Going beyond the authorised scope can expose the employee to disciplinary or legal consequences.

4. Confidentiality and company information

An employee may encounter confidential information while performing security research. Such information should not be copied, disclosed, downloaded to personal devices, or used for another bounty programme unless specifically authorised.

This is particularly important where an employee participates in a third-party bug bounty. Using vulnerabilities, credentials, source code or security information obtained from the employer to test another organisation could create serious confidentiality and trade-secret issues.

5. Conflict of interest

An employee may discover a vulnerability in a competitor's system through an external bounty programme. The employer should have rules dealing with:

• competitors;
• customers;
• suppliers;
• business partners;
• government systems;
• systems containing personal data; and
• systems connected with the employee's normal duties.

The employee should disclose potential conflicts before conducting the research.

6. Bounty payments

Employment policies should clarify who is entitled to the bounty.

Possible approaches include:

• employee keeps the bounty;
• employer keeps the bounty where testing was part of the employee's job;
• bounty is shared;
• employee receives a bonus instead; or
• employee participation in external bounty programmes is prohibited without approval.

The contractual position is important because merely discovering a vulnerability during employment does not automatically answer who owns the resulting payment or intellectual property.

7. Intellectual property

A vulnerability report may contain:

• source-code information;
• technical documentation;
• screenshots;
• exploit demonstrations;
• security research;
• scripts;
• proof-of-concept code.

Employment agreements and intellectual-property policies may affect ownership of work created during employment. Therefore, bug-bounty policies should expressly address ownership and permitted disclosure.

8. Disciplinary action

If an employee intentionally exceeds the authorised scope, the conduct may become a disciplinary matter.

Possible consequences include:

• warning;
• suspension;
• withdrawal of system privileges;
• recovery of losses;
• termination of employment; and, in serious cases,
• civil or criminal proceedings.

However, disciplinary action should distinguish between a good-faith security researcher who accidentally exceeds scope and an employee who deliberately accesses confidential information or exploits a vulnerability for personal gain.

9. Importance of a safe-harbour policy

A well-designed bug-bounty programme should provide a form of safe harbour for good-faith researchers who remain within the authorised scope.

For employees, the organisation should additionally explain:

• what constitutes authorised research;
• whom to notify;
• what evidence can be collected;
• what data must not be accessed;
• whether exploitation is permitted;
• how emergency vulnerabilities should be reported; and
• when legal approval is required.

Important Case Laws

1. Van Buren v. United States, 593 U.S. 374 (2021)

The U.S. Supreme Court considered the meaning of "exceeds authorized access" under the Computer Fraud and Abuse Act (CFAA). Van Buren had legitimate credentials to access a law-enforcement database but used the database for an improper purpose.

The Court held that a person exceeds authorised access when they access information located in areas of a computer that they are not permitted to access. The decision is important for employee cybersecurity because it distinguishes misuse of information that an employee is authorised to access from accessing computer areas that are technically off-limits.

Relevance: Employee bug-bounty policies should identify precisely which systems, databases and files an employee is authorised to test.

2. LVRC Holdings LLC v. Brekka, 581 F.3d 1127 (9th Cir. 2009)

Brekka was an employee who had permission to use his employer's computers. He emailed company documents to himself while still employed.

The Ninth Circuit held that he had not accessed the computer "without authorization" merely because the employer considered his conduct contrary to its interests. The court emphasised that authorisation depends substantially on whether the employee had permission to access the computer.

Relevance: An employee's ordinary access rights should not be confused with unlimited authority to perform security research. Organisations should expressly define the permitted purpose and scope of access.

3. United States v. Nosal, 844 F.3d 1024 (9th Cir. 2016)

Former employees whose access credentials had been revoked continued accessing their former employer's confidential database using another employee's credentials.

The Ninth Circuit held that circumventing the employer's affirmative revocation of access constituted access "without authorization" under the CFAA.

Relevance: An employee must not continue bug-bounty or security testing after authorisation has been withdrawn. Using another employee's credentials to continue testing can be particularly serious.

4. hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022)

hiQ used automated methods to collect publicly available LinkedIn profile information. LinkedIn attempted to stop the activity and invoked the CFAA.

The Ninth Circuit held that hiQ raised serious questions concerning whether accessing publicly available information after a cease-and-desist notice constituted access "without authorization" under the CFAA. The court also relied on the distinction between publicly available information and systems protected by authentication mechanisms.

Relevance: Bug-bounty participants should not assume that information being technically accessible means that every form of automated testing is authorised. The programme's specific rules remain important.

5. United States v. Morris, 928 F.2d 504 (2d Cir. 1991)

Morris involved the spread of the Morris Internet worm. The Second Circuit examined the concept of "authorization" under the CFAA and treated the term according to its ordinary meaning.

The case became an important early authority concerning unauthorised computer access and the scope of the CFAA. It was subsequently discussed by courts considering employee access and computer-use restrictions.

Relevance: The case demonstrates the longstanding importance of determining whether a person's computer activity falls within the permission granted to them.

6. United States v. Nosal, 676 F.3d 854 (9th Cir. 2012)

The earlier Nosal decision concerned former employees who used legitimate credentials to obtain confidential information for a competing business. The Ninth Circuit addressed whether violations of employer computer-use restrictions could constitute CFAA violations.

The case is important because it demonstrates the legal distinction between accessing information one is not permitted to access and merely violating an employer's restrictions concerning how authorised information may be used.

Relevance: An employee bug bounty policy should clearly define both access permissions and permitted security-testing activities.

Practical Legal Framework for Employers

A good employee bug-bounty policy should contain the following:

Conclusion

Bug bounty participation by employees can be encouraged, but it must be controlled through clear authorisation and scope rules. The most important legal distinction is between authorised security research and unauthorised access. Cases such as Brekka, Nosal, Van Buren and hiQ Labs demonstrate why an employer should not rely merely on general employee computer access. The organisation should expressly define what the employee may test, what information may be accessed, how vulnerabilities must be reported, and what happens to bounty payments.

A properly drafted policy can encourage employees to identify vulnerabilities while protecting the employer's confidential information, systems, intellectual property and legal interests.