Bug bounty and responsible disclosure

Up to now, you tested systems that belong to you. Real life offers a more tempting situation: you are using a website and you notice something odd that looks like a vulnerability. What do you do? This lesson explains the legitimate paths for security researchers: bug bounty programmes, vulnerability disclosure policies, and coordinated disclosure, and it explains what separates a helpful researcher from someone who commits an offence.

Three situations, three ways to act

Situation	What you are authorised to do
A contract with the client (penetration test)	Everything stated in the signed scope and rules of engagement
A public bug bounty programme or disclosure policy	What the policy states: in-scope assets, allowed techniques, safe-harbour terms
No agreement at all	Nothing active. If you accidentally come across a problem, stop and report with minimal information

What is a bug bounty programme?

A bug bounty is an arrangement where an organisation invites independent researchers to look for vulnerabilities in specified systems and rewards valid reports, usually with money, recognition or both. Some programmes are run by the organisation directly; others use an intermediary platform that handles registration, report triage and payment. Programmes can be public (anyone may join) or private (invited researchers only).

Some organisations do not offer rewards but publish a vulnerability disclosure policy (VDP): a statement explaining that they welcome reports, how to send them, and what is allowed. A common convention is to publish contact details in a standard text file at a well-known location of the website (a “security.txt” file), so that researchers know where to write.

Reading a programme’s rules

Before touching anything, read the policy completely. A good policy states:

• Scope: which domains, applications and versions are in scope. Anything not listed is out of scope, including third-party services and partners.
• Allowed and forbidden techniques: typically forbidding denial-of-service, social engineering of staff, physical attacks, automated mass scanning, and accessing or keeping other users’ data.
• Safe harbour: a statement that the organisation will not pursue legal action against researchers who follow the rules. This is reassuring but not magic; it applies only to that organisation and does not bind third parties or the prosecuting authorities in every case.
• Report format and contact channel.
• Rewards and severity criteria, and which issue types are excluded (many programmes exclude low-impact items such as missing headers).
• Rules about public disclosure and confidentiality.

If something is unclear, ask before acting. Any contact with the organisation should be professional and brief.

Rules of conduct for a responsible researcher

1. Stay in scope. Respect every limit in the policy.
2. Use your own accounts. To demonstrate an access control flaw, use two accounts that you created. Do not look at real customers’ data.
3. Do the minimum. Prove the issue with the least intrusive action: one harmless record, one screenshot. Do not download databases, do not browse further than needed.
4. Do no harm. No destructive actions, no service disruption, no data modification beyond your own test data.
5. Protect any data you encounter. If you accidentally see personal information, stop, do not copy it, and mention it in the report without including it.
6. Do not pivot. Do not use one weakness to explore other systems or escalate beyond the proof.
7. Do not trade or demand. Never threaten to publish or ask for payment outside the programme’s terms; that can amount to extortion.
8. Keep it confidential until the organisation has had a reasonable opportunity to fix the issue.

Writing the report to the organisation

The structure from lesson 1 of this chapter applies, in a shorter form: a title, a description, the impact, reproducible steps using your own accounts, a suggestion of a fix, and your contact details. Be courteous and factual. Triage teams receive many reports, and clear, reproducible ones are treated faster and are better rewarded. Duplicates are common: if another researcher reported the same issue first, you may receive no reward, which is normal and not a judgement of your work.

Coordinated (responsible) disclosure

Coordinated vulnerability disclosure is the practice of reporting a vulnerability privately to the party that can fix it, giving them time to do so, and publishing details only afterwards or by agreement. The usual stages:

1. Discovery and private report to the owner, vendor or the programme.
2. Acknowledgement and triage by the organisation.
3. Fix development and release.
4. Agreed publication, often with an advisory, a credit to the researcher and, for products, a CVE identifier requested through the proper channel.

Many researchers and vendors work with a time limit after which details may be published even if no fix exists, to avoid indefinite delay; lengths vary between programmes, and a reasonable timeline should be agreed with the organisation. International standards and guidance on vulnerability disclosure exist, and national bodies publish recommendations.

If there is no programme

Not every organisation has a policy. If you believe you have noticed a real vulnerability in a system without a programme, the safest course is to stop testing immediately and report what you saw, briefly and neutrally, through a public security contact if one exists. In France, ANSSI offers a way for people to report vulnerabilities, and French law contains provisions protecting those who report in good faith to the national authority; check the current text and guidance at cyber.gouv.fr before acting. For incidents and fraud affecting individuals, cybermalveillance.gouv.fr is the public assistance platform. If you are unsure, ask for advice before sending anything, and remember that the people who find vulnerabilities by accident and report them promptly are rarely the ones who get into trouble; the ones who continue exploring are.

Building a career path

Bug bounty can be a rewarding way to practise, but it is competitive and income is irregular, so treat it as a complement to learning rather than a first career plan. Good habits for a beginner:

• Keep practising in legal labs (Web Security Academy, TryHackMe, HackTheBox, Juice Shop) before touching real programmes.
• Start with programmes that welcome beginners and have clear scopes; read disclosed reports from the community to learn how good reports look.
• Specialise in a few vulnerability classes at first and learn them deeply; then widen.
• Write up your learning, in your own words and without disclosing confidential details, to build your reputation.
• Consider professional paths: penetration tester, application security engineer, security analyst in a SOC, and certifications offered by recognised bodies, which the next courses will explore.

Ethics beyond legality

The law sets the minimum. Professionals also follow an ethic: respect privacy, avoid harm, be honest about limits and findings, give credit, keep client information confidential, and use skills to protect. Ethical hackers are trusted precisely because they can do harm and choose not to.

Your turn: evaluate a hypothetical policy

Read the following fictional policy excerpt and answer: which actions are allowed, which are forbidden, and what would you do if, while testing your own two accounts, you saw another customer’s name appear on screen?

Fictional policy (excerpt)
In scope:      the web application at app.example.test and its API
Out of scope:  all other domains, partner services, physical offices
Allowed:       manual testing with accounts you create yourself
Forbidden:     denial of service, automated scanning above a low request rate,
               accessing other users' data, social engineering of our staff
Reporting:     send reports to the security contact; do not publish before we confirm the fix
Safe harbour:  we will not take legal action against good-faith research that follows this policy

See a solution

Allowed: manual testing of the application and API with your own accounts, at a low request rate. Forbidden: any other domain, partner service or office, high-rate scanning, denial of service, accessing other users’ data and social engineering of staff. Publishing before fix confirmation is also not allowed.

If another customer’s name appears, you have reached data you should not see. Stop testing that path immediately, do not note or copy the name, take a screenshot where the name is masked or simply describe the situation, and report it with your own two accounts’ evidence, mentioning that unexpected data was displayed. Doing so respects the “do the minimum” and “protect data” rules and shows good faith.

One last lesson remains: bring your whole audit together and look at what comes next.