A vulnerability is a weakness that can let a threat source trigger behavior a system was not meant to allow. That definition from NIST covers more than a dramatic remote takeover. A forgotten permission check, an unsafe parser, or a badly handled error can all become security problems when the surrounding conditions line up.
The public conversation often jumps from the bug to the payout. The important work happens between those points: finding a weakness, testing it without harming people, helping the vendor validate it, and turning the report into a fix.
Bug bounty programs can pay well, but payment is a result of useful, authorized disclosure. It is not permission to probe any system that happens to be reachable.
What counts as a security vulnerability?
Security teams usually describe a flaw by the security property it can affect. Confidentiality is about who can see data. Integrity is about who can change it. Availability is about whether a service or device remains usable. A single coding mistake can touch one of these properties or several at once.
The word bug is wider than vulnerability. A page that displays the wrong color is a bug, but it is not normally a security issue. A missing authorization check on that same page may let one account read another account's records. The difference is the unintended security impact and the conditions required to reach it.
Common vulnerability families include injection flaws, broken access control, cross-site scripting, insecure deserialization, memory-safety errors, authentication weaknesses, and server-side request forgery. These labels describe recurring causes or outcomes. They do not, by themselves, tell you how serious a finding is. A low-impact issue in an isolated test feature may deserve a different response from a similar flaw in an account or payment workflow.
How CVE, CWE, and CVSS differ
Three terms are often mixed together. CVE is an identifier for a publicly recorded vulnerability. The CVE program explains that numbering authorities assign identifiers to eligible issues, while the National Vulnerability Database adds related product and severity information. A CVE number is a reference, not a guarantee that every affected installation faces the same risk.
CWE describes a weakness type, such as improper input validation or incorrect authorization. It helps engineers discuss root causes across products. CVSS is a scoring method that expresses technical severity through factors such as attack requirements, privileges, user interaction, and impact. A CVSS score is useful for triage, but it does not replace asset context. Exposure, compensating controls, and the value of the affected data still matter.
This separation is practical. A report might identify an access-control weakness, receive a CWE classification, later obtain a CVE identifier, and receive a CVSS score. Those labels answer different questions. Treating them as synonyms makes prioritization harder.
How authorized researchers find vulnerabilities
Legitimate research starts with permission. A program's scope defines the domains, applications, versions, and test accounts that may be examined. Its rules also describe prohibited actions, rate limits, data-handling requirements, and safe ways to demonstrate impact. If a target is not in scope, testing it can create legal and operational risk even when the researcher has good intentions.
Within that boundary, researchers combine several methods. They read documentation and compare the promised behavior with what the product actually does. They inspect requests and responses in a test account, review client-side code, exercise normal workflows, and look for differences between roles. Automated scanners can find patterns, but a human still has to decide whether a result is real, reachable, and security-relevant.
A safe proof of concept should be small. It should demonstrate the security boundary with a test account, synthetic record, or harmless marker. A researcher does not need to download a real customer database to prove that an authorization check is missing.
The report should explain what was observed, what was expected, the conditions needed to reproduce it, and the security impact. It should also state what the researcher deliberately did not do.
How a report becomes a verified finding
Triage teams first check whether the report is in scope, reproducible, and distinct from an existing case. They may ask for a clearer trace, a video, logs, or a revised test case. A report can be technically correct yet receive no bounty when it is out of scope, already known, or missing the impact required by that program's policy.
Good reports save time. A concise title names the affected component and the security effect. The body separates setup, steps, observed result, expected result, and impact. Screenshots can help, but they should avoid personal data and secrets. If a researcher found exposed information, the safer choice is to stop at the minimum confirmation, notify the vendor, and delete local copies according to the program's instructions.
The vendor's response may include a fix, a mitigation, a configuration change, or a decision that the behavior is accepted risk. Coordinated vulnerability disclosure gives the vendor time to investigate and remediate before public details appear. The CVE process and a vendor advisory may follow later. Public disclosure without coordination can put users at risk and can violate a bounty program's terms.
How bug bounty programs evaluate reports
A bug bounty program sets a public or private channel for security reports and defines how rewards are decided. Some programs publish fixed amounts by severity. Others use ranges, bonuses, or separate rules for mobile, cloud, hardware, or artificial-intelligence products. A platform such as HackerOne may provide intake and triage, while the company remains responsible for scope, remediation, and the final award.
Rewards are usually tied to impact, exploitability, report quality, and novelty. A complete report that shows a meaningful security boundary being crossed is more useful than a long list of speculative scanner output. Programs may also reward defense-in-depth research, but only when their published policy includes it.
Safe-harbor language can protect good-faith research conducted within the rules, but it is not universal. Read the program's terms before testing. Do not use social engineering, denial-of-service traffic, spam, persistence, or attempts to access other people's accounts unless a program explicitly authorizes a controlled exercise. When you encounter sensitive data, stop and report it through the stated channel.
How large can bug bounty rewards be?
The largest advertised rewards are reserved for rare, high-impact research. They should not be treated as a typical income estimate or as a reason to chase risky targets.
Apple's Security Bounty page currently lists rewards reaching $2 million for qualifying exploit chains that resemble sophisticated real-world attacks. As of July 2026, Apple says bonuses can push the potential maximum above $5 million. Its categories distinguish outcomes such as kernel control, browser sandbox escapes, unauthorized access to iCloud data, and remote code execution. The program requires a complete, actionable report and coordinated handling before disclosure.
Microsoft's bounty programs overview currently lists awards up to $250,000 for eligible findings in endpoint and on-premises programs, with cloud programs listed up to $100,000 as of July 2026. Microsoft emphasizes scope, rules of engagement, and coordinated disclosure. Its guidance tells researchers not to access, modify, or exfiltrate customer data and to stop if they encounter sensitive information.
How to start vulnerability research safely
Learning security does not require testing live services without permission. Build a lab with intentionally vulnerable applications, study secure coding guidance, and practice writing reports from your own test data. Public advisories, vendor programs, and coordinated disclosure policies provide examples of how professional research is documented.
The most transferable skill is disciplined observation. Define the expected security boundary, test only what you are allowed to test, preserve evidence without collecting unnecessary data, and explain the result so another engineer can verify it. That process is useful whether the final outcome is a patch, a CVE record, a thank-you note, or a bounty.
