Static Code Analyzer resultaten binnen Open Source community

[Ask!]

We hosten een open source project op Github, en hebben een Github Action gemaakt voor het scannen van code in SonarCloud voor wat static code analysis.
Ik vraag me af wat een best practice is voor het publiekelijk (of niet) maken van de SonarCloud resultaten.

Aan de ene kant wil je alles natuurlijk delen, omdat het project Open Source is.
Aan de andere kant wil je misschien niet alle vulnerabilities public hebben? (Of juist wel, want Open Source).

Heeft iemand ervaring met deze discussie?

Ik kan weinig best practices vinden op internet hierover, misschien hebben jullie ervaring!

[418O2]

Wat houdt iemand tegen om je project uit te checken en dat zelf te doen?

Je zou zelfs kunnen ageren dat het goed is en code niet in Main komt zonder vulnerabilities. Dat wekt meer vertrouwen dan "We draaien sonarcloud maar maken dat niet openbaar"

[Voor 20% gewijzigd door 418O2 op 12-02-2021 10:09]

[Ask!]

Zeker een goed punt!
Ik hoop wat meer meningen te krijgen

[Gomez12]

Tja, is de uitkomst van de static code analyzer zo beroerd? Want dan zou ik eerder overwegen een andere static code analyzer oid te gebruiken.

Kijk zoals Catch22 al zegt, iedereen kan het zelf ook draaien.
Het enige waar je goed mee moet uitkijken is of jouw/jullie conventies wel overeen komen met de conventies/instellingen van de static code analyzer. Anders is het vechten tegen de bierkaai.

De enige reden die ik me kan voorstellen dat je het vraagt is dat het resultaat nu simpelweg slecht is.

En dat kan wmb 3 oorzaken hebben :
- Er zitten daadwerkelijke known exploits etc tussen, dan zou ik het eerst fixen en daarna pas online gooien wmb hoef je geen known exploits van jezelf online te zetten. Terwijl als het een unknown exploit is anderen je er juist perfect op kunnen wijzen terwijl je het misschien zelf nog niet eens ziet.
- Jullie conventies komen niet overeen met de analysis zijn conventie, maar dat is een kwestie van de analysis anders instellen, het heeft geen zin om 3000 warnings te krijgen op iets wat jullie gewoon standaard doen.
- De code is gewoon slecht, tja dan zou ik me afvragen of je het uberhaupt wel moet open sourcen...

Kijk, ik denk dat het het belangrijkste is dat je het wel zo moet instellen dat hij enkel toont waarvan je ook echt de intentie hebt om het te gaan fixen.
Als je 5000 meldingen krijgt, maar je filtert ze er voor nu uit omdat je het nu niet gaat oppakken (en dat zeg je al een half jaar) dan moet je wmb ze ook in de config uitschakelen.
Het heeft geen zin om 5000 warnings te tonen en als iemand een half jaar later kijkt dat die nog steeds dezelfde 5000 warnings ziet. Dan heb je gewoon niet de intentie gehad om die te gaan oppakken.

[Voor 18% gewijzigd door Gomez12 op 12-02-2021 10:50]

[Ask!]

Gomez12 schreef op vrijdag 12 februari 2021 @ 10:43:
Tja, is de uitkomst van de static code analyzer zo beroerd? Want dan zou ik eerder overwegen een andere static code analyzer oid te gebruiken.

Kijk zoals Catch22 al zegt, iedereen kan het zelf ook draaien.
Het enige waar je goed mee moet uitkijken is of jouw/jullie conventies wel overeen komen met de conventies/instellingen van de static code analyzer. Anders is het vechten tegen de bierkaai.

De enige reden die ik me kan voorstellen dat je het vraagt is dat het resultaat nu simpelweg slecht is.

En dat kan wmb 3 oorzaken hebben :
- Er zitten daadwerkelijke known exploits etc tussen, dan zou ik het eerst fixen en daarna pas online gooien wmb hoef je geen known exploits van jezelf online te zetten. Terwijl als het een unknown exploit is anderen je er juist perfect op kunnen wijzen terwijl je het misschien zelf nog niet eens ziet.
- Jullie conventies komen niet overeen met de analysis zijn conventie, maar dat is een kwestie van de analysis anders instellen, het heeft geen zin om 3000 warnings te krijgen op iets wat jullie gewoon standaard doen.
- De code is gewoon slecht, tja dan zou ik me afvragen of je het uberhaupt wel moet open sourcen...

Kijk, ik denk dat het het belangrijkste is dat je het wel zo moet instellen dat hij enkel toont waarvan je ook echt de intentie hebt om het te gaan fixen.
Als je 5000 meldingen krijgt, maar je filtert ze er voor nu uit omdat je het nu niet gaat oppakken (en dat zeg je al een half jaar) dan moet je wmb ze ook in de config uitschakelen.
Het heeft geen zin om 5000 warnings te tonen en als iemand een half jaar later kijkt dat die nog steeds dezelfde 5000 warnings ziet. Dan heb je gewoon niet de intentie gehad om die te gaan oppakken.

De code is nu niet slecht, het is zelfs erg goed!
Maar mochten er vulnerabilities in komen door wat voor commit dan ook, wil je dat dan public hebben.
Dat was meer de vraag

[Gomez12]

Ask! schreef op vrijdag 12 februari 2021 @ 10:56:
[...]


De code is nu niet slecht, het is zelfs erg goed!
Maar mochten er vulnerabilities in komen door wat voor commit dan ook, wil je dat dan public hebben.
Dat was meer de vraag

Tja, wat is de reden dat je het open sourced?

Is dat omdat het je gewoon niets boeit en je de code dan net zo goed beschikbaar kan stellen?
Of is dat omdat je graag hebt dat de OS-community je kan helpen en je kan wijzen op dingen?

Kijk, je vulnerabilitie staat sowieso al public na een commit. Dat is nog ongeacht of je analyzer het een vulnerability vind. Het is wmb meer de vraag of je hulp accepteert of niet bij het vinden/oplossen van die vulnerability.

Nogmaals, zou ik met kwade bedoelingen naar een vulnerability zoeken, dan zou ik gewoon elke dag jouw code pullen en die door een zwaar apart geconfigureerde static analyzer gooien, dat is veel minder werk als elke dag jouw static-analyzer uitslag gaan bestuderen om te zien of er niet toevallig een vulnerability in opgetreden is.

Maar sowieso zegt SonarCloud niet per definitie of iets een vulnerability is afaik, en anders kan je gewoon het nivo aanpassen zodat hij niet publiek inzichtelijk wordt.

[downtime]

Het lijkt me gezond verstand. Door de vulnerabilities openbaar te maken geef je gebruikers van de code ook de optie om eerst op een fix te wachten voordat ze die code gebruiken. Of ze kunnen ervoor kiezen om op een andere manier te mitigeren voor die kwetsbaarheid. Het alternatief is dat de gebruikers slachtoffer van een kwetsbaarheid in jouw code worden omdat jij die kwetsbaarheid geheim hield.

[Haan]

Security through obscurity is sowieso geen security dus inderdaad eens met de anderen dat dit soort resultaten niet zou moeten verbergen.

[Gomez12]

Haan schreef op vrijdag 12 februari 2021 @ 13:22:
Security through obscurity is sowieso geen security

Dat is nu echt een complete dooddoener.

Security through obscurity is wellicht theoretisch geen security. Maar in de praktijk werkt het toch verdraaide goed als het om slechts een obscuur programmaatje gaat.

Praktijk is namelijk wel/ook dat als er bepaalde exploits optreden dat menig scriptkiddie dan gewoon github af gaat zoeken naar waar die exploit gebruikt wordt om daarna Shodan / Google te gebruiken om doelen te vinden.

En als jouw code dan niet op GitHub staat dan scheelt het jouw klanten toch een zooitje drive-by-scriptkiddies.

Security through obscurity werkt niet als men een gerichte aanval uit gaat voeren, maar je hebt daarnaast ook een heleboel drive-by aanvallen die je wel gewoon kan voorkomen.

[Ask!]

Bedankt allemaal!
Ik ben goed geholpen!

[Gomez12]

En waar ga je nu dan voor?

Wel public tonen of niet public tonen?

[Ask!]

Ik ga voorstellen om het public te houden, puur om transparant te blijven en gebruikers inderdaad de optie te geven om code wel of niet te gebruiken op basis van bijvoorbeeld bepaalde vulnerabilties.
Daar hebben jullie me van overtuigd

[Haan]

Gomez12 schreef op vrijdag 12 februari 2021 @ 14:14:
[...]

Dat is nu echt een complete dooddoener.

Security through obscurity is wellicht theoretisch geen security. Maar in de praktijk werkt het toch verdraaide goed als het om slechts een obscuur programmaatje gaat.

Praktijk is namelijk wel/ook dat als er bepaalde exploits optreden dat menig scriptkiddie dan gewoon github af gaat zoeken naar waar die exploit gebruikt wordt om daarna Shodan / Google te gebruiken om doelen te vinden.

En als jouw code dan niet op GitHub staat dan scheelt het jouw klanten toch een zooitje drive-by-scriptkiddies.

Security through obscurity werkt niet als men een gerichte aanval uit gaat voeren, maar je hebt daarnaast ook een heleboel drive-by aanvallen die je wel gewoon kan voorkomen.

De code van de TS staat echter wel op GitHub, dus ik snap niet welk punt je precies probeert te maken nu?

[Hydra]

Gomez12 schreef op vrijdag 12 februari 2021 @ 14:14:
[...]

Dat is nu echt een complete dooddoener.

Security through obscurity is wellicht theoretisch geen security. Maar in de praktijk werkt het toch verdraaide goed als het om slechts een obscuur programmaatje gaat.

Precies.

Het is een verkeerde interpretatie van een incomplete quote. "Security through obscurity" betekent security alleen door obscurity. Het komt voor uit de discussie dat bijvoorbeeld je crypto secure moet zijn door de sterkte van de key en het algorithme en niet afhankelijk mag zijn van het onbekend zijn van het algorithme.

Er is niks mis met obscurity toevoegen om het misbruikers moeilijker te maken. Sterker nog; informatie die het ze makkelijker maakt moet absoluut verwijderd worden. In een header je Apache of PHP versie meesturen is volkomen debiel.

Het misbruik van die quote gebeurt veel te vaak. Het is schokken hoe veel mensen (heb het niet over mensen in dit topic) denken security te snappen en dan doodleuk dit soort quotes te pas en te onpas rondstrooien.

En als jouw code dan niet op GitHub staat dan scheelt het jouw klanten toch een zooitje drive-by-scriptkiddies.

Maar het scheelt ook een hoop ogen die meekijken. Dus het is een afweging. De kans dat mensen misbruik maken versus de kans dat mensen problemen rapporteren.

In deze discussie is het, aangezien de code zelf al publiek staat, wel een no-brainer trouwens. Een dergelijke vulnerability scan kunnen 'hackers' zelf ook wel doen op de bestaande code. Er is weinig reden het af te sluiten.

[Voor 18% gewijzigd door Hydra op 13-02-2021 13:31]