Dynamic report is not adding MD5/SHA1 correctly

[CalldiDoctor]

I've noticed that the dynamic report created by the dependency-track does not correctly add the SHA1 and MD5 of the dependency. It adds the "libraryVersion.getUndashedUuid()" since, the libraryVersion.getSha1() is null.
I've realized about this issue when trying to suppress some vulnerabilities, because copying the suppression code into the supression.xml file cause a problem when parsing this xml (libraryVersion.getUndashedUuid() does not have 40 characters as SHA1 requests).

I've solved this updating the performAnalysis method in the DependencyCheckAnalysis class. You can see the code below:

for (LibraryVersion libraryVersion : libraryVersions) {
            final Library library = libraryVersion.getLibrary();
            final Dependency dependency =
                new Dependency(new File(FileUtils.getBitBucket()));

            final License license = library.getLicense();
            if (license != null) {
                dependency.setLicense(library.getLicense()
                    .getLicensename());
            }
            dependency.setDescription(String.valueOf(libraryVersion
                .getId()));
            dependency.getVendorEvidence().addEvidence("dependency-track",
                "vendor", library.getLibraryVendor().getVendor(),
                Confidence.HIGHEST);
            dependency.getProductEvidence().addEvidence(
                "dependency-track", "name", library.getLibraryname(),
                Confidence.HIGHEST);
            dependency.getVersionEvidence().addEvidence(
                "dependency-track", "version",
                libraryVersion.getLibraryversion(), Confidence.HIGHEST);

            // Adding the SHA1 and MD5 of the dependency (Update)
            libraryVersion.setSha1(dependency.getSha1sum());
            libraryVersion.setMd5(dependency.getMd5sum());


            dependencies.add(dependency);

        }

Surely this is not the best solution, since it does not work well when a new dependency is added, but it works well with dependencies added before.

[stevespringett]

This issue should be resolved for all new generated SHA1 hashes and corrects existing records.

[CalldiDoctor]

I still see a problem here, the code now adds 8 characters in order to avoid the problem of the supression.xml parser. However, this si not creating a real SHA1 nor MD5 hash. The methods setMd5() and setSha1 of the libraryVersion class are nto called anywhere. Thus, in this check

dependency.setSha1sum((libraryVersion.getSha1() != null) ? libraryVersion.getSha1() : libraryVersion.getUuidAsSha1Hash());

the condition is always false and the sha1 is set as "00000000".concat(uuid.replace("-", ""));.
I would suggest to set the sha1 and md5 when the libraryVersion is created.

Another point is that if this hash is the same for 2 different components, then it won't be possible to suppress a vulnerability from just one of the components.

[stevespringett]

You're correct in that the setMd5 and setSha1 methods are never called. This will be changed by #4 . The idea is that when the Dependency-Check XML reports are imported, or when the (future) RESTful API is invoked, that the Md5 and Sha1 values will be set with real hash values. This will not only be used in the suppression file, but to assist Dependency-Track in identifying what the component is.

As part of this enhancement, the values will also be settable on the add/modify form when adding a library version.

I figured I'd leave the database fields (and setters/getters) in place so that I wouldn't have to worry about SQL upgrade code later on.

[lock]

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.