Blomgren (Community Member) asked a question.
We’ve run into an interesting challenge and are curious how others are approaching it.
When proprietary third-party libraries (not open source, and not known to Veracode’s SCA database; these are libraries provided by a vendor/partner which you include in your 1st party application) are included in your codebase, Veracode treats them as first-party code during static analysis. That introduces some nuanced pros and cons — and we’d like to hear how other teams are managing this.
Reasons You Might Include the Vendor Code in SAST:
- Added security assurance beyond standard vendor risk assessments, which may be compliance-heavy and light on technical validation.
- Could uncover critical security flaws (ex., hard-coded credentials, insecure crypto) that aren’t found by DAST or SCA.
- SAST results for 1st party code may be incomplete/unreliable if it's tightly integrated with the vendor-provided library and that library was not included in the SAST upload files.
- Helps identify issues early — especially if the end product is not yet deployed.
Reasons You Might Exclude the Vendor code in SAST:
- Licensing restrictions: Uploading vendor code to a cloud service like Veracode may violate terms of use.
- SAST is designed to be baked into the SDLC, but this approach is scanning the vendor's code after its been shipped
- Potentially large number of findings discovered/reported all at once (due to scanning after shipping), can overwhelm vendor
- Difficult to cleanly separate which findings belong to your team vs. the vendor, increasing triage burden.
- May require extra coordination between internal security team and vendors to properly propose mitigations in a way that is consistent/acceptable with internal practices
- If DAST scanning is performed, it can provide some security assurance of the end-product while maintaining reasonable expectations for the vendor
- Vendors may not be willing to address code-level "flaws" without proof of exploitation (which can only be provided via DAST/PT).
We’re interested in how others — especially Veracode customers — are approaching this edge case.
Have you included proprietary vendor libraries in your SAST scans? Why or why not? What practices or policies have worked well for your team?
.png){kind=logo}
Hi @Blomgren (Community Member) - Great question! Thanks for kicking off the discussion. I asked around internally and received a couple of answers that I'll share here:
1) This article is often shared RE this topic, with #4 often being suggested to be looked at first: https://community.veracode.com/s/article/How-to-fix-a-Veracode-Static-Analysis-flaw-in-third-party-software
2) "IMO, treating them like first party code seems like a reasonable approach. It seems likely to give the most accurate results for SAST (not sure how it figures in to SCA itself)
The tricky part is what to do with flaws that are reported inside the third party library. My recommendation would be to use the data path to find the crossover point from the true first party code into the third party library — that’s where you’ll need to apply a fix. And if you’re feeling generous, tell the third party library developers about the flaw."