Új hozzászólás Aktív témák

• #2776 Egon nagyúr Xpod #2774

  Új Válasz 2025-04-24 09:28:16 #2776

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Egon

  nagyúr

  válasz Xpod #2774 üzenetére

  És emiatt leszek kíváncsi, hogy erre a fejlesztők hogy fognak reagálni.
  Sok esetben már az kiveri a biztosítékot, amikor a szerződés megújításakor felhívom a figyelmet rá, hogy ha egy sérülékenység vizsgálat során felmerül, hogy a szoftver sérülékenységet tartalmaz, vagy egy audit során felmerül egy hiányosság, akkor azt hogyan tervezik javítani? Azt meg sem említem, hogy egy sérülékenység javítása számomra a garanciális javítás kategória, bele kell férnie a support szerződésbe.

  Csakhogy nem így működik a piac. Mivel nincs definiálva az "elvárt minőség" fogalma (azaz pl. hogy legalább OWASP Top10 sérülékenységeket ne tartalmazzon az a fejlesztett tákolmány), mindenki a kiírásból, a műszaki specifikációból indul ki, igyekezvén azt szűken (a lehető legszűkebben) értelmezni. Mivel az esetek 99%-ában az ár dönt az adott pályázatok elbírálásánál (papíron legalábbis - az egyéb "elhajlásokról" idő és kedv hiányában inkább nem beszélnék), sok esetben igenis erős árverseny alakul ki, amit pedig a minőség rovására igyekeznek sokan tartani. Triviális, hogy a funkcionalitásból nem engednek, a legkönnyebben a security rész húzható le. Sok fejlesztőnél egyáltalán nem triviális, hogy legyen biztonság a CI/CD pipeline-ban, max. a Sonarcube-basl bohóckodnak kicsit, esetleg statikus forráskód-elemzés történik, de hamar belefáradnak a sok false positive kiszűrésébe, így inkább ignorálják, stb.
  A lényeg, hogy nincs beárazva, nincs benne az árban az ilyen jellegű support, egy kicsit sem. Főleg, ha eleve koncepciós, tervezési hibára (vagy mondjuk már nem frissülő beépülőre, aminek nincs alternatívája...) vezethető vissza 1-1 sérülékenység, és k. sokba fájna javítani.

Új hozzászólás Aktív témák