Bugbountyplatform HackerOne ontslaat 12 procent van werknemers, ook in Nederland

Bugbountyplatform HackerOne ontslaat zo'n twaalf procent van zijn personeelsbestand. Daarbij worden ook Nederlandse werknemers getroffen, maar het is niet bekend hoeveel. Volgens het bedrijf doen nieuwe projecten het minder goed dan gedacht en moet het daarom krimpen.

HackerOne schrijft in een update dat twaalf procent van de werknemers van het bedrijf wordt ontslagen. Naast ontslagen op het hoofdkantoor in San Francisco worden er ook werknemers in het Groningse hoofdkantoor ontslagen. HackerOne zegt in een reactie aan Tweakers nog niet te kunnen zeggen om hoeveel werknemers het in totaal gaat en hoeveel ontslagen er precies in Nederland vallen. Details voor werknemers volgen volgens het bedrijf nog.

Het bugbountyplatform is vorig jaar flink uitgebreid met nieuwe werknemers die aan nieuwe producten werken. Het bedrijf nam bijvoorbeeld codereviewtool PullRequest over en introduceerde nieuwe tools voor pentests. Het bedrijf zegt nu dat klanten minder snel geneigd zijn die producten af te nemen. "De nieuwe producten die we op de markt brachten, deden het minder goed dan we hadden verwacht", zegt het bedrijf. "Onze strategie om personeel te werven en nieuwe producten te maken bleek daardoor te groot en daarom moeten we nu herstructureren." Het is niet duidelijk welke tools HackerOne daarmee precies bedoelt.

HackerOne is een bugbountyplatform waar bedrijven zich bij kunnen aansluiten. HackerOne neemt dan het responsibledisclosurebeleid voor rekening, zoals het opstellen van de scope of het uitbetalen van de beloningen. Het is het grootste bugbountyplatform in die soort. Het bedrijf verwacht dat de ontslagen eenmalig zijn.

Reacties (27)

[Floort]

Een klein beetje off-topic, maar de laatste alinea gebruikt onterecht de term 'responsibledisclosurebeleid'.De meeste programma's bij HackeOne, ook degenen die geen beloningen betalen, leggen non-disclosure-voorwaarden op aan degenen die iets willen melden. Dat is geen responsible disclosure. Responsible disclosure is juist het wel publiceren van bevindingen, maar op een manier waarop stakeholders zoveel als redelijk is de kans krijgen om voor publicatie problemen op te lossen. De meer correcte term daarvoor is overigens coordinated vulnerability disclosure (CVD). Maar bij HackerOne vind je dat dus bijna niet.

[TijsZonderH]

Ik heb het nog eens extra overlegd met de eindredactie, maar we blijven responsible disclosure gebruiken als term voor 'het melden van kwetsbaarheden aan bedrijven of overheden'. Ik ben bekend met de discussie dat CVD een betere term zou moeten zijn, maar voorlopig blijft responsible disclosure nog wel de meest gangbare term en is de nuance zo minimaal dat we daarvoor blijven kiezen. Zo noemen we Tweakers' eigen beleid ook. Daarmee maak ik het wel vooral een semantische discussie maar ook in verband met de duidelijkheid tegenover lezers vind ik het te verdedigen RD te blijven gebruiken, als eigenlijk CVD wordt bedoeld.

[Floort]

Ik wilde redactie en bedrijfsvoering niet door elkaar halen, maar het Tweakers beleid is best rommelig (conflicterende voorwaarden op eigen pagina versus die bij Intigriti) en echt geen RD beleid. En ik had verwacht dat keuzes in de bedrijfsvoering niet perse relevant zouden zijn voor de journalistiek-inhoudelijke keuzes. Het gaat me bovendien niet om de verwarring tussen RD en CVD. Wat mij betreft is CVD de wat meer volwassen variant waarbij elementen die onder RD impliciet waren veel duidelijker zijn uitgewerkt.

Het gaat me om de verwarring die ontstaat waarbij bedrijven zeggen: als je een gevaarlijke situatie ziet mag je ons alleen waarschuwen als je beloofd nooit aan iemand te vertellen wat je hebt gezien tenzij we daarvoor toestemming geven. Dat is geen RD en geen CVD. Dat is wel wat verreweg de meeste programma's bij HackerOne doen en dat is ook wat Tweakers doet.

[Reactie gewijzigd door Floort op 29 juli 2024 11:26]

[Ircghost]

