Dependency scanning analyzer ignores evicted revisions in ivy-report.xml
-
I verify the issue isn't a duplicate.
Summary
Dependency scanning analyzer only reports the last parsed revision from ivy-report.xml
, ignoring version conflicts and evicted dependencies that should be included in SBOM reports.
Discovered during 649656.
Steps to reproduce
- Create an Ivy project with version conflicts (multiple revisions of the same dependency through nested/composite libraries).
-
Run
ant report
to generateivy-report.xml
with evicted revisions. - Run GitLab dependency scanning job on the project.
- Check the generated SBOM report.
- Check the Dependency List from UI.
Example Project
Example ivy-report.xml
module showing the issue. A submodule can be added to the ivy demo project if needed to generate a similar module:
<module organisation="com.fasterxml.jackson.core" name="jackson-core">
<revision name="2.14.0" status="release" downloaded="false" searched="false" default="false">
<caller organisation="example" name="core" conf="default" rev="2.14.0"/>
<artifacts>
<artifact name="jackson-core" type="bundle" ext="jar"/>
</artifacts>
</revision>
<revision name="2.6.3" evicted="latest-revision" evicted-reason="" downloaded="false" searched="false">
<evicted-by rev="2.14.0"/>
<caller organisation="example" name="common" conf="default" rev="2.6.3"/>
<artifacts></artifacts>
</revision>
</module>
What is the current bug behavior?
The dependency scanning analyzer only reports jackson-core:2.6.3
in the SBOM, completely ignoring the selected version 2.14.0
that was originally requested by core
. The code structure only holds one Revision
object per module, causing data loss during SBOM report generation.
What is the expected correct behavior?
The analyzer should:
- Parse all
<revision>
elements from ivy-report.xml. - Exclude
evicted
ones from the report.
Output of checks
This bug is reproduced on GitLab.com dependency scanning analyzer version 0.36.3
Possible fixes
So here is the code for fetching revision
of modules
func (m Module) version() string {
return m.Revision.Version
}
Educated guess is that this code assumes there is single child revision while there might be more with the example setup provided before and when the revision is defined as single struct in Module
it returns the latest child.
Patch release information for backports
Bug fix and not a security backport. So only with 18 should be good.
High-severity bug remediation
Not high severity.