Hello KMittal,

The best option to go over the results is to Schedule a Consultation Call.

Please check this link to get more information about how to Schedule a Consultation Call.

https://docs.veracode.com/r/t_schedule_consultation

Best regards,

Fabiano

Veracode Inc.

Hi @[KMittal]​ ,

TL;DR: We recommend you remove the API wrapper from your upload to Veracode or deselect it during module selection. These flaws are mitigated.

Thank you for submitting this question, it touches on 3 issues we see frequently:

1. Incorrect packaging / entry point selection.

Veracodes API Wrapper is a tool used for working with our various analyses. As with any other non-production tool we don’t recommend analyzing it with Veracode Static Analysis unless you have a lot of experience with Veracode Static Analysis and are making the conscious decision to expand your analysis.Results from analysis of these tools will be a lot harder to triage as they are further removed from the user and so require the attacker to have a lot more access.

This is not to say that an attacker could not infect a developer machine, however, if they have done so, they will likely not bother to try to find vulnerabilities in your tooling but will simply use your access to internal resources to for example upload a rootkit to a staging server to get a foothold.Getting your packaging and module selection right is important because as the old adage goes “Garbage in, garbage out”. Because we realize that Static Analysis is likely not your full time job, we have the Application Security Consulting service (mentioned above). It is our job to work with our analyses full time and we’re happy to help review your packaging to get the best out of our analyses.

2. Scanning (commercial third party) binaries without involving developers.

Analyzing a binary without developer support will typically yield flaws that are impossible to work with.

As in the current case, is there any risk? It depends on various controls and is impossible to say without deeper understanding of the code and what it’s doing.Please also note that analyzing binaries without permission from the owner may entail some legal risk. Various companies have strict terms and conditions prohibiting analysis of their binaries. While many countries will have laws stating that security analysis cannot be forbidden by a contract, it is worth checking with your legal team for your specific circumstances.

3. Not all ‘fixes’ can be automatically detected, many flaws will have to be investigated and manually mitigated.

CWE 73 is a flaw that commonly requires mitigation please consider reading more on this topic in the following Community article: https://community.veracode.com/s/article/how-do-i-fix-cwe-73-external-control-of-file-name-or-path-in-java

Having said that, what’s up with the CWE 73 flaws in VeracodeAPI.jar?

The 2 CWE 73 flaws are reported in VeracodeAPI.jar as we look for the credential file in the following location:

System.getProperty(“user.home”) + File.separator + “.veracode” + File.separator + “credentials”

Veracode Static Analysis is raising these flaws as it sees System.getProperty, warning that if any property is under attacker control this might be used to change the file path to unintended files and directories.

We recommend you review how ‘user.home’ is set on your machine, though typically this is set to the default value (for example for my OS X machine it will be “/Users/bbaukema”).For an analysis tool, running on a developer / CI machine, we believe the risk that user.home is attacker controlled is sufficiently small to be negligible. In our analysis results we have mitigated this flaw ( for more information please see: https://docs.veracode.com/r/improve_mitigation ).

An example mitigation for this flaw might be:

Technique: M5: Use industry-accepted security features instead of inventing your own

Specifics: System property is used to read ‘user.home’, location for ‘./veracode/credentials’ file. This property is difficult for an attacker to control without broad access and even if controlled can only be used to read a ‘./veracode/credentials’ file.

Remaining Risk: If the user.home system property is attacker controlled, this might be used to read ‘/.veracode/credentials’ from another location.

Verification: Manual review, Veracode Application Security Consultation, Unit Test at DefaultCredentialsServiceTest.java

For your application, this may be different. We recommend reviewing this on a case-by-case basis, there too if you would like our expertise please feel free to schedule a consultation.

Thank you,

Boy Baukema