How do you security test software when you have no source code?

Without source, test from the outside. Inventory what the binary bundles, run it in a controlled environment, probe its inputs with fuzzing, scan any network interface it exposes, and press the supplier for evidence. Static source analysis is off the table, though some tools can analyse compiled code.

What you can still learn

Closed components are common: a vendor SDK, a compiled plugin, a legacy service whose repository vanished. Four angles still work.

1. Inventory. Find out what the component bundles. Packaged libraries, embedded runtimes and container layers often reveal known-vulnerable parts. OWASP notes that an accurate inventory is the base for component risk analysis, and that SBOMs and dependency management can help build it. Ask the supplier for an SBOM first, then check it against what you can observe.

2. Black-box scanning. If the component listens on a network port or serves a web interface, a dynamic scanner can probe it from outside. OWASP describes these tools as scanning applications "normally from the outside" for issues such as injection and insecure server configuration.

3. Fuzzing. OWASP's fuzzing page says that when a tested system is totally closed, fuzzing is one of the only means of reviewing its quality. You send malformed input to a file parser, protocol endpoint or command line and watch for crashes and odd behaviour.

4. Binary analysis. OWASP's source code analysis page notes that some static tools can analyse compiled versions of code, and lists running against binaries as a selection criterion. Support varies a lot by language and format, so test it on a sample.

Rules before you start

• Get written permission. Testing a vendor product can breach licence terms, and testing a hosted service without consent can be unlawful.
• Use an isolated copy, never production.
• Record the version tested. Results do not carry over to the next release.

A short workflow

1. Request an SBOM, a vulnerability disclosure contact and any test summaries from the supplier.
2. Build your own inventory from the package or image and compare.
3. Run the component in a sandbox with logging on.
4. Scan exposed interfaces, then fuzz the riskiest input path.
5. Log findings, report to the supplier, and decide whether to keep, wrap or replace.

What the results cannot tell you

Fuzzing finds crashes and unexpected behaviour. It does not prove logic is correct. OWASP also cautions that fuzzers tend to find simple bugs, so a quiet run is not a clean bill of health. Black-box scanning sees only what the interface reveals. Treat every result as partial and keep compensating controls, such as network isolation and least privilege, around the component.

Where Safeguard fits

For the inventory step, Safeguard's SBOM and dependency scanning can read container images and package files to list what a bundled component carries, and reachability analysis helps judge which findings matter for your use. It does not decompile or fuzz proprietary binaries. The free scan is at https://gold.safeguard.sh/scan.

Quick check

Sources

• OWASP Fuzzing
• OWASP Component Analysis
• OWASP Source Code Analysis Tools
• OWASP Vulnerability Scanning Tools

Last reviewed: 19 October 2026.