AMaslov317333 (Community Member) asked a question.
How to disable reporting flaws originating from 3rd-party static vendor libraries?
Veracode website does not provide ability to mark 3rd-party vendor static libraries to be ignored from analysis and/or reporting. Marking libraries as "not entries" is only possible for shared libraries.
How to set to ignore flaws reported from 3rd-party static vendor libraries?
.png){kind=logo}
Hi @AMaslov317333 (Community Member) ,
There are several things you can do to ensure Veracode Static Analysis is able to give you the best possible results with regards to third party libraries:
* In the pre-scan phase Veracode Static Analysis identifies 'Scannable Modules', typically identified by an entry points (that part of the module we think might be user facing). Please ensure you are not selecting modules with an entry point that is a third party library.
* Veracode Static Analysis has improved results for many common publicly available third party libraries, however it needs to be identified first, so please ensure you are providing us with unconcatenated, unminified, unobfuscated, unchanged library to us. For common third party libraries that you would like us to investigate improving our results please contact Veracode Support.
* If you do not want us to analyse a library, you can chose to omit it from what you provide for scanning. For compiled languages like .NET or Java this may impact any results from functionality that references the library.
Please do note that third party software, still means first party risk.
If you are building a house and use third party wooden planks that turn out to be rotten or you're using it incorrectly (bearing too much weight) it will still be *your house* that collapses on *you*.
If you are aware of flaws in third party software that you are relying on we recommend you work with the vendor to get the flaws remediated.
Thank you,
Boy Baukema
1) In the "pre-scan phase Veracode Static Analysis identifies 'Scannable Modules'," - I only see our executables as entry points. I assumed you cannot list static libraries separately, for me to un-check them during this "pre-scan" step - is that an accurate assumption?
2) I will file "support ticket" for Veracode to review scan of the 3rd-party library. But unless there is a way to separate concerns, I will have to omit that static library from further submissions.
3) While your reasoning is academically sound, in practice few companies could afford to allow their dev teams to actively correct external vendor library, especially ones that has been vetted through heavily usage over the years. I also suspect many reported flaws are false positives.
Thank you for your input.
1) If you only see your executables as entry points, then this is correct. We will always show selected modules in the Review Modules / pre-scan results.
2) Okay, thank you. Depending on your budget and appetite for risk, omitting the library can be a reasonable choice.
3) Investigating security properties and hardening of libraries that the security of your application is relying on, especially if they are not recognised by Veracode Static Analysis, may or may not be a worthwhile exercise. Again this depends on your appetite for risk and your budgets. Popular third party libraries typically have many mitigating controls already in place that may simply not have been picked up with Veracode Static Analysis, this can only be discovered by reviewing the source code. If you can discover those controls, you can document them as mitigation proposals and keep the library in the scan. But it's important to note that third party libraries, even those heavily used, are not by themselves automatically secure (see also HeartBleed and the Equifax breach).
Thank you,
Boy Baukema