Add an analyzer which will look up an artifact in an Artifactory instance by SHA-1.
This may present challenges as you can only search by checksum in the Pro version of Artifactory. You can get a 30-day eval license of it to test with, but if the API changes outside of that window, modifying the analyzer will be difficult. Somebody from the community is looking to see if we can possibly get a longer-lived license to test with.
@colezlaw Do you still have plan to implement this feature?
I did some testing with Artifactory and it did not really seem to add any value in the same way pinging Maven Central or a Nexus repo. Maybe I didn't spend enough time reading through the API guide, but the reason we ping Central is to get the GAV coordinates. When you search an Artifactor by hash you don't get the GAV back (unless I'm missing something). So the best it would be is a way to find out if the dependency is in your Artifactory.
Now another type of plugin for Artifactory would be one to scan the entire repo and identify vulnerable components. This would take a bit more time and I do not have a licence for Artifactory pro.
--Jeremy
I asked jfrog about it and they propose 2 solutions:
with sample request:
items.find(
{
"$and":
[
{"repo" : {"$eq":"libs-release-local"}},
{"actual_sha1" : {"$eq" : "8ab478f35e2220c8e36d7a904fdc67d29257c224"}}
]
}
).include("path")
and the response will contain:
"path" : "com/uriah/artifact/1.0"
pros:
cons:
And expose REST API with checksum in request and GAV values in response
pros:
cons:
Which solution, do you think, will be better?
I would vote for option 1 as parsing the path is not that difficult and the setup is easier as it does not require the on-prem with the user plugin.
Hello,
I do have artifactory pro - I am willing to test for you since you don't have pro available (At the same time, I believe that jfrog wouldn't mind granting you at least an evaluation license for this).
The ODC project has an Artifactory instance and we are in the process of moving to it - so I'll be able to build/test the integration.
We would be interested in testing this also
For option #1, what happens when group is not supplied? How can the path be parsed? This will be a common occurrence if Artifactory is hosting a Node.js repo where group is an optional item in package.json.
Does the request have to change based on the type of file we're scanning? In the example, the repo is "libs-release-local", but will that repo always exist and be used for all types of components?
Does the response differ when using a non-Maven repo? If the path element is the same, then having the last part of the path being the artifact and anything before it be the group should be fairly simple.
I got Artifactory Pro as well so I might be able to help with this. JFrog got XRay, a product which provides similar functionality so I doubt how much they will be willing to help.
@jeremylong Do you think providing the WADL will answer the questions it looks like it's available here
The response if the artifact not found is HTTP 200 which looks like below
I'll be happy to help with creating this analyzer, will you be able to give me some guidelines to bootstrap this?
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Server: Artifactory/5.4.6
X-Artifactory-Id: f88ccba01261e0eb:-30f3c7d9:15e6419ed91:-8000
{
"results" : [ ],
"range" : {
"start_pos" : 0,
"end_pos" : 0,
"total" : 0
}
}
Will likely end up using the:
curl -H "Authorization: Bearer <token>" -H "X-Result-Detail: info" "<server>/api/search/checksum?sha1=d832b22f68e34a66d84efd4d0c90720bcac5cde5"
Which results in:
{
"results" : [ {
"repo" : "libs-release-local",
"path" : "/org/owasp/dependency-check-core/3.1.0/dependency-check-core-3.1.0.jar",
"created" : "2018-01-02T23:29:08.325Z",
"createdBy" : "ci_deploy",
"lastModified" : "2018-01-02T23:29:08.282Z",
"modifiedBy" : "ci_deploy",
"lastUpdated" : "2018-01-02T23:29:08.282Z",
"downloadUri" : "https://dependencycheck.jfrog.io/dependencycheck/libs-release-local/org/owasp/dependency-check-core/3.1.0/dependency-check-core-3.1.0.jar",
"mimeType" : "application/java-archive",
"size" : "597724",
"checksums" : {
"sha1" : "d832b22f68e34a66d84efd4d0c90720bcac5cde5",
"md5" : "cfa4b35fc6e75b2db0867d70702059b5",
"sha256" : "3fb262c71542e5ae0a50508e76aec7e9cc76f4fec3f22500639e795576fbe193"
},
"originalChecksums" : {
"sha1" : "d832b22f68e34a66d84efd4d0c90720bcac5cde5",
"md5" : "cfa4b35fc6e75b2db0867d70702059b5",
"sha256" : "3fb262c71542e5ae0a50508e76aec7e9cc76f4fec3f22500639e795576fbe193"
},
"uri" : "https://dependencycheck.jfrog.io/dependencycheck/api/storage/libs-release-local/org/owasp/dependency-check-core/3.1.0/dependency-check-core-3.1.0.jar"
} ]
}
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I would vote for option 1 as parsing the path is not that difficult and the setup is easier as it does not require the on-prem with the user plugin.