Product
What we've shipped, and when. So you can see the platform improving.
Your researcher profile now showcases the CVEs credited to you, unified across GitHub security advisories and CVEs you have added and verified yourself, deduped and linked to the source. Repository-level GitHub advisories that credit your verified account are captured too, not just the globally reviewed ones, so credit that was previously invisible finally shows up where it belongs.
The homepage now opens on the thing that matters most: a live look at which programs are heating up and where the surface is exposed. The public record of researcher credits and reviews is still there beneath it, as the proof behind the ratings.
New: Attack Surface, live intelligence on the whole bug bounty field. It reads every rated program as a market and shows which are heating up, which are under-hunted while still active, and what each one's surface is exposing right now: staging environments, exposed configs, and login and admin panels. Read it on a live board, or pull it into your own recon over a metered JSON API. Available as a subscription.
Every program page now shows report intake day by day over the last 30 days. A small sparkline makes it obvious at a glance whether a program is heating up as reports pour in or quietly cooling off, so you can time your effort instead of guessing.
Reviews can carry proof now. When you write about a program you can attach screenshots of the parts worth showing: a triage exchange, a payout, a scope decision. Uploads are checked and stripped of anything unsafe, so a review can back its rating with evidence instead of only words.
We now collect the researcher credits that programmes publish themselves, from two directions.
Eleven new sources are being read: security advisories from Jenkins, Drupal, GitLab, Moodle and Zoom, and the acknowledgement pages that Philips, Schneider Electric, Wikimedia, Palo Alto Networks, Axis and Signify maintain.
Those acknowledgement pages matter more than they look. For a lot of programmes there is no advisory and no CVE, and a name on the vendor's own thanks page is the only public record that the work happened at all.
Nothing from these sources publishes automatically. Every credit lands as a draft for a person to approve, because vendor pages change shape without warning and a wrong name attached to a real person is a real harm. A broken parser should be an annoyance in a queue, never a false claim on a public page.
We are also reading HackerOne's per-programme thanks lists, which record not just who a programme credited but how many of their reports it recognised against how many they submitted.
That ratio is the most honest public answer to the question every hunter actually asks, which is whether a programme is worth your weekend. It is a signal to noise reading for a specific programme, published by that programme, and nobody aggregates it.
Names are stored exactly as the programme published them. Where a platform withheld a name, we store that it was withheld and leave it that way.
The directory has grown by about a third, and it now covers ground it previously ignored entirely.
Every programme we held came from HackerOne or Bugcrowd. Now the directory also carries Intigriti, YesWeHack, Immunefi, Code4rena and Sherlock, and around nine hundred self-hosted programmes: companies running their own disclosure programme with no platform behind them at all. Those are exactly the ones that are hardest to find, which is the best reason to list them.
Filtering by platform now includes all of these, so you can look at just the web3 programmes, or just the self-hosted ones, without wading through everything else.
A company that runs on two platforms is one company here, not two entries. The matching rules are deliberately cautious: a missed merge is easy to fix later, a wrong merge quietly corrupts the directory. Where a listing could not be named honestly, it was set aside for a person to look at rather than guessed at.
We are also frank about the source. The self-hosted list comes from an open community dataset, and we check each entry against the company's own published security contact. Roughly a quarter still publish one and about a fifth no longer resolve at all, so we record what the source says and when we read it, rather than presenting it as current fact.
The directory search now filters as you type, matching anywhere in a programme name, the company behind it, or the handle it is filed under on its platform. With more than eight thousand entries, scrolling was no longer a reasonable answer.
We have started recording what HackerOne programmes actually pay, rather than what they advertise.
A programme's policy page tells you a reward range. That is a statement of intent. What we now store is the average amount actually paid at each severity, and the number of reports behind that average, straight from HackerOne's own public data.
The count matters as much as the figure. An average over three reports and an average over nine hundred are not the same claim, so both are kept together and neither is shown alone.
Alongside it we record intake and responsiveness: reports received in the last ninety days, how many have been resolved, how many people are participating, response efficiency, and the programme's own declared response targets. We also record what stands between you and submitting at all, which almost nobody publishes: whether a programme accepts only cleared or identity-verified hackers, whether HackerOne triage is in the loop, and whether it hides its bounty amounts.
This is stored as a daily snapshot rather than a single current figure, because the interesting thing is the movement. A programme whose average critical payout has been sliding for two months, or whose queue is filling faster than it drains, is telling you something no single number can. Keeping only the latest value would throw that away every time we refreshed.
The data is arriving now and the reading pages come next. Everything here is published by HackerOne to anyone, signed in or not. We collect it, we do not infer it, and where a programme publishes nothing we record nothing rather than guessing.
The site now has a dark theme, and you choose how it behaves.
The control in the nav offers System, Light and Dark. System is the default and follows whatever your operating system is set to, including when your OS switches automatically in the evening. Pick Light or Dark and that choice wins, on every page, whatever your OS says.
Your choice is remembered in your browser, so it works whether or not you are signed in, and it is applied before the page paints. You will not get a flash of white on the way in.
Dark mode was drawn rather than flipped. The letter grades were reworked so an A+ still reads as good and an F still reads as bad against a dark card, and the engraved grade block still looks engraved. Panels that are deliberately dark on the light theme, like the admin sidebar, become raised dark surfaces rather than turning into white slabs. Depth comes from the surface being lighter than the page behind it, because a shadow barely registers on a dark ground.
We checked every colour on the site against its background for contrast and fixed what failed. One thing we did not change: a company's own brand colour on its profile is that company's colour, and we would rather leave it alone than repaint someone's identity to suit our theme.
Two changes, one of them a fix to something that was plainly wrong.
The landing page opened with security releases. Reviews are the premise of this site (what it is actually like to submit to a program, from the people who did it) so they now come first, and releases follow them.
If you had already had a review approved, a new one went straight to public with no check at all. That was never the intent. The rule is that a trusted researcher skips the manual queue, not that they skip review altogether.
Now every review lands pending and an automatic check picks it up within a few minutes. It scores completeness (the per-report detail, the ratings and the outcomes, not merely length) and either publishes it or hands it to a person with the reason recorded. It can never reject anything on its own.
Two silences went with that bug, and both are closed:
had no way to distinguish that from nothing happening.
and moderators are now told, so it cannot sit there unnoticed.
Two fixes that belong together, because the same report surfaced both.
Transactional mail (password resets, email confirmations) was going out unauthenticated. It failed SPF and DKIM, so it landed in spam. Worse, providers disable links in messages they cannot verify, which meant a reset email could arrive looking perfectly normal and still be impossible to use.
Mail is now sent authenticated and signed as bugrater.com, so it reaches the inbox. We also added delivery monitoring: if sending breaks again it raises an alert immediately, instead of failing silently the way it did this time.
Deleting your account deactivates it rather than erasing it, and we now email you a recovery link that works for 30 days. Change your mind, click once, and everything comes back. Reviews included. Nothing is quietly destroyed in the meantime.
Before this, deletion was instant, silent, and final. If you were already locked out by the email problem above, there was no way back at all.
To Ahmed Taha, who ran into the broken reset flow. Thank you.
Two changes about what BugRater sends you and how it shows you things.
We can now tell whether the mail we send actually arrives: whether it was delivered, opened, and whether its links worked. It is entirely first-party: no delivery or marketing service is involved, and any IP address is stored only as a hash. The [privacy policy](/privacy) sets out exactly what is recorded.
The reason is operational rather than behavioural. If password resets and notifications are quietly failing to land, we want to know before you do.
Change notes and blog posts were showing their Markdown as raw characters. You would see ## and ** in the text instead of a heading and bold. That was our renderer not being wired into those two surfaces. It is now, so headings, lists, and bold appear as intended, including in the note you are reading.
Two changes to the read-only JSON API. One of them changes how your code behaves, so read on if you call the API.
Each key is now allowed 60 requests per minute. Every response carries X-RateLimit-* headers so you can see where you stand, and going over returns 429 with a Retry-After telling you how long to wait. If you were hammering an endpoint in a tight loop, that is now throttled. This is a behaviour change, said plainly.
List endpoints are now paged. Pass ?limit= (default 50, maximum 100) and ?offset=, and every list response includes total and has_more so you know whether there is more to fetch. If you were relying on a single call returning everything, it no longer does.
The generated docs regenerate with all of this in them, your key already baked into the examples.
The API key page has been redone. A new key is revealed exactly once, at the moment you create it. After that it is masked and you cannot read it back, which is the only honest way to store a credential. The page also carries an endpoint reference, so what you can call sits on the same page as the key you call it with.
A set of changes to how reviews are checked, with one rule underneath all of them: a check can hold something for a human, but it cannot silently destroy it.
A verified researcher's review can now skip the manual queue by passing an automatic quality check. The check scores completeness, and length is only a small part of that. Filling in the per-report detail, the ratings, and the outcomes counts for far more. A long review with an empty form does not pass.
The check has exactly two outcomes: publish, or defer to a human. It never auto-rejects. And a review that names an individual alongside an accusation is always held for a person to read, however complete it is, because that is not a call an automatic check should make.
New detectors flag three things: a burst of negative reviews on one program from a single account, the same text pasted across many programs, and a cluster of brand-new accounts all hitting one program at once. A flagged item goes back to the moderation queue. Nothing is deleted.
The last of those is deliberately only a flag. Being a new account is not misconduct. Plenty of real researchers sign up and immediately review the program that brought them here. So the brigade detector raises a hand for a moderator. It does not unpublish anyone. This is about keeping grades trustworthy, not about punishing people for being new.
Deleting a review no longer destroys it. It is hidden, and a moderator can restore it. The same principle again: the reversible action is the default, and the irreversible one is not something a single click can trigger by accident.
Moderators now have a full review detail view (the whole review, its per-report breakdown, and its history in one place) so the person making a call is looking at everything, not a summary.
You could only leave one review per program, and editing it overwrote what you had said before. That was the wrong shape for a site whose whole point is how programs behave over time.
A review is now an experience with a date you set: when it actually happened, not when you typed it up. You can log several with the same program, and they render as a timeline:
3★ 2023 → 5★ 2025 · improved
That line is the thing we could not show before. A single overwritten rating hides whether a program got better or worse. A timeline makes it plain.
If every experience counted equally, a researcher with five reviews would drown out one with a single review. So when one researcher has several experiences with a program, their most recent counts for 80% and their earlier ones share the remaining 20%. A researcher's voice still counts once, and stacking reviews cannot move a grade.
A program is still only graded once enough distinct researchers have reviewed it: the bar is people, not reviews. Existing grades did not move when this shipped.
The moderation check is on the person, not on every review. If you have already had a review approved, your additional experiences publish straight away. You were vetted the first time, and we are not going to make you wait in a queue to say a program got worse this year.
Deleting your account no longer erases it on the spot.
When you delete your account it is deactivated (signed out and hidden from the site) rather than destroyed the same instant. Your reviews and your standing are not shredded the moment you click a button. That matters because "I deleted it by mistake" and "someone got into my account and deleted it" are both real, and neither should be unrecoverable.
Sensitive account events (deactivations, reinstatements, erasures) are now recorded in an audit trail. If something happened to an account, there is a record of what and when, rather than a silence.
An administrator can reinstate a deactivated account, or fully erase one when erasure is genuinely what is wanted: a real request to be forgotten, or an obligation to honour one. Erasure is still available. It is just no longer the accidental result of pressing delete.
Your researcher profile now shows the programs that have publicly thanked you.
We read this from your verified HackerOne profile's thanks list: the programs that have named you there. Each one that also has a program page here links to it, so a reader can go from "this program thanked you" to what other researchers say about that program in a single click.
It is pulled from a source you already control and have already verified, so there is nothing here to claim and nothing to dispute: either a program has thanked your HackerOne profile or it has not.
There is now a native macOS companion app that mirrors your local research into a BugRater collaboration record. Download it at bugs.maliqbarnard.com/research-tracker.
As your agent turns up findings on your Mac, the app appends them to a collaboration record here. The record is append-only, attributed, and server-timestamped. You are building a log of who found what and when, not a document anyone can quietly rewrite later.
Project contents are encrypted on your Mac before they leave it. What we store is the ciphertext and nothing else. We cannot read your research, and neither can anyone who obtains the database. End-to-end means what it says here.
The app uses a device-authorization flow. You start sign-in on the Mac, then approve the device in your browser, where you are already signed in. You never paste a BugRater password into the app, so the app never holds a credential it could leak.
It also surfaces your BugRater standing and reputation, so you can see where you stand without leaving what you are working on.
This shipped across versions 1.2 through 1.4.
Being able to help moderate used to mean holding every key in the building. That is now fixed.
There was a single is admin flag. You either had it or you did not, and having it meant you could do everything: moderate reviews, edit programs, touch other people's accounts, publish releases. Anyone brought in to help with one job could, by the design of it, do every other job too.
That flag is gone. In its place are named roles (admin, analyst, moderator, editor) and about twenty-two granular permissions underneath them. A moderator has the permissions moderation needs and no others.
A permission does not have to come from your role. It can be granted to you directly, and it can be scoped to a single object (this one program, this one review) rather than the whole class. And a denial always wins: if anything, anywhere, denies a permission, it is denied, whatever a role would otherwise have allowed.
The navigation now reflects your permissions. You no longer see links to things that would refuse you when you clicked them. If a control is not there, it is because it is not yours to use, which is a more honest answer than a locked door.
Three changes to how you move around the site and how you get people into a project.
You can now invite a collaborator without knowing their handle here or asking for an email address. Generate a one-time link mints a URL that seats whoever opens it.
It is a bearer credential, so it is bounded three ways: it works once, it expires after 7 days, and you can revoke it from the same panel the moment it goes somewhere it should not have. The link is shown exactly once, when you make it. Send it the way you would send a password.
Clicking your name used to drop you straight into settings. It now opens a menu: profile, projects, your reviews, BugBadge, settings, sign out. Projects moved out of the top nav and into it, so the main navigation is about the site and your name is about you.
The settings, projects, BugBadge and encryption-key pages ran in a narrow centred column meant for prose, while holding tables and forms. They now run the full width with the sidebar against the left edge, the same posture as the moderation area.
The note on an unencrypted project said this was "not a place to keep your research". That was the wrong emphasis. A project workspace is exactly where the work goes. The correct sentence is that an unencrypted project is readable by us and by anyone who obtains the database, and that turning encryption on removes both the risk and the entry-length cap that existed because of it.
Security releases now go through a review step before anyone sees them.
A release catcher imports a vendor advisory as a draft: invisible on the site, and its credits cannot be claimed. It stays that way until a moderator has read the credits against the vendor's own page and approved it. Approving is the only decision a person makes; a scheduled job running every minute is what actually publishes, stamps the BugRater ID on every credit, and records that it went out.
Splitting the decision from the act buys two things. There is always a window in which pulling a release back costs nothing. And publication happens in exactly one place, with a run log, rather than wherever someone happened to click.
The admin console was capped at a width that left a third of a wide screen empty while tables scrolled inside it, and its summary tiles wrapped six-then-two leaving a dead panel. Both fixed.
The review form now sits in one column instead of having the report editor break out wider than every fieldset around it.
The month field on a report row rendered as an unlabelled empty box in Safari, which does not implement that input type and silently falls back to a plain text field. It now says what it wants.
Notification email now waits a couple of minutes in a queue that a job drains every minute, instead of being sent during your request.
The delay is the point. Edit a comment inside that window and the email that goes out carries the corrected text, because the message is built when it is sent rather than when it is queued. Delete the thing entirely and the email is cancelled rather than arriving to describe something that no longer exists. Five events in two minutes arrive as one message. And a mail server having a bad minute now means a retry instead of a lost notification.
Password resets and address confirmations still send immediately. Nobody wants to wait two minutes for a reset link.
Link a GitHub account and BugRater will find the security advisories you are credited in.
GitHub credits by username, not by printed name, so unlike a vendor advisory there is nothing to claim and nothing to dispute: a verified GitHub link either matches the credited login or it does not.
The index only ever stores credits for accounts our own members have linked. An earlier build mirrored the whole public feed and held credit records for a hundred and thirty people who had never signed up. Those were deleted. Everything else is read, used to keep our place in the feed, and discarded.
The database is now backed up nightly, kept for fourteen days, stored above the web root and unreachable from the internet.
Two details worth stating, because a backup nobody has restored is not a backup. Binary columns are written as hex rather than quoted as text. Quoting them corrupts encrypted report bodies silently, which would ruin the backup in exactly the situation you would need it. And every backup is read back after it is written: if the file is truncated the job reports failure rather than success.
It was tested by restoring a dump into an empty database and comparing row counts table by table, not by checking that a file appeared.
The official response box on a program page was visible to site administrators on any program, including companies that have never claimed a profile here. An administrator could have posted a reply that published as the company's own voice, on a page nobody at that company controls, with no way for a reader to tell the difference.
That bypass is gone. The only person who can post an official response is the verified claimant of that company. There is deliberately no administrator override: if a moderator needs to say something, that is a different thing and needs different wording, not the company's box.
The old account console has been retired. Everything it held now lives in settings, so /account goes straight there instead of showing a page whose only purpose was to tell you it had moved.
Your reviews came with it, with their status, at Settings → Your reviews. That page earns its place: editing a published review sends it back to review, and without somewhere to see that, an edit looks like a deletion.
The footer now uses the full width of the screen and is organised into columns rather than stranding a large gap in the middle of it.
Collaboration records existed, but there was no way to get from seeing another researcher to working with them. Now there is a button on their profile.
You can invite someone to a collaboration you already own, or start a new one in the same action. It becomes an ordinary invitation, and they accept or decline the way they always could.
Three things are built in on purpose. There is an opt-out, on your public profile settings, and when it is set the button does not appear and a hand-crafted request is refused. There is a limit of ten invitations a day, counted across every route so it cannot be side-stepped. And if someone declines, you cannot ask them again on that collaboration unless they come back to it themselves. A button on every profile is one small step from a way to pester people.
Apple's July releases are up: iOS 26.6, macOS Tahoe 26.6 and macOS Sequoia 15.7.8, 843 credits between them. 152 of those have no CVE at all: they are additional recognition, the kind of credit that until now had no identifier anywhere in the world. Every one of them now has a BugRater identifier, and every one of them is claimable.
They are on the home page as cards, and each release lists every line with search, filters and paging, because finding your own name among 376 should not mean scrolling. Filter to additional recognition, or to unclaimed lines only, and search by name, CVE or component.
Claiming opens a dialog that puts the vendor's credited name (exactly as they printed it) above everything else. That is deliberate: a claim is instant and public, so the check that it is really you has to be visible to anyone passing by. If you find a line already claimed, you can dispute it, and the person who claimed it gets to answer before a moderator decides.
These come in automatically now. A scheduled job reads Apple, Microsoft and Chrome security releases and files what it finds as drafts for review. Nothing a machine scrapes gets published without a human looking at it first.
Two fixes to credit claims, one of which mattered.
Restoring a rejected claim did not check whether the credit had been claimed by someone else in the meantime, and rejecting a claim is exactly what frees a credit up. One admin misclick could leave two people holding the same credit, with the release page showing whichever was older and quietly hiding the real holder. The restore now refuses, names who currently holds it, and does the check inside the update itself so there is no window between looking and writing.
Withdrawing a claim also used to be permanent, because nothing could re-claim the credit afterwards. That was survivable when claims waited for approval. Now that a claim is live the moment you make it, withdrawing takes a credit off your profile, so it can be restored.
Separately, the job scheduler no longer lives in the web root. The host runs it by file path, so it never needed to be reachable over the web, and a script that runs every scheduled job in the application is the last thing that should be. It now sits above the document root and refuses to run over HTTP at all.
Settings pages had drifted: two carried a title and two did not, so moving between sections looked like the page was rebuilding itself. They now share one header.
Also: a Preview profile button next to your avatar; the notification bell moved out of the row of text links and in with your account controls, where it reads as part of "you"; the masthead now uses the full width of the screen with the brand and actions in the corners; and adding a missing program moved to the top of the directory, since the directory will never be complete.
Two fixes with teeth. Link previews of the site were serving a stale social card, and the router had no handling for HEAD requests, so uptime monitors and every link unfurler saw a 404 on pages that were fine.
Background work now runs on a schedule that can be seen, paused, rescheduled and run by hand from the admin area, rather than living in a host control panel where nobody looks at it.
A job that is already running is never started twice, a job that fails is caught and reported without taking the rest down, and long jobs save their place and continue on the next tick instead of blocking everything behind them.
If you have verified a HackerOne account, you can now pull your public profile across instead of typing it again.
It is an itemised list, not a sync. Every row shows your current value, HackerOne's value, and a checkbox. Nothing is applied that you did not tick, and an empty field on their side never clears a filled one on yours.
Alongside your details it brings your standing (reputation, rank, signal, impact, percentiles, streak, badges), the other platform handles you list there, and every program that has thanked you with your reputation and rank inside that program. Those get matched against our directory so you can go straight to writing a review.
Imported handles are marked as imported and unverified. HackerOne asserting your GitHub handle is corroboration, not proof.
Collaborations go wrong over attribution: who found the vector, who escalated it, what split was agreed, who submits. Those arguments happen months later, in private, with no record.
A collaboration record is that record: an append-only log attributed to whoever wrote each entry, and a split that binds only once every member has signed. Entries are never edited or deleted. A correction is a new entry, and both stay visible, which is the only reason the log is worth anything in a disagreement.
BugRater does not store your research. You hash your own finding in your browser and only the digest is sent, so revealing the text later proves what you held on that date and a breach of our database leaks nothing exploitable.
Leaving a collaboration does not erase your contributions, and you keep read-only access to the record.
A record of a disagreement, with both sides present.
Either a researcher or a verified program owner can open one. It opens private. The other side is notified and can reply, and nothing can be published until they have. Where no verified owner exists on the other side, a case cannot be published at all: a right of reply that nobody could exercise has not been honoured by letting a clock run out.
Categories are factual and evidence is asked for. Nothing here touches a BugBadge automatically; that is a human decision or it does not happen. Cases age out after two years, like most professional records.
Vendors publish their own security advisories, and those pages name the researcher in public. That is verifiable ground truth that no bounty platform controls, and it covers the work that is invisible everywhere else: open source, direct-to-vendor, and programs with no platform behind them.
Releases now have their own section. Each one lists every CVE and every named recognition in it, and you can claim your own line.
Every credit also gets a BugRater identifier (BR2026-0042-000137), not just the ones a vendor happened to assign a CVE to. Additional recognition and acknowledgements have no identifier anywhere in the world. Now they have one, and it is yours to quote.
Anyone can dispute a claim, with a reason and an explanation. While a claim is disputed it reads as disputed and under review (never as fraudulent, never silently removed), and the person who claimed it is told and can answer before a moderator decides.
A review used to be one summary of a whole relationship with a program. Now every report you filed can be logged on its own row: month, severity, outcome, vulnerability class, asset type, bounty, time to first reply, whether you were credited, and, when it wasn't resolved, why it closed.
Filing a batch is the normal case, so the editor is built for it. Fill one row, then Duplicate last to reuse everything a batch to one program shares, and change only what differs.
The close reason comes from a fixed list of twenty-five, grouped as Scope, Impact, Evidence, Already known, and Process. They are written neutrally on purpose. "Already known internally" is not a complaint, and several of these are entirely reasonable positions for a program to take. The value is in the distribution, not in any single row.
Which is the point: program pages now show why reports get closed there, ranked. A grade tells you how a program felt to work with. This tells you what will get your report closed, which is the question that actually decides where a week of work goes. The panel only appears once a program has at least five public reports, and it is labelled as reported by researchers, not verified by us.
Your grade is unaffected. This records what happened; it does not re-score anything.
We're now BugRater, and moving to bugrater.com. The name says plainly what the platform does: researchers rate the programs they work. Everything you've built here (your profile, reviews, and reputation) comes with us unchanged.
The mobile menu and the leaderboard tables used to overflow their containers on small screens. Both are fixed: navigation now collapses cleanly and the ranking tables scroll and reflow properly on phones. The site is finally comfortable to use on mobile.
Account security caught up with the rest of the platform. You can now reset a forgotten password, verify your email address, and delete your account and its data whenever you want. These are table stakes for a site researchers trust, and they're now in place.
We built our own analytics instead of reaching for a third-party tracker. It's privacy-respecting by design: IP addresses are hashed, Do Not Track is honoured, and nothing is shared with outside services. We get the numbers we need to improve the platform without following anyone around the web.
There's now a read-only JSON API for programs, rankings, stats, and reviews. Access is key-authenticated, and each key comes with generated documentation: an api.md with your key already baked into the examples. You can pull our data into your own tooling in a few minutes.
You can now generate personalized invite links for researchers you want to bring in. Each link carries a custom landing page and tracks its own clicks and signups. It makes growing the community a deliberate, measurable thing rather than a broadcast.
Reviews are now a conversation. You can comment on them, share them with a clean link, and get notified when there's activity on your reviews or profile. It keeps you in the loop without having to check back manually.
A grade rarely tells the whole story. You can now publish a full write-up alongside a review: the context, the back-and-forth, and how it resolved. It gives other researchers the detail they need to decide whether a program is worth their time.
Reviews can now break down report by report, so the experience is documented at the level it actually happened. Each block has a public/private toggle: sensitive details can stay private while a dispute is arbitrated. That way disagreements get mediated fairly without airing everything in public first.
Every review now goes through one structured form, so a rating means the same thing across programs. From those answers we compute a letter grade, A+ down to F, and roll them up into a program scorecard. It makes programs directly comparable at a glance instead of buried in prose.
Researchers now have verified platform accounts on BugRater. You can import your HackerOne stats (reputation, rank, and signal) so your standing follows you here instead of starting from zero. Your review history lives on your profile, giving programs and peers an honest picture of who's rating them.