Wat de badge feitelijk vastlegt
Een verified commit-badge is het resultaat van een handtekeningcontrole, geen karakterreferentie. Als je op GitHub “Verified” naast een commit ziet, vertelt het platform je één smal ding: het heeft een cryptografische handtekening bij die commit gecontroleerd en de controle is geslaagd.
GitHub markeert een ondertekende commit als Verified wanneer de handtekening met succes is geverifieerd. Bron
De badge hangt aan een commit, niet aan een persoon. Het is ook geen live beveiligingsindicator voor het account dat je vandaag bekijkt. Het verificatieresultaat is een historisch record van een controle die op een bepaald moment plaatsvond.
Zodra de verificatie is vastgelegd, kan het record blijven bestaan, zelfs nadat een ondertekeningssleutel is ingetrokken of verlopen. Bron
Die persistentie is belangrijk voor onderzoekers. Een badge kan zichtbaar blijven op een oude commit, zelfs nadat de ondertekeningssleutel die hem produceerde is ingetrokken of verlopen. Een ingetrokken sleutel wist de badge niet met terugwerkende kracht, en een verlopen sleutel maakt de oude commit niet ongeverifieerd. De badge vertelt je dus dat de handtekening klopte toen deze werd vastgelegd, niet dat de sleutel nog vertrouwd is, dat het account nog veilig is of dat de huidige accounthouder dezelfde persoon is die heeft ondertekend.
Stap 1: Scheid de drie vragen
Wanneer iemand een verified commit aanvoert als bewijs voor een ontwikkelaarsclaim, worden meestal drie verschillende vragen door elkaar gehaald. Haal ze uit elkaar voordat je iets beoordeelt.
| Vraag | Wat een verified badge kan aantonen | Wat het op zichzelf niet kan aantonen |
|---|---|---|
| Is deze commit ondertekend en geverifieerd? | GitHub heeft een geslaagde handtekeningverificatie voor die commit vastgelegd. | Wie de code heeft geschreven, of de code ergens goed voor is. |
| Wie beheert het account nu? | Niets direct. De badge is gekoppeld aan de commit, niet aan de huidige logincontrole. | Of dezelfde persoon nog eigenaar is van het account, of het account van eigenaar is veranderd. |
| Is deze persoon wie hij zegt te zijn, of werkt hij waar hij zegt te werken? | Niets direct. | Identiteit, dienstverband of bevoegdheid om namens een organisatie te spreken. |
Een verified badge beantwoordt alleen de eerste rij. De tweede en derde rij vereisen afzonderlijk bewijs. Dit is dezelfde discipline als beschreven in onze gids over wat openbare profielsearch wel en niet over iemand kan onthullen: een publiek artefact is een aanwijzing, geen conclusie.
Stap 2: Lees de commit, niet alleen de badge
Een badge is een snelkoppeling, en snelkoppelingen verbergen context. Open de commit zelf en kijk naar wat er rond het verificatieresultaat staat.
- Het veld commit author en het veld committer. Dit zijn metadata-velden, geen bewijs van wie de code heeft getypt. Ze kunnen in veel workflows op alles worden gezet.
- De getoonde ondertekeningssleutel. GitHub koppelt een verificatieresultaat aan een sleutel. Let op of de sleutel wordt gepresenteerd als behorend bij een account, een organisatie of een bot.
- De repository en branch. Een verified commit in een persoonlijke fork heeft minder organisatorisch gewicht dan een die is samengevoegd in een onderhouden project, maar geen van beide bewijst een dienstverband.
- De datum. Een oude verified commit is een historisch gegeven. Het zegt niets over de huidige beveiligingsstatus van het account.
Geen van deze velden, alleen of samen, stelt vast dat de accounthouder de persoon is die in een biografie wordt genoemd of dat de persoon werkt waar een profiel zegt dat hij werkt.
Stap 3: Controleer de huidige accountcontrole afzonderlijk
Een verified commit is een record over een commit. Accountcontrole is een aparte vraag, en openbare pagina’s beantwoorden die zelden direct. Wat je kunt doen, is zoeken naar consistentie en continuïteit.
- Vergelijk de openbare geschiedenis van het account in de loop van de tijd. Een lange, samenhangende geschiedenis van bijdragen is een aanwijzing, geen bewijs.
- Zoek naar dezelfde handle of weergavenaam op andere platforms. Overeenkomende handles zijn een aanwijzing. Ze zijn geen bewijs dat de accounts bij dezelfde persoon horen, omdat handles niet uniek zijn across platforms en kunnen worden hergebruikt of gekaapt.
- Behandel profieltekst, avatars en biografieën als claims die de accounthouder doet, niet als geverifieerde feiten.
Als iemand een verified badge presenteert als bewijs dat hij nu een account beheert, is dat een categoriefout. De badge meet niet de huidige loginbeveiliging en bevestigt niet dat de persoon die met je spreekt de accounthouder is.
Stap 4: Zoek naar onafhankelijk bewijs
Onafhankelijk bewijs is alles wat niet afkomstig is van hetzelfde account dat de claim doet. Voorbeelden zijn een eigen gepubliceerde lijst van teamleden door een organisatie, een sprekerslijst op een conferentiesite of een repository die wordt onderhouden onder een organisatieaccount met een eigen openbaar record. Zelfs deze zijn corroboratie, geen identiteitsbewijs. Het is jouw taak om te bepalen hoeveel gewicht de combinatie verdient, niet om zekerheid te verklaren.
Beslissingstabel: hoeveel gewicht geef je een verified badge
| Situatie | Redelijke lezing | Resterende onzekerheid |
|---|---|---|
| Badge aanwezig, sleutel nog aan het account gekoppeld, recente commit | De handtekening is geverifieerd en de sleutelkoppeling is actueel. | Bewijst niet dat de persoon het account beheert of de code heeft geschreven. |
| Badge aanwezig, sleutel ingetrokken of verlopen | De verificatie is vastgelegd toen deze plaatsvond. | Zegt niets over huidig sleutelvertrouwen of accountbeveiliging. |
| Badge alleen aanwezig op oude commits | Historisch verificatierecord. | Geen implicatie over huidige activiteit of controle. |
| Badge afwezig | Geen geverifieerde handtekening op die commit. | Afwezigheid is geen bewijs van kwaadwilligheid; veel legitieme workflows ondertekenen niet elke commit. |
| Badge plus overeenkomende handle elders | Een aanwijzing die het volgen waard is. | Handles zijn niet uniek; de accounts kunnen bij verschillende personen horen. |
| Badge plus vermelding in organisatieprofiel | Corroboratie van een mogelijke affiliatie. | Bewijst geen dienstverband of bevoegdheid om namens de organisatie te spreken. |
Veelgemaakte fouten
- De badge als identiteitscontrole behandelen. Het is een handtekeningsresultaat, geen achtergrondcheck.
- Aannemen dat een historische badge de huidige accountbeveiliging bewijst. Het record kan blijven bestaan nadat een sleutel is ingetrokken of verlopen, dus de badge is geen live statuslampje.
- Metadata van author en committer verwarren met auteurschap. Deze velden zijn claims in het commit-object, geen geverifieerde feiten over wie de code heeft geschreven.
- Overeenkomende handles als bewijs van één persoon zien. Dezelfde handle op twee platforms is een aanwijzing. Het is geen bewijs dat de accounts bij dezelfde persoon horen.
- Een badge op een fork lezen als organisatorische goedkeuring. Een verified commit in een persoonlijke fork stelt niet vast dat een organisatie het werk heeft beoordeeld of goedgekeurd.
- Aannemen dat een niet-ondertekende commit verdacht is. Veel legitieme bijdragers en workflows ondertekenen niet elke commit.
Checklist voor zelfbeoordeling
Voordat je een ontwikkelaarsclaim herhaalt die op een verified badge rust, doorloop je deze checklist.
- Heb ik de commit geopend en de author, committer, sleutel, repository en datum genoteerd?
- Heb ik “handtekening geverifieerd” gescheiden van “accountcontrole” en van “identiteit of dienstverband”?
- Heb ik gecontroleerd of de sleutel nog aan het account is gekoppeld, of dat het record kan blijven bestaan na intrekking of verlopen?
- Heb ik ten minste één bron gezocht die niet van hetzelfde account afkomstig is?
- Heb ik overeenkomende handles beschreven als een aanwijzing in plaats van als bewijs van één persoon?
- Heb ik vermeden te beweren dat de badge huidige beveiliging, auteurschap of dienstverband bewijst?
Je eigen voetafdruk beschermen
Als je commits ondertekent, onthoud dan dat een verified badge een record is dat je achterlaat. Het kan de sleutel die het produceerde overleven. Voordat je een ondertekeningssleutel intrekt of roteert, bepaal je hoe je wilt dat oude commits worden gelezen, en houd je eigen notities bij over welke sleutels wanneer zijn gebruikt. Als je openbare profielen onderhoudt, bekijk dan de handles die je in de loop van de tijd hebt gebruikt en controleer of oude accounts nog naar je verwijzen. Een gebruikersnaamzoekopdracht zoals TraceSeek kan je helpen je eigen bekende openbare handles te bekijken across 3.000+ platforms; de eerste scan is gratis en vereist geen registratie of login, en resultaten worden doorgaans binnen 20–30 seconden teruggegeven. Zie de uitvoer als een lijst met aanwijzingen om te beoordelen, niet als een verificatie van identiteit. TraceSeek wijzigt geen platforminstellingen, garandeert geen match en verifieert niemands identiteit. Zie onze methodologie voor hoe we bewijs en beperkingen framen.
Belangrijkste feiten
- GitHub markeert een ondertekende commit als Verified wanneer de handtekening met succes is geverifieerd.
- Zodra de verificatie is vastgelegd, kan het record blijven bestaan, zelfs nadat een ondertekeningssleutel is ingetrokken of verlopen.
- Een verified commit-badge is een handtekeningsresultaat voor een specifieke commit, geen bewijs van huidige accountcontrole of identiteit.
- Overeenkomende openbare identificatoren across platforms zijn aanwijzingen, geen bewijs dat de accounts bij dezelfde persoon horen.
- TraceSeek dekt 3.000+ platforms en biedt een gratis eerste scan zonder registratie of login.