GitHub laat beveiligingsonderzoekers privé bugs in externe repo's melden

GitHub maakt het mogelijk voor beveiligingsonderzoekers om privé kwetsbaarheden te melden aan beheerders van repositories. Dat was al mogelijk in bèta, maar nu wordt dat breed beschikbaar voor 30.000 organisaties die samen meer dan 180.000 repo's beheren.

GitHub schrijft in een blogpost dat het de private vulnerability reporting algemeen beschikbaar maakt. Met die optie kunnen externe beveiligingsonderzoekers makkelijk contact opnemen met beheerders van een repository als ze daar kwetsbaarheden in vinden. Beheerders kunnen die feature aanzetten voor hun repo's, waardoor onderzoekers privé contact kunnen leggen met de juiste persoon zonder eerst naar de website van een bedrijf of instantie op zoek te moeten naar een contactpersoon of -e-mailadres. GitHub kondigde de feature in november van vorig jaar aan tijdens zijn ontwikkelaarsconferentie GitHub Universe. Nu kunnen alle repobeheerders de functie inschakelen via het Code security and analysis-instellingenmenu. Het gaat om een opt-in.

Volgens GitHub zijn er inmiddels 30.000 organisaties die privémeldingen voor kwetsbaarheden mogelijk hebben gemaakt. Dat zou gelden voor meer dan 180.000 repositories, die gezamenlijk voor meer dan duizend meldingen hebben gezorgd.

GitHub voegt direct ook enkele nieuwe aspecten aan die functionaliteit toe. Zo kunnen de meldingen nu worden ingeschakeld voor alle repo's binnen een organisatie; tijdens de bètaperiode kon dat alleen nog voor individuele repo's. Ook komen er verschillende api's beschikbaar, waaronder een die het mogelijk maakt een privémelding ook via thirdpartyplatformen door te voeren. Daarnaast kunnen beveiligingsonderzoekers een kwetsbaarheid geautomatiseerd melden in alle beschikbare repo's waar die bug voorkomt.

Reacties (11)

[i-chat]

wat zou het toch geweldig zijn als die 'beveiligingswaarschuwingen' dan ook direct zichtbaar zijn voor 'forks' en vooral ook voor projecten die die code in hun project hebben opgenomen.

neem nu code zoals bepaalde liberaries zoals lib_ssl

[laurxp]

Dat kan op Github al met Dependabot. Dat geeft automatisch een waarschuwing als er een bekend beveiligingsprobleem is in één van je dependencies.

Als je forkt of de code kopieert naar jouw repo in plaats van het fatsoenlijk als dependency in te stellen, ben je uiteraard zelf verantwoordelijk voor eventuele issues.

[Anonymoussaurus]

Niet alleen een waarschuwing: je kan ook een workflow configureren zodat Dependabot automatisch pull requests aanmaakt, zodat je dependencies geüpdatet worden.

[CH4OS]

Als je forkt of de code kopieert naar jouw repo in plaats van het fatsoenlijk als dependency in te stellen, ben je uiteraard zelf verantwoordelijk voor eventuele issues.

Het is niet dat als je forked, dat je dan niet meer code van elkaar kan hergebruiken. Daar kun je met een pull request alsnog aan komen hoor. Goed reviewen en merge conflicten controleren, dat wel naturulijk. Maar bij dependancies is het risico daarop wel een stuk kleiner natuurlijk.

[Reactie gewijzigd door CH4OS op 25 juli 2024 23:32]

[Jelmer]

Maar dan ondermijn je het idee van private. Een geïnteresseerde in vulnerabilities zou dan van diverse projecten een fork kunnen maken en zo als eerste op de hoogte te zijn.

[kuurtjes]

Ik dacht juist hetzelfde.

Forks moeten gewoon wachten op de nieuwe versie. Je wilt juist dat zo weinig mogelijk mensen er van weten.

[Tubby]

Jeej, over het algemeen wil je externe libraries niet direct als code includen in jouw project maar via een artifact (compiled / packaged variant van dat project)

En dat is er al met dependency scanning van owasp of tools zoals snyk

[djvdorp]

Het lijkt mij uitdagend om dit goed te bouwen en alle implicaties vooraf uit te denken, zeker icm eventuele project forks.

[WhatsappHack]

Het is alleen weer wat belabberd geregeld met permissions.