False positive when a *.deps.json file contains a dependency to a vulnerable package with directory.package.props file and multiple projects
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 454
- Forks
- 134
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
We have just switched to docker scout to scan our docker images.
We are seeing an issue which seems like issue 93 has returned.
I have made a repoduction repository, it seems to be an issue if there are multiple projects which use a directory.package.props file to manage dependecies. The reproduction also uses dotnet 8 with 10.x.x packages, but that might not be contributing to it.
The code is in this repo https://github.com/chestercodes/docker-scout-playground/tree/main/dependency-issue
There is one difference in that i am using a slightly different base image for the build part, which allows my company laptop to get around the VPN, but the sdk one should work as well.
The docker scout output for the version is included in the run script
The issue seems to stem from the deps file of the referenced project, in this case called other.csproj.
It is not present when the directory.package.props file is remove and the version is specified in each of the csproj files, there is a branch with this case
The differences can be seen in the docker scout invocation, the main branch shows 2 high vulns, which is incorrect, as the updated package is specified in the packages props file.
The branch built image shows no high vulns, which is correct.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the dependency-issue reproduction repository and run the build.ps1 Docker Scout invocation. Compare how the main branch and dep-issue-fixed branch process the referenced other.csproj and its *.deps.json with directory.package.props. Done means the main branch no longer reports the two incorrect high vulnerabilities and matches the clean fixed-branch result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, docker, powershell
- Domain
- devops, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100