/dev/null - Overig

Kwetsbaarheden eerder gevonden in open source dan ze gepatcht kunnen worden.

29-05-2021, 12:37 door Anoniem, 7 reacties
Voorbeeld: https://metrics.openssf.org/grafana/d/default/metric-dashboard?orgId=1&var-PackageURL=pkg:github%2Fretirejs%2Fretire.js

Bovendien is er ook nog de averserende invloed van een aantal Google hoepeltjes,
waar doorheen gesprongen moet worden.

En dan is er verder dit project: https://spdx.dev/

Vergeet niet, degenen, die de code schrijven, herkennen zelden de eigen fouten.

luntrus
Reacties (7)
30-05-2021, 14:38 door Anoniem
Als software dus afhankelijk is van de inspanningen van een bepaalde developer op Github,
kunnen sommigen een probleem hebben.

Open-bug-hazenjacht, Gevolg, er worden al 50% meer kwetsbaarheden gevonden.

Open Source kwetsbaarheden overzichten, een goed idee maar te veel externe sturing door Google etc.

Bugs worden dus sneller gevonden als ze te patchen zijn.

Iemand?

#sockpuppet
31-05-2021, 10:08 door Anoniem
Hmm... dat klinkt als een roeptoeter op een zeepkist.

Bij het vinden en patchen van fouten in software komt het een en ander kijken: hoe populair is het pakket, hoeveel mensen onderhouden het, hoeveel mensen proberen er gaten in te prikken, hoeveel tijd kan een ontwikkelaar steken in het patchen.

De titel van deze draad stelt (nogal dwingend) dat hier een probleem beschreven wordt dat voor de gehele open source geldt. Met een pakket als voorbeeld.

Dat een slager die zijn eigen vlees test niet altijd het beste vlees heeft is een gegeven. Maar om vervolgens op basis van een N=1 een stelling als deze te doen is (mijns inziens) nauwelijks constructief
31-05-2021, 11:39 door Anoniem
Door Anoniem: Maar om vervolgens op basis van een N=1 een stelling als deze te doen is (mijns inziens) nauwelijks constructief

Ben ik het niet mee eens, het is een constatering. Ik zou deze stelling willen poneren:

Voordat, ook al is het open source, iemand code op whatever sharing platform zet, zou het door een proces heen moeten, zodat het by-design wordt getest, gereviewed, stuk gemaakt wordt en weer gerepareerd op de juiste manier.

De echte stelling: Secure coden is complex.
31-05-2021, 13:13 door Anoniem
Kwetsbaarheden eerder gevonden in open source dan ze gepatcht kunnen worden.

Dat is altijd het geval. Ongeacht of iets open source is. Een kwetsbaarheid die onbekend is, zal niet gepatched worden.
31-05-2021, 13:29 door Anoniem
tja net als die zero-days die je in ANY (dus ook propriety) software steeds hebt?

ik snap dus het punt gewoonweg niet...
31-05-2021, 22:31 door Anoniem
Als je niet als soort menselijk experiment bekut wordt en overal stelselmatig getreiterd omdat je niks verkeerds hebt gedaan maar men je om een reden van iemands dimme ego schizo wil maken... ja dan kun je alles. Ook in de heavily infiltreerde opensource community.

Dat 1 op de 50 verward raken en mensen steken ipv de Kroon dragen dat maakt de vetzakken niks uit.

Het is een killer joke als je wel de capaciteiten hebt maar je werk steedw wordt gefrustreerd...

Dus er gaan mensen hun privacy en carriere verliezen

De wetten beschermen de daders

Brace for it
31-05-2021, 22:57 door Anoniem
Ik ben de OP en draadstarter. Ik heb deze vraagstelling zo aangetroffen bij de security rubriek van The Register, de Engelse tegenhanger van ons aller security dot nl. Open source was de "name of the game in coding". Ik kon dus niet weten dat sommigen hier dit een draak van een topic vinden, maar ala dat zij zo.

Natuurlijk zal het geheel afhankelijk zijn van welke code er tegen het licht gehouden gaat worden. Babel en Rust zal wat gemakkelijker liggen dan Bootstrap bijvoorbeeld. Dan speelt onderhoud van de code en de regelmaat van vernieuwen daarvan en het aantal mensen dat de reviews doet etc. zeker ook een rol. Signeren van code ook altijd behulpzaam in gevallen dat.....

Ik bemoei me als anti-malware fighter met website security, dus dan richt je specifiek op bibliotheken, update en patch grade van gebruikte front en back-end software. Bij Magento kan je via magereport (van de stek van good old GWillem), een goed idee krijgen van de veiligheidsstatus van de gebruikte code/

Daar komen ook andere zaken bij om de hoek kijken, zoals in hoeverre is er sprake van een goede Content Security Policy, de veiligheid van de connectie op de achterliggende server, Cloaking (er is verschil tussen de code gepresenteerd aan Google en Googlebot).

Laatst verloren we de online versie van de Retire.JS tool, omdat Erlend Oftedal, de onderhouder van de website, de serverkosten te begrotelijk zag worden. Maar als extensie is Retire.Js in de browser een aanrader voor developers. En nog een heel scale aan andere website/webserver veiligheidszaken passeren regelmatig de revue.

Natuurlijk kost fuzzen, linten en hinten tijd, ook op inline code, maar aan de andere kant is er ook vrij veel winst mee te behalen. En er zijn ook veel 3rd party resources, die men kan integreren.

Liever een veilige(r) site dan een mooie gelikte, zeg ik in dat geval. CMS vaak een ondergeschoven weeskindje en veelal op kritieke punten verwaarloosd.

Dat was mijn insteek, lieve lezers dezer draad en ik wilde beslist geen experts tegen de haren instrijken hier.
Ik weet hoe ze soms kunnen reageren en uitschieten als je ze te zeer irriteert. ;)

gegroet van uw aller,

luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.