Ik denk dat je een eigen definitie creeërt van hoe jij RD graag wilt zien. RD betekent dat de ontdekker van het issue het op een verantwoordelijke manier meldt. Verantwoordelijk betekent dat je het meldt aan de partij die het kan oplossen (of laten oplossen i.e. NCSC). Over het algemeen is het (initieel) verantwoordelijker om het aan een bedrijf zelf te melden zodat ze het kunnen fixen voordat het publiek bekend wordt.

Natuurlijk is het nog beter als het later ook publiek wordt gemeldt, maar dat zou voor mij geen voorwaarde moeten zijn van RD.

[Reactie gewijzigd door Ircghost op 29 juli 2024 11:26]

[Chiwn]

Mogelijk maak ik me nu ook schuldig aan de definitie verwarren met hoe ik het graag zie, maar bij disclosure in RD denk ik ook aan public disclosure. Puur melden aan de verantwoordelijke partij waarbij zij zichzelf de ruimte gunnen er nooit iets mee te doen en jou te verbieden erover te publiceren (wat ik ook het idee heb dat intussen de standaard is geworden), tja... dat hadden ze dan beter coordinated doofpot disclosure kunnen noemen.

[Floort]

Dat is volkomen redelijk. ISO/IEC TR 5895:2022 noemt het de "release stage" (public disclosure) en de hele standaard gaat uit van het toewerken naar die uiteindelijke publicatie. Je leest het dus precies goed.

[Floort]

Het is een beetje flauw om me te verwijten dat ik een eigen definitie creëer van hoe ik RD graag wilt zien. Ik zie niet echt hoe ik anders het initiatief had kunnen nemen. Had ik het zo moeten maken zoals ik het niet graag zie?
Maar als je het niet van mij aanneemt, kijk dan naar het NCSC (zie ook mijn reactie hieronder ergens) die expliciet zegt: "Openbaarmaking van kennis over de kwetsbaarheden na het verhelpen is het uitgangspunt van het proces.". Je mag ook kijken naar de MPCVD lifecycle zoals gespecificeerd in ISO/IEC TR 5895:2022 waarbij die D van disclosure ook weer onderdeel van het proces is (kost wel geld om te lezen). Het is niet alsof ik zelf even wat bedacht heb en dat aan anderen opleg. Het is overheidsbeleid en een ISO-standaard. Er hebben allerlei andere mensen veel harder aan gewerkt dan ik.

Een beleid waarbij melders een geheimhoudingsverplichting wordt opgelegd om überhaupt te mogen melden is geen RD of CVD omdat dat lijnrecht ingaat tegen het uitgangspunt van het proces.

Edit n.a.v. de latere toevoeging:
Tweakers zou de conflicterende non disclosure voorwaarde van Intigrity kunnen schrappen en een deadline (bijv. max 3 maanden) kunnen toevoegen waarna publicatie zoiezo mag of het aanpassen van voorwaarde naar een beleefd verzoek. Dan hoeft iemand die uiteindelijk wil publiceren dat niet te doen zonder eerst Tweakers te informeren.

[Reactie gewijzigd door Floort op 29 juli 2024 11:26]

[Orangelights23]

In de praktijk wordt het responsible disclosure beleid ingezet tussen melder (bug bounty hunter) en ontvanger (organisatie). Heeft dus niet veel te maken met het publiekelijk bekend maken van een gevonden kwetsbaarheid.

[Floort]

Ik snap niet helemaal wat je bedoelt, maar in de praktijk zie ik dat RD/CVD beleid best vaak verkeerd wordt ingezet. Waardoor bug bounties en CVD beleid door elkaar gehaald worden en organisaties ongepast voorwaarden opdringen aan degenen die opmerken dat er problemen zijn. Zo ook in jouw reactie waarbij je een melder onder een RD beleid een bug bounty hunter noemt. Dat klopt niet.

[Orangelights23]

Responsible disclosure: een ethisch hacker vindt een kwetsbaarheid en d.m.v. dit beleid kan dit eenvoudig gemeld worden aan de organisatie. Eens dat CVD en RD door elkaar gehaald worden, maar zoals ik schreef, RD beleid wordt vaak gekoppeld aan het kunnen melden van een kwetsbaarheid aan een organisatie. En dat is ook hoe HackerOne en Integrity dit communiceren (ben zelf CISO bij een bedrijf dat samenwerkt met Integriti).

[Floort]

Bij klanten van Integriti zie ik dit ook vaak fout gaan. Wat je omschrijft over responsible disclosure is een veel te beperkte blik van hoe responsible disclosure is opgezet. Later is dat beter uitgewerkt als CVD, met zelfs een ISO-standaard. Maar precies de verwarring die je hier laat zien is een reden waarom zoveel mensen denken dat de RD en/of CVD kunnen misbruiken om onredelijke voorwaarden op te leggen aan melders.

