Slightly odd situation. I always use specific versions for dependencies and therefore have never used a gradle lockfile. However, multiple SCA packages I am evaluating (suck as semgrep.dev) utilize the lockfile to perform a scan on dependencies for CVE and related issues.
So, basically, is there a way within Gradle to generate the lockfile, but disable its functionality?
(Otherwise, I will just script it as part of the CI/CD process).
As I’m like you and not use dynamic versions, I’m not fully sure.
Imho those tools should be updated to use the Gradle tooling API to get the used versions and not parse any file.
But besides that, you have to enable locking for the configurations where you want it to be used.
I would expect that if you enable it, generate the lockfile and then disable it again, that no locking is used.
Besides, what do you loose if locking is used? By disabling it you probably only risk that the lockfile and the real dependencies deviate in the future. If you really need a lockfile for those tools, it is probably best to actually use the locking, even with the fixed version.
The reason SCA tools use lockfiles is because they require minimal coding to differentiate between the many build systems, and are much more stable. I have no disagreement with that aspect.
The “hack” I would do in CI/CD would be along those lines, “find --name gradle.lockfile --delete” and then use the --write-locks while building. I would prefer a more “elegant” solution to such a brute force hack.
and are much more stable. I have no disagreement with that aspect.
I fully disagree.
Lockfiles are not meant to be stable and supported over multiple versions.
They are supported by the version of Gradle used for that build and could change any time, and rightfully though as they are just an implementation detail of the feature, not something meant to be parsed by others.
The tooling API is mainly made for other tools to integrate with Gradle like IDEs and similar.
It is designed for stability, backwards and forwards compatibility. The Tooling API version is guaranteed to support running builds with all Gradle versions for the last five major releases. For example, the Tooling API 8.0 release is compatible with Gradle versions >= 3.0. And the Tooling API is guaranteed to be compatible with future Gradle releases for the current and the next major. This means, for example, that the 8.1 version of the Tooling API will be able to run Gradle 9.x builds and might break with Gradle 10.0. So you can easily support all Gradle versions since 2016 and at least until the major version after the next major version.
By supporting lock files you can only support projects using lockfiles and thus only projects at least using 4.8 and only if you support the evolved lock files which are not guaranteed to be stable in format.
We can agree to disagree.
It is also not material, SCA companies have implemented against the lockfile instead of the gradle tooling API.
We can agree to disagree.
SCA companies have implemented against the lockfile instead of the gradle tooling API.
SCA companies the SCA company you use!
If I Google for SCA solutions, first thing I find is Snyk, which is a Gradle plugin you apply in your build and run as Gradle task.
Second thing I find is Mend, which automatically adds a task to the project and executes that task, then scans the result. I didn’t check how it runs the Gradle build, but chances are very high that it uses the tooling API.
Third thing I find is OWASP Dependency Check which also is a Gradle plugin you apply and then execute a task.
Then I stopped looking.
lol, well Synk is one of the companies I am evaluating. Just not the only one.
Veracode, Semgrep (reads the lock file), and a few others.
I am actually evaluating SAST and SCA; as an “upgrade”: from PMD, Checkstyle, Spotbugs/FindBugs solution we cobbled together.
Do you really consider this an “upgrade”?
I would have thought it more as a supplement.
PMD / Checkstyle / Spotbugs check your actual code.
SCA tools check your dependencies.
At least the ones I know and have looked at in the past.
At work we for example use all those tools (OWASP Dependency Check as SCA) and additionally SonareQube which has its own rules and also integrates the findings of all those other tools in one Code Quality UI.
There is a reason I had upgrade in quotes.
There are two parts to this “upgrade”, SAST and SCA, Our existing solutions does not cover the full range of SAST requirements in PCI. Therefore, we are looking to implement a SAST tool to replace our existing solution. SAST depending on the solution either reads the source files, or the compiled binary, of our code.
Separate from SAST, we are planning to also implement SCA, while not required this year it will be soon. Therefore, we are proactively looking to implement SCA with our SAST solution later this summer. For SCA, the tool needs a dependency list to compare against CVEs and other issues. There seem to be two solutions for getting the dependency list. Look at a lock file, or integrate directly with the build tool. Hence my original question.
SonarCube is a good example, depending on the package you purchase, it can cover SAST, DAST and SCA; plus provide additional code tools such as code coverage analysis.
Even SonarQube free should cover all those parts, shouldn’t it?
Except if you need support for some of the languages only available in the paid versions, or PR decoration features, or branch analysis and so on.
To just analyse the
master branch and have the issues analyzed, the static code checkers result incorporated, the code coverage incorporated, the OWASP dependency check result incorporated, … the free version is fully sufficient imho. At least that is what we use.
Hence my original question.
And did you try my idea to your original question?
The short answer is no. The OWASP dependency check does not meet our requirements. I can provide a full list of requirements if desired. But fundamentally, I am looking for a security code management tool which has capability to provide SAST and SCA. Some of the solutions for SCA that I have found depend on parsing the lock-file.
I have one POC running now, which parses a lock file for SCA. Worst case, I script around it. I have another POC starting Friday, and two more next week, of which SonarCube starts next week.
If Gradle does not have the ability to handle what I want built in (in terms of the lock-file), then this tool gets a small negative in the assessment that we have to script around it.
Let me ask again, did you try what I suggested?
You asked how to have a lockfile without it being used.
And I made a suggestion, although just based on guessing, my guessing if often quite good especially when Gradle releated.
Ah, in your first post? No I missed that. I will try to enable and disable.
When I read that originally, I was thinking it would be easier to add --write-locks to enable it inside the CICD pipeline (both regular and merge pipelines) with a find statement before to make sure all locks are flushed.