When integrating Operaton I am notified about security issues in dependencies of Operaton. Specifically gson 2.8.9 which is shaded in operaton-engine and bootstrap 3.4.1 as part of deps.js in operaton-webapp-webjar.
In order to assess the impact of those issues I was looking for further information or documentation to refer to. So far I could not find information about dependency management regarding security in general and no remarks regarding those two versions specifically.
What is the current approach to handling dependency updates for security issues or tracking possible issues? I noticed Operatons Sonar analysis does not notify about the security issues with those dependencies and dependabot does not suggest an available update.
thanks for raising this. Both dependencies you mentioned are indeed still on the versions you reported in the current main branch. This definitely requires investigation and remediation. Could you open separate issues for each of them in the GitHub project so we can track and fix them properly?
Regarding the release cadence: As discussed in our call on December 5, we’ve defined the following release rhythm for dependency / security update releases:
Monthly patch release on the second-to-last Friday of each month
Out-of-band releases for critical security issues
This should give us a predictable cadence while ensuring we can react quickly to urgent vulnerabilities.
Thanks again for bringing this to our attention — much appreciated!
Hi @SDied, thank you for this post and mentioning the security issue with gson 2.8.9.
We are currently relying on the security scanning by GitHub (I guess the tab with all outstanding security issues is only visisble to project members) and were under the impression that it worked quite well, because we caught multiple vulnerabilities very soon after they were released with it. We are checking the results regularly, independent from the pull requests which are created by dependabot for this. While it is an issue that GitHub only can scan on a code level, we have also talked about integrating trivy to check on the built artifacts, too. If I remember correctly, we already use trivy to help create the SBOMs. As you already concluded, this issue was not raised by the GitHub scanner, so we were not aware of it. We will look into it, thanks for the pointer!
May I ask which scanner reported this issue for you? If there is room for improvement I’m always happy to learn.
For the backend there is a maven plugin that checks maven dependencies and for the frontend I depend on the shell version. Sonar then picks up those results and displays them as security issues.
@javahippie Right, for the generation of the SBOMs we are already using trivy, so the basic setup in Github workflows is done. It was a bit tricky, since the default installation recommends using Homebrew, which itself was a bit tricky to set up.
@SDied Thank you for pointing us to the tool. Interesting would be if that tool detects more than trivy. Obviously Github security scanning is not enough. Especially we only can set it up for the main branch, while we need scans also for other branches. I am planning to set up trivy for that one day, but might consider dependency-check as additional resource. In that case, more helps more. Not a big deal if both run once a day (or slighly less).