Ik krijg er de kriebels van om een autoriteits-argument te gebruiken, maar lees eens de CVD leidraad van het NCSC. Daarin staat bijvoorbeeld het volgende:

Doel van Coordinated Vulnerability Disclosure
Het doel van CVD is om bij te dragen aan de veiligheid van ICTsystemen door kennis over kwetsbaarheden te delen. In deze praktijk wordt de kennis gedeeld met een of meer mogelijk kwetsbare organisaties om zo in samenwerking met de melder te komen tot een gezamenlijke oplossing van de gevonden kwetsbaarheid. Om schade zoveel mogelijk te beperken of te voorkomen is het hierbij van belang dat de getroffen organisaties voldoende tijd hebben om kwetsbaarheden te verhelpen of systemen te beschermen. Openbaarmaking van kennis over de kwetsbaarheden na het verhelpen is het uitgangspunt van het proces.

Let in het bijzonder ook op de laatste zin. En het NCSC zegt dat niet alleen. Ik zeg het ook. Je zal bijvoorbeeld in dat document tweemaal mijn naam zien staan. Als mede-initiatiefnemer van RD toen het NCSC nog GovCERT was weet ik vrij goed wat de intentie is geweest van mijzelf.

[Orangelights23]

Wat ik schrijf, ik ben het eens met je, maar dit is weer een geval waarbij de praktijk niet zo gaat als theoretisch bedacht. Leuk overigens dat je meegeschreven hebt!

[Floort]

Ik wil toch nog heel duidelijk zijn: in de praktijk gaat het vaak anders omdat bedrijven er belang bij hebben om bijvoorbeeld problemen stil te houden. Prima als een bedrijf daarin wil afwijken, maar noem dat geen RD of CVD omdat dat heel wat anders is. En meestal gaat dat goed. Totdat het niet goed gaat omdat je bijvoorbeeld iets gemeld hebt bij een gemeente en een leverancier gaat opeens dreigen met juridische stappen als je zonder toestemming wilt publiceren. Een goed CVD beleid is nodig om melders te beschermen. Veel bug bounty platformen doen mee aan het scheppen van verwarring omdat ze klanten ook willen laten meeliften op de positieve connotaties van CVD (of de verplichting onder de BIO), maar niet de ongemakkelijke boodschap willen vertellen dat daar ook verantwoordelijkheden en transparantie bijhoren. En als ze er niet actief aan meedoen voelen ze wel de marktdruk en willen ze hun klanten vaak niet corrigeren als ze dit fout doen.
En hoewel het veel fout gaat is de suggestie dat het in de praktijk nu eenmaal anders gaat dan in theorie wel erg neerbuigend. Het kan namelijk in de praktijk ook gewoon goed gaan. Bij het opzetten van dit initiatief heb ik juist een aantal risicomijdende bedrijven uitgekozen (banken en telco's had ik zo ingeschat) en tot mijn verbazing zijn deze twee sectoren beiden (vrijwel) geheel meegegaan. Op misschien een enkele uitzondering na kan ik me dus niet voorstellen dat anderen dat voorbeeld niet ook zouden kunnen volgen. Zonder degelijke onderbouwing ben ik dus niet zo gevoelig voor het standpunt dat het noodzakelijk is om onterecht te doen alsof je een CVD beleid hebt.

[kodak]

Ik ben daarom wel benieuwd naar de redenen waarom de resultaten tegen vallen. Het kan bijvoorbeeld zijn omdat de voorwaarden die gesteld worden niet passen bij wat de 'bughunters' willen bereiken. Vaak gaan dit soort projecten om stil houden van problemen en daarvoor dan een beloning in goederen of geld geven. Maar het idee achter het 'bughunten' naar risico's is vaak juist dat er door anderen van geleerd kan worden de fouten niet opnieuw te maken.

[Floort]

Hoewel ik principiële bezwaren heb tegen het verwateren van het begrip responsible disclosure en me zorgen maak om de bescherming van (arbeids)rechten van hackers in veel bug bounty programma's heb ik niet het idee dat veel hackers zich daar zichtbaar zorgen over maken. Ik vermoed dat eerder de zware concurrentie tussen platformen lastig zijn. Voor zowel hackers als voor bedrijven die managed bounties willen afnemen is het niet meteen duidelijk hoe de verschillende platformen beter zijn. En voor de hele bug bounty sector zou het me niet verbazen als iedereen begint te voelen dat de waardering van bug bounties wat naar beneden wordt bijgesteld. Het kan nog steeds een heel nuttig onderdeel zijn van een security programma, maar ik zie teveel plekken waar het vooral als PR-instrument wordt ingezet of waar de waarde enorm overschat wordt. Een beetje correctie daarin zou volgens mij op de lange termijn wel gezond zijn.

[kodak]

De onzichbaarheid van het belang lijkt me geen redelijke grens alsof het dus maar niet belangrijk is. Deze bedrijven leven bij het verdienmodel alsof hun eenzijdige eisen tot geheimhouding meerwaarde heeft door er vanuit te gaan dat er altijd wel een (steeds vernieuwende) groep is die genoegen met die eisen en de daarop aangepaste beloning neemt. Maar ze sluiten daarmee om te beginnen al de groep uit doe zich niet neer legt bij dit soort eisen en de (tijdelijke) beloning blijft niet zomaar genoeg bij de constante eenzijdige eisen om als bedrijven controle en macht te houden over de deelnemers. Die deelnemers leven niet in een constante wereld waarbij ze niets wijzer worden over gepast belonen en waarde van vrijheid om over ontdekkingen te spreken. Hooguit nemen de bughunters die actief meedoen er genoegen mee. En dat is juist niet zomaar genoeg als je juist uit bent op verbetering.

[hstoker]

Staat in de blog:

However, we did not anticipate the degree to which the overall economic situation is affecting us, with smaller companies running out of money and larger ones taking longer to make purchasing decisions. The new products we brought to market didn’t perform the way we wanted them to.

Dus tegenvallende resultaten aan de business side.

[kodak]

Als bedrijf je niet uitgekomen verwachtingen wijten aan iets algemeens als een economische situatie legt niet uit hoe hun verwachtingen realistisch waren. Het klinkt namelijk niet als een realistisch verdienmodel om kennelijk zo zwaar op nieuwe producten te leunen dat als de economie tegen zit je al flink wat personeel moet laten vertrekken.

[himlims_]

ervaring leert dat je een situatie kunt melden; (te) vaak op de stapel beland en geen response krijg.
(info uit https://www.digitaltrustcenter.nl/securitytxt)

Zodra dit imago schaadt (lees; je publiceert jouw bevindingen) het 'ineens' allemaal wel kan.

[ags7]

Los van de discussie die nu ontstaat wil ik je wel bedanken voor het delen van je reactie, ik heb deze en je andere reacties hieronder gelezen. Erg leerzaam en inzichtgevend. Ik vind dit het mooie aan Tweakers, volwassen discussies tussen mensen die verstand hebben van zaken en alhoewel ik vaker lees dan reageer, ben ik toch altijd blij om de verschillende reacties te lezen. Juist omdat dit beide bijdraagt aan mijn kennis en ik denk vele anderen met mij.

[ataryan]

een onafhankelijk security bedrijf is naar mijn idee van de gehele IT de moeilijkste sector om actief te zijn
erg seizoensgevoelig en vaak een omgekeerde en vroegere curve tov de rest van de markt ontwikkelingen
het getuigd van erg veel lef, maar vaak eindigt het toch dan weer in een sellout danwel selloff of beide....

[Puremonk]

Wellicht dat concurrentie die populairder bij bounty hunters is, hier ook invloed op heeft gehad.

[Tomino]

Bijzonder dat er minder aandacht is voor dun dienstverlening, ik zou toch denken dat met de (aanstaande) NIS2 wetgeving juist méér interesse zou zijn. Mogelijk vallen de resultaten in de USA tegen, en niet hier?

[jaapzb]

We zien overal in de technische sector ontslagen vallen. Er word uitgegaan van een wereldwijde economische krimp. Bij een krimpende economie wordt er in veel budgetten gesneden en security wordt toch vaak minder belangrijk geacht dan andere onderdelen van de bedrijfsvoering, er is dus een aardige kans dat daar minder aandacht aan besteed wordt op het moment dat er minder geld uit te geven is.

[Reactie gewijzigd door jaapzb op 29 juli 2024 11:26]

[NeFoRcE]

Ik blijf het bijzonder vinden dat ik met de directeur van deze club in de klas heb gezeten op't HBO een jaar of 10 geleden. Zeer ondernemend mannetje was het toen al. Zonde om te zien dat ze nu moeten inslinken.

[Verwijderd]

Ik merk een trend in mijn omgeving dat bedrijven minder programma's aangaan met bugbounty bedrijven, maar dat kan toeval zijn. Precies dat ze voorzichtiger zijn met budgetten gezien de economische situatie

[Bsandro]

En/of ook omdat er geen geloof zit in tools die claimen dat ze een penetratietest uitvoeren. Iemand met marketing kennis prikt daar wel doorheen