Förvaltning av gamla beroenden

[tomppa-p]

What happened?

Beroenden som används i applikationen är utdaterade och gör att scanningsprogram som Xray rapporterar sårbarheter som har dykt upp i de beroendena. Ex. så används version 1.61 av Dom4j som har de kända sårbarheterna CVE-2020-10683 och CVE-2018-1000632. Finns det någon plan för hur förvaltning av mjukvaran ska göras? Kommer det göras uppdateringar i repot med senare versioner av beroenden?

Steps To Reproduce

Sårbarheterna borde rapporteras vid scanning med Xray eller liknande analysprogram.

What did you expect?

Vi skulle önska senare versioner av de beroenden som används.

Version

No response

Optional Screenshots

No response

Relevant log output

No response

[fredriknordlander]

Tjena, tack för info! Tanken är att det ska göras uppdateringar i repot med senare versioner av beroenden. Kikar på det och återkopplar 👍

[tomppa-p]

Super!

[halge]

@fredriknordlander hur går det, vi använder er fork o security larmar hög)?

[fredriknordlander]

Tjena, runnit lite vatten sedan denna rapporterades, men vi ska planera in och åtgärda under ngn av kommande sprintar.

[halge]

@fredriknordlander tjena, när fixas det har ni tidsram?

[halge]

@JessicaPry so how is it with this issue? Who will fix it if Fredrik is gone?

[halge]

@tomppa-p @matthiaspalmer @jenniferskoglund someone, please, reply how is it going?

[halge]

@jonassodergren i ask you to help to contact someone.

[fredriknordlander]

@halge - sorry för radiotystnaden. Tyvärr finns det ingen spikad tidsram ännu. Teamet som ska åtgärda dessa delar har ej kommit på plats, så det har inte gått att planera in arbetet. Dock är det topp prio att åtgärda dessa sec.issues.

[janderssonse]

Hejsan, jag fick frågan av Fredrik och kollade närmare på denna.
Vi har som standard GitHubs egna säkerhetsverktyg påslagna - dependabot (SCA-verktyg), secrets, codeql (SAST-verktyg) etc för våra repositorys numer.

SCA-verktyget (dependabot) kunde inte hitta just det felet och beroendet som pekas ut i denna. Jag kikade om beroendet återfinns inte heller i GitHubs dependecygraph för projektet, ej i den heller. Provade också SCA-dependabot-inställningarna i en tom fork av projektet för att se om det var något knas med själva inställningarna för projektet. Inget funnet. Kan det vara en äldre version än den i main som skannats av Xray?

Jag körde också sidokoll med senaste NVD-informationen utanför GitHub's verktyg och då hittade OWASPs SCA-verktyg https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ några criticals som inte GitHubs egna verktyg fann. Alla dess criticals verkar lösa sig om man uppgraderar spring boot-versionen.

Här ser vi att man kan få lite olika resultat beroende på vilket verktyg man använder helt enkelt också.

Så det här är eg två frågor : finns de specifika CVE's som pekas ut jiran kvar i senaste main, och är critical ? Nej inte vad githubs verktyg eller OWASP säger.
Vill man använda kompletterande verktyg för säkerhet i framtiden förutom githubs för att komplettera, eftersom andra CVE's kan hittas då? Kanske?

Så här är mina förslag:

• Stäng denna issue specifikt med hänvisning till ovan undersökning
• Avgör om ni inom projektet vill nöja er med de GitHub-funktioner som är påslagna eller lägga till extra som owasp-verktyget ovan.
• OM ni vill ha OWASP mvn som visas ovan, Lägg en ny issue om ni vill) där man använder dependency-check med maven i en pipeline. (såg dock att projektet har problem med sin 9.x-version och man får köra 8.x om det ska fungera just nu).

[halge]

desutom docker build . falleras (man kan bara använda :latest tag fri #26):

Step 9/19 : FROM cgr.dev/chainguard/jdk:openjdk-jre-11-20221109
manifest for cgr.dev/chainguard/jdk:openjdk-jre-11-20221109 not found: manifest unknown: Unknown manifest

[janderssonse]

desutom docker build . falleras (man kan bara använda :latest tag fri #26):

Step 9/19 : FROM cgr.dev/chainguard/jdk:openjdk-jre-11-20221109
manifest for cgr.dev/chainguard/jdk:openjdk-jre-11-20221109 not found: manifest unknown: Unknown manifest

@halge
Just dockerbuilden är löst här, #29 vill du bygga en egen innan den blivit inmergad bör du kunna använda den dockerfilen.

[ayeshabhatti78]

Jag har nu lyckats uppgradera spring version till 3.2.0 och smoke test typ fungerar. Alla spring CRITICALS är borta.

Snakeyaml också gick att uppgradera.

Enda som är kvar är det felet som finns i issuen. Som Josef har också skrivit, det är lite lurigt. OWASP verktyget har spårat den till hibernate-core. Jag har kollat för nyare versioner men hittade ingen på själva som finns i projekt, har provat med en liknade men felet finns kvar. Den används inte direkt från kod. Utan den tillgängliggör json types till hibernate om den lyckas laddas innan eller samtidigt som hibernate. Jag tror att det är därför den är svårt hittad.

Nu har jag pratat med Jonas och vi har kommit överens att jag committar till två olika feature branches. En med uppdaterat spring samt snakeyaml och andra där hinernate-core är också borta. Vi kör acceptans test och gå darifrån. Uppdaterar issue igen när jag är klar med committen.

[ayeshabhatti78]

Uppgraderat spring boot mm: 18-förvaltning-av-gamla-beroenden
Uppgraderat spring boot mm samt tog bort hibernate-json-contributor: 18-förvaltning-av-gamla-beroenden-1

[halge]

@janderssonse @ayeshabhatti78 inform when those changes are in main, please.

[halge]

@janderssonse @ayeshabhatti78 when main branch will be updated? what is the plan?

[janderssonse]

Hej! @halge Jag har själv inga mergemandat för detta projekt, men ska kolla med med min kollega m.fl vad status är på dessa alt. om jag skulle kunna få mergemandat för enklare fixar som säkerhet o liknande.

[fredriknordlander]

Hej. @halge Vi ska börja acceptanstesta de fixes vi gjort för denna issue och några till. Jobbet drar igång till veckan. Efter detta, förutsatt att det fungerar som tänkt, så kommer vi att merga in detta på main.

[tomppa-p]

Hej igen! Hur är status på det här nu? När tror ni att ni kommer kunna merga in detta på main?