Setting Up a Bug Bounty Program: A Sustainable Ethical-Hacker Reward System for Your Company

A classic penetration test is done once or twice a year, the reports are placed on the desk as a PDF, and the attack surface grows until the next test. Yet attackers neither line up in a queue nor wait for a date. This is exactly where bug bounty comes in: ethical hackers from all over the world test your system every day, every hour, with their own methodology, and they earn a reward only if they find and prove a real vulnerability. In this article we will explain how a company in Turkey can build a sustainable bug bounty program from scratch, which platform it should choose, the reward matrix, the legal framework, and how the pre-program cleanup is done with DSET's KAOS engine.

What Is Bug Bounty, and How Does It Differ from a Penetration Test?

Bug bounty is a continuous security program in which a company rewards external researchers who find vulnerabilities in its own systems, within rules announced in advance. According to the annual reports of platforms such as HackerOne and Bugcrowd, the global hacker community now numbers in the tens of thousands, and the number of critical vulnerabilities it finds is leaving the classic audit sector behind.

A penetration test and bug bounty are not alternatives to each other but complements. A penetration test is fixed-scope, fixed-duration, and fixed-fee. Bug bounty is continuous, results-based, and large-crowd. The ideal structure is this: one comprehensive pentest a year, followed by a live bug bounty program.

Criterion	Penetration Test	Bug Bounty
Duration	1, 2 weeks	Continuous
Tester	2, 3 experts	Hundreds of hackers
Pricing	Fixed	Per finding
Scope	Narrow, deep	Broad, parallel
Report	Structured PDF	Real-time ticket

Public or Private? The Program's Visibility

There are two basic visibility models:

Private (invite-only) program: Covers only the platform's high-scoring, identity-verified researchers. It is the most sensible starting form for newly launching Turkish companies. Starting with 5 to 10 researchers and broadening the scope as the process matures reduces both noise and duplicate reports.

Public program: An open program that anyone registered on the platform can join. Visibility is high and the brand prestige is great, but at the same time hundreds of low-quality reports can come in per day. Going public before your triage team has matured leads to self-destruction.

The professional rule: first 3, 6 months private invite-only, then public.

Platform or Self-Hosted?

Three main platforms should be on a Turkish company's agenda:

• HackerOne: The sector leader, the most crowded researcher pool, with heavy references such as GitHub, Shopify, and Goldman Sachs. It also sells a triage service.
• Bugcrowd: Enterprise-focused, the "Crowdcontrol" platform, with strong ASM (attack surface management) integration.
• Intigriti: Belgium-based, attractive for companies sensitive to GDPR and EU data residency. Its EU-based researcher pool is large.

On the Web3 and smart contract side, Immunefi is the undisputed leader. If you are building a DeFi protocol, you will go straight there.

A self-hosted option is also possible: it is run with a security.txt file, a security@ email address, and a terms page on your own website. Trail of Bits's responsible disclosure guide is a good reference for companies adopting this model. The advantage is that the cost is zero; the disadvantage is that the triage and payment operation falls entirely on your shoulders.

Practical advice: for a SaaS with revenue under 50 million TL, start with Intigriti private, and for larger ones with HackerOne private.

The Art of Defining Scope

A poorly defined scope wears out both you and the hacker. Be clear.

In-scope example:

• *.companyname.com.tr production domains
• iOS and Android mobile apps (by bundle id)
• All REST endpoints on api.companyname.com.tr
• Public IP blocks (write them with CIDR)

Out-of-scope items commonly accepted as standard in every program:

• Attempts to access production customer data (provide test data)
• Social engineering and physical attacks
• DDoS, DoS, volume-based attacks
• Absence of rate-limiting (cannot be reported on its own)
• Third-party SaaS services (such as Salesforce, Stripe)
• Self-XSS, vulnerabilities that work on old browsers

If you explicitly reference the OWASP Top 10 categories in your scope document, the hacker understands which class to look for.

The Severity Matrix and CVSS 4.0

The biggest cause of reward inconsistency is severity scoring remaining subjective. The solution: make the CVSS 4.0 standard the official metric of your program. CVSS 4.0 solves the "supplemental metrics" field (automation, recovery, safety impact) where CVSS 3.1 fell short.

The generally accepted threshold table is as follows:

Severity	CVSS 4.0 Score	Typical Example
Critical	9.0, 10.0	Unauthenticated RCE, production DB dump
High	7.0, 8.9	Horizontal/vertical privilege escalation, SQLi
Medium	4.0, 6.9	Reflected XSS, IDOR (limited)
Low	0.1, 3.9	Information leak, missing header

Reward Table: Realistic Ranges

The most common mistake here is copying exaggerated figures. The upper limits in the public programs of companies like Google and Apple are the exception, and are not a reference for an ordinary Turkish SaaS. According to the sector reports published by HackerOne and Bugcrowd, the general ranges in small and mid-sized enterprise programs run roughly as follows:

Severity	General Sector Range (USD)
Critical	1,500, 5,000
High	500, 1,500
Medium	150, 500
Low	50, 150

In Web3, Immunefi programs publicly announce six-figure rewards for critical smart contract vulnerabilities, but this class is proportional to TVL (total value locked).

For a Turkish company, rewards can be published in TL, but if your researcher pool is international, using USD or EUR is standard. Set up your infrastructure so that you can make the payment with a single click via Stripe or Wise.

The Triage Process: A 24-Hour Promise

In the bug bounty community, communication time is as important as the reward. The standard SLA is as follows:

1. First response: reading the report and saying "received" within 24, 48 hours
2. Triage decision: a duplicate, valid, or invalid decision within 3, 5 business days
3. Remediation plan: ETA notification within 10 business days
4. Payment: within 30 days after remediation or acceptance

Who will do the triage? There are two paths: either buy the platform's managed triage service (HackerOne and Bugcrowd charge separately), or tie it to a daily routine in-house with your own IR team.

Coordinated Disclosure: The Disclosure Timeline

When and how the vulnerability will be disclosed to the public must be written into the contract text. The industry standard:

• The hacker does not share it with third parties until the fix is complete.
• The company promises to make the fix within a reasonable time (generally 90 days).
• After the fix, both parties may publish a joint written summary (CVE number, affected version).
• No disclosure is made without crediting the hacker's contribution.

This framework is covered in detail in the Trail of Bits responsible disclosure guide.

Hall of Fame and the Duplicate Rule

Beyond the reward, having their name appear in your program is a serious source of motivation for a researcher. Set up a public "Hall of Fame" page; show name, country, severity, and date. This page is both a mark of respect to the community and a brand communication tool.

Duplicate rule: It is common for two hackers to independently report the same vulnerability. The industry standard is to give the reward to the one who writes the first valid report. However, a second report that produces a new attack chain, deeper impact, or a bypass can also be rewarded separately. Write this explicitly on your program's terms page.

Rules for Communicating with the Bug Bounty Hunter

Researchers are generally extremely technical, direct, and methodical people. Do not shy away from speaking plainly, but:

• Demeaning language is forbidden. The phrase "this was already known" can only be used with a public CVE reference.
• Explain instead of lowering severity. Write a justification like "this is medium because the impact is limited to production data".
• When you cannot reproduce it, ask the researcher for a video or PoC; do not close it by saying "it does not work".
• Do not cancel, tag. Archive even an invalid report as "informational", so the hacker gets feedback.

Legal Framework: Bug Bounty Law in Turkey

The most critical item for Turkey is Articles 243, 244, and 245 of the Turkish Penal Code No. 5237. These articles define unauthorized access to an information system, alteration of data, and bank card abuse as crimes. The bug bounty program is mandatory because it is the statement of consent that makes the hacker's action legally valid.

Your program's terms page must include the following safe harbor statement (in essence):

Security research carried out in good faith within the rules of this program is considered authorized by our company. No criminal complaint will be filed against the researcher for actions carried out within this scope.

The KVKK side: it must be a contractual condition that if the hacker sees personal data during testing, they immediately delete it, do not share it, and notify the company. For ISO 27001 certified companies, this is already available in the document pool as ready-made text.

A Practical 30-Day Start for Turkish Companies

A practical timeline from zero to live:

Week 1: Policy document, scope, severity matrix, safe harbor text.

Week 2: Platform selection (Intigriti or HackerOne), creating the private program, the first list of 5, 10 invited researchers.

Week 3: Legal approvals, the legal department's signature, payment infrastructure (Stripe or Wise).

Week 4: Soft launch, triage of the first reports, SLA tests.

The must-have of this process is "cleaning the house" before the bug bounty. Otherwise, in the first week 50 medium reports come in, your budget runs out in two days, and morale collapses.

Pre-Program Self-Discovery with DSET's KAOS Engine

The KAOS autonomous security engine, which we developed in-house at DSET, is exactly the tool that pre-bug-bounty cleanup needs. With over 70 specialized modules (recon, IDOR hunter, SSRF scanner, takeover triage, exploit verifier, CVE matcher), KAOS scans your target system like an independent hacker.

Before your program, KAOS:

• Enumerates your subdomain inventory (passive recon + cert intel)
• Catches low-hanging fruit vulnerabilities in the OWASP Top 10 category
• Verifies with its exploit engine whether the finding is actually exploitable
• Reports the findings with their severity and CVSS 4.0 score

The result: on the day you start the bug bounty, external researchers no longer come in with easy vulnerabilities, they find genuinely creative attack chains. Your budget is not wasted, and your critical vulnerability discovery rate rises by up to threefold.

The supporting layers that reinforce this: a modern EDR solution sees an endpoint hijack attempt before the bug bounty report, and SOC 2 certification proves the seriousness of your program to your SaaS customers.

FAQ

1. How much should the annual bug bounty budget be? Industry practice: 5 to 10 percent of the annual information security budget. For a SaaS with a security budget of 100 thousand USD, a bounty reserve of 5 thousand to 10 thousand USD is a reasonable start.

2. A hacker did a pentest on us without permission, are we obliged to give a reward? No. If you have not announced an official program, you have no legal obligation. However, punishing a good-faith report will disgrace you within the community. At a minimum, offer a thank-you note and a Hall of Fame spot.

3. Does it make sense to outsource triage? For the first 6, 12 months, yes. You filter out the noise with the HackerOne and Bugcrowd managed triage service. Once volume matures, running it in-house is more economical.

4. How will I explain the bug bounty to my customers? On the contrary, this is a trust signal. The sentence "We keep our systems continuously open to an external community of security researchers" is a serious differentiator in B2B sales. The Hall of Fame page is a showcase.

5. What happens if the hacker sells the vulnerability they found? A "non-disclosure" condition explicitly written in the program binds the hacker. In case of a breach of the condition, the reward is cancelled and the legal path is opened. This is why a private program is preferred, with identity verified.

6. Should we move between CVSS 4.0 and CVSS 3.1? New programs should start directly with 4.0. Old programs set a transition timeline through the end of 2025. The official FIRST.org guide is your reference.

7. An out-of-scope attack came in, what should I do? Close it with the "out-of-scope" tag, and politely remind the reporter of the scope. The hacker learns this and will bring the correct report in the future. Do not punish.

8. How do we run the KAOS engine on our own system? DSET delivers the self-discovery report produced by KAOS under a key specific to the closed scope. After this, you can open the cleaned-up system to bug bounty. An on-site demo can be done on request.

Conclusion and the Next Step

A bug bounty program is not just a budget line item, it is a culture. When set up correctly, it catches ten times more vulnerabilities than an annual pentest, raises your brand prestige, and becomes a serious differentiator in international SaaS sales. When set up wrong, your budget melts in two weeks, you get a bad name in the community, and you enter legal risk.

From its Hacettepe Teknokent Ankara headquarters, DSET runs bug bounty program consulting, KAOS autonomous self-discovery scanning, scope and severity documentation, platform selection consulting, and the triage operation end to end. To launch your program on the right foot, get in touch with us: +90 536 662 38 09.