Το νέο πρόγραμμα bug bounty του GitHub αλλάζει τους κανόνες για security researchers

Το νέο πρόγραμμα bug bounty του GitHub αλλάζει τον τρόπο με τον οποίο η πλατφόρμα οργανώνει τις αναφορές ευπαθειών και τις αμοιβές των ερευνητών. Στην ανακοίνωση της 22ας Ιουλίου, η GitHub περιγράφει μια μόνιμη, προσκαλούμενη VIP διαδρομή για ερευνητές με σταθερά υψηλής ποιότητας ευρήματα, παράλληλα με ένα δημόσιο πρόγραμμα που αποκτά σαφείς, σταθερές αμοιβές ανά severity. Για τους developers και τους security researchers, το πρακτικό μήνυμα δεν είναι «στείλε περισσότερα reports»: είναι να επενδύσεις σε αναπαραγώγιμη απόδειξη, σωστή εκτίμηση impact και καθαρή τεκμηρίωση.

Οι νέοι όροι εφαρμόζονται σε αναφορές που υποβάλλονται από τις 27 Ιουλίου 2026. Η GitHub δηλώνει ότι το υπάρχον backlog θα αξιολογηθεί με το προηγούμενο μοντέλο, ώστε μια αναφορά που είχε ήδη κατατεθεί να μη βρεθεί ξαφνικά σε διαφορετικό πλαίσιο. Αυτό είναι σημαντικό για όσους έχουν ενεργές αναφορές ή σχεδιάζουν υπεύθυνη γνωστοποίηση τις επόμενες ημέρες.

Τι αλλάζει στις αμοιβές

Στο δημόσιο πρόγραμμα, η GitHub περνά σε σταθερά ποσά: 250 δολάρια για low, 2.000 για medium, 5.000 για high και 10.000 για critical findings. Η αλλαγή αντικαθιστά τα εύρη αμοιβών με ένα καθαρό payout table. Δεν καταργεί τη δυνατότητα bonus για εργασία που ξεχωρίζει, αλλά μειώνει την ασάφεια που είχε ένας ερευνητής πριν αποφασίσει πόσο χρόνο αξίζει να διαθέσει σε ένα target.

Παράλληλα, το νέο VIP πρόγραμμα είναι private και invite-only. Για όσους πληρούν τα κριτήρια, η GitHub αναφέρει υψηλότερες αμοιβές, ταχύτερες απαντήσεις και στενότερη συνεργασία με την security engineering ομάδα της. Το αντίστοιχο table ξεκινά από 1.000 δολάρια για low, φτάνει 7.500 για medium, 20.000 για high και 30.000+ για critical. Η πρόσβαση δεν προκύπτει από τον απόλυτο αριθμό reports: η GitHub συνδέει την πρόσκληση με αποδεδειγμένα findings, όπως ένα critical, δύο high, τέσσερα medium ή επτά low.

Γιατί η GitHub βάζει «σήμα» πριν από τον όγκο

Η εταιρεία συνδέει την αναδιάρθρωση με τη διαχείριση μιας αυξανόμενης ουράς αναφορών. Στο δημόσιο πρόγραμμα εισάγεται HackerOne signal requirement: όσοι δεν έχουν ακόμη φτάσει το σχετικό threshold ξεκινούν με έως τέσσερις υποβολές για να χτίσουν ιστορικό. Η GitHub τονίζει ότι δεν πρόκειται για κλείσιμο της πόρτας σε νέους ερευνητές. Στην πράξη όμως η πολιτική μεταφέρει το βάρος από την αποστολή πολλών ασαφών reports στη δημιουργία λίγων, πλήρως ελεγμένων αναφορών.

Η διάκριση αυτή έχει νόημα και έξω από το συγκεκριμένο πρόγραμμα. Ένα report που απλώς περιγράφει μια θεωρητική αδυναμία είναι δύσκολο να τριμαριστεί. Ένα report που δείχνει ακριβώς το asset, τις προϋποθέσεις, τα βήματα αναπαραγωγής, το αναμενόμενο και το πραγματικό αποτέλεσμα, καθώς και το ρεαλιστικό impact, επιτρέπει στην ομάδα ασφαλείας να επιβεβαιώσει το εύρημα και να το προτεραιοποιήσει. Αυτό μειώνει και τον χρόνο ping-pong ανάμεσα σε researcher και triager.

Πώς να προετοιμάσεις μια αναφορά που αντέχει σε triage

Ξεκίνα από scope και κανόνες

Πριν δοκιμάσεις οτιδήποτε, διάβασε το scope, τα out-of-scope σημεία και τους κανόνες safe harbor του προγράμματος. Μην υποθέτεις ότι κάθε subdomain, test environment ή συμπεριφορά τρίτου προμηθευτή επιτρέπεται. Η προηγούμενη επίσημη τοποθέτηση της GitHub δίνει έμφαση στην κοινή ευθύνη: ο ερευνητής χρειάζεται να ακολουθεί τους κανόνες του target και η πλατφόρμα να εξηγεί με συνέπεια τον τρόπο αξιολόγησης.

Κάνε το proof of concept μικρό και ασφαλές

Το proof of concept πρέπει να αποδεικνύει την ευπάθεια με το ελάχιστο αναγκαίο impact. Απόφυγε την άντληση πραγματικών δεδομένων, την επίμονη πρόσβαση ή επιθετικούς αυτοματισμούς όταν αρκεί ένα ελεγχόμενο παράδειγμα. Κράτησε τις ακριβείς εκδόσεις, τα headers ή τα requests που χρειάζονται και σημείωσε τις προϋποθέσεις του λογαριασμού. Όπου είναι δυνατό, ένα σύντομο βίντεο ή ένα καθαρό sequence βημάτων είναι καλύτερο από δεκάδες screenshots χωρίς συνοχή.

Εξήγησε impact, όχι μόνο μηχανισμό

Η ίδια τεχνική αδυναμία μπορεί να έχει πολύ διαφορετική σοβαρότητα ανάλογα με το ποιος ελέγχει τα δεδομένα, αν απαιτείται interaction, ποιοι χρήστες επηρεάζονται και αν υπάρχει πρακτική αλυσίδα εκμετάλλευσης. Γράψε τι μπορεί να κάνει ένας επιτιθέμενος, τι δεν απέδειξες και ποια στοιχεία θα βοηθούσαν την ομάδα να αναπαράγει το σενάριο. Έτσι η αναφορά είναι χρήσιμη ακόμη κι αν η τελική severity διαφέρει από την αρχική σου εκτίμηση.

Τι σημαίνει για τις ομάδες ανάπτυξης

Για μια ομάδα προϊόντος, η είδηση είναι υπενθύμιση ότι ένα καλό vulnerability intake δεν είναι απλώς email inbox. Χρειάζεται owner, SLA για επιβεβαίωση, ασφαλές κανάλι επικοινωνίας, σαφές scope και τρόπος να μετατρέπεται ένα verified report σε fix, regression test και ενημέρωση. Η ποιότητα του triage επηρεάζει και την ποιότητα των reports που θα λάβεις αργότερα: όταν οι κανόνες είναι καθαροί, οι ερευνητές μπορούν να επενδύσουν στον σωστό έλεγχο αντί σε εικασίες.

Αν θέλετε να εξασκήσετε αυτή τη διαδικασία εσωτερικά, ένα μικρό project που καταγράφει security findings, reproduce steps και remediation status μπορεί να γίνει χρήσιμο δείγμα δουλειάς μαζί με άλλα projects για developer portfolio. Η αξία του δεν βρίσκεται στο να «παριστάνει» ένα πρόγραμμα bug bounty, αλλά στο να κάνει ορατή τη διαδρομή από την αναφορά έως το verified fix.

Το νέο μοντέλο της GitHub είναι συνεπώς μια σαφής κατεύθυνση: λιγότερη τριβή από χαμηλής ποιότητας υποβολές και περισσότερος χώρος για ερευνητική δουλειά με αποδείξεις και ουσιαστικό αντίκτυπο. Για όποιον στέλνει ή διαχειρίζεται vulnerability reports, το καλύτερο επόμενο βήμα είναι απλό: διάβασε τους κανόνες, δοκίμασε το εύρημα με ασφάλεια και γράψε το report ώστε ένας άλλος άνθρωπος να μπορεί να το επαναλάβει χωρίς να μαντεύει.

Επίσημες πηγές

• GitHub: Next chapter — restructuring the bug bounty program
• GitHub: Quality, shared responsibility and the bug bounty program