Answer yes, then add three specifics: that you keep an inventory of the open source components in each release, that you check them for known vulnerabilities and license terms, and that someone owns the process. A short, concrete yes builds more trust than a long defensive paragraph.
Why the question is asked
Nearly every modern application includes open source libraries, so a customer asking "do you use open source?" is not hunting for a yes or no. They want to know whether you can see what you ship and whether you act on what you see. NIST's Secure Software Development Framework, SP 800-218, treats reuse of third-party and open source components as normal and asks producers to review them, verify them and keep them updated (practices PW.4.1 and PW.4.4).
Saying "no" when the answer is yes is the worst reply. It usually comes out later in an SBOM or an audit, and it costs you credibility on every other answer.
A reply structure that works
Use four short parts.
- Confirm. "Yes, our products use open source libraries and frameworks, as most modern software does."
- Show visibility. "We generate a component inventory for each release and keep it with the build record."
- Show action. "New advisories are matched against that inventory, and we triage by exposure and severity."
- Offer evidence. "We can share our open source policy summary and a recent component list under NDA."
Only claim what you do today. If the inventory is generated per release but advisories are matched weekly, say weekly.
Example reply
Yes. Our application uses open source libraries, mostly for web frameworks, parsing and cryptography. We keep a per-release component inventory, review new dependencies before they are added, check the inventory against public vulnerability data, and track license terms. Happy to share the policy summary or an SBOM under NDA.
Notice what is absent: adjectives, promises of zero risk and the word "secure" used as a label.
What to prepare before you reply
| Item | Why a customer may ask |
|---|---|
| Component inventory or SBOM | Proof you can see what you ship |
| Policy summary | Shows rules exist and are owned |
| Vulnerability handling steps | Shows what happens after an advisory |
| License review approach | Shows distribution terms are checked |
If any row is missing, say it is in progress with a date rather than implying it exists. The related post on what to send when a customer asks for your SBOM covers the file itself.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory view and note how direct and transitive components appear side by side. That is the evidence behind the "yes".
Safeguard produces SBOMs and runs dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see what an inventory looks like for your own project.
Quick check
Is it risky to admit we use open source?
No. Customers assume it. The risk is in being unable to describe how you manage it.
Should we send the full dependency list immediately?
Offer it under NDA first. Some customers need just the policy summary, and a list can be read out of context.
Sources
Last reviewed: 19 October 2026.
