Data Folder Location

[T1mey]

Hello,

it seems that the folder of the cache data was moved with version 6.2.0.

From
$(Agent.WorkFolder)_tasks\dependency-check-build-task**..\dependency-check\data

to

/home/vsts/work/1/s/dependency-check/data

As we can't download all definitions during each pipeline run we need to cache the data dir upfront and restore it once a owasp scan is executed. We're wondering why this is now located in the work dir?

As well if this is right how can we construct the path of the cache dir using variables before OWASP runs?

[mobijmartinez]

Hi, this move has also affected the detection as now Dependency Check includes its own dependencies in the scan, and has found some high ones (in our case failing the pull request pipelines in the process).

[pippolino]

Hi @T1mey, since version v6.2.0 the plugin structure has changed, however you can set the location of the data directory used to store persistent data via additionalArguments by setting --data or -d, see parameters at DependencyCheck Command Line Arguments

[pippolino]

Hi @mobijmartinez, the dependencies of the Dependency Check tool do not depend from the Azure DevOps plugin.

[mobijmartinez]

Hi @pippolino , thanks for your answer.

The issue is that the tool is downloaded into the /home/vsts/work/1/s/ directory now, which is also the directory where the default repository is downloaded (the Build.SourcesDirectory variable). When performing a scan on this directory the scan also includes the /home/vsts/work/1/s/dependency-check/lib directory and fails the build as there are vulnerable dependencies within.

From the task, unless I download and install manually Dependency Check, I have no way (afaik) of customizing the install directory of the tool.

[T1mey]

ed (the Build.SourcesDirectory variable). When performing a s

Yes this was as well our assumption this morning... As the folder is now in the same checkout dir as our repo.

[pippolino]

Hi @mobijmartinez @T1mey, this hasn't changed from the previous version. Let's check this point further, I'll check the code, it might have been something unwanted.

[mobijmartinez]

From our side the issue has resolved on its own. PRs started to work again 🤔

Nope, issue still there

[lennartb-]

We have the same issue. I'm not super deep into our pipeline, but previously we downloaded the database once, and it was placed inside the directory of the task itself, for example, C:\agent\_work\_tasks\dependency-check-build-task_47ea1f4a-57ba-414a-b12e-c44f42765e72\6.1.3\dependency-check\data. The pipelines that perform the check took the database from that directory automatically (?, we don't seem to have configured the location of the database manually). This now fails, as the default data directory seems to be inside the work folder for our initial download task. Unless the behavior is reverted, I guess we'd have to point data.directory to an explicit directory, shared by all pipelines?

[T1mey]

he previous version. Let's check this point further, I'll check the code, it might have been something unwanted.

From our experience the folder locations seems to be changed.

As outlined by @mobijmartinez the main problem is that the azure devops extension positions the owasp binaries in the work folder. As a result of that an owasp scan will scan it's own libs.

Before the change the binaries were located in _tasks folder.

[pippolino]

Hi @T1mey, I found a possible cause. I'm working on restoring functionality

[T1mey]

@pippolino Did you break smth. else?

[tegidi]

Looks like the creation of the directory - when not available - was removed: #159 (comment)

[Wes-Love]

This has broken all my builds. New Issue raised #161

[pippolino]

The version 6.2.3 has been released with a fix.

[lennartb-]

Can confirm that 6.2.3 works as expected for us, no manual changes necessary 👍