Safeguard
Developer Tools•

What does FilesAnalyzed false mean in an SPDX SBOM?

FilesAnalyzed false means an SPDX package is a reference to a component whose files were not analyzed. What that changes for checksums and license fields.

Safeguard Security Team
3 min read

FilesAnalyzed false means the package entry is a reference to an external project or component whose files were not analyzed. It carries metadata, not content. The spec says such a package shall not contain files, and it removes a few fields that depend on file analysis.

The field in plain terms

Files analyzed is a boolean on an SPDX package. If you leave it out, it defaults to true. That default matters, because tools that emit package entries for dependencies they only know by name often need to set it to false explicitly.

When it is true, the package entry is describing content the creator looked at, which can include the files inside it. When it is false, the creator is saying: this thing exists, here is its name and version, but I did not open it.

What changes when it is false

According to SPDX 2.3.1:

  • The package must not contain files.
  • The package verification code must be omitted.
  • License information from files must be omitted.

Those make sense. A verification code is computed from the files in a package, and you cannot compute it if you did not read the files. A package checksum of the archive is a different field and can still be given if you have the archive.

Why this shows up in real SBOMs

Most dependency SBOMs list libraries by name and version, taken from a lockfile or registry metadata. The tool did not unpack each one. Those entries are exactly the kind of external references that files analyzed false describes.

Seeing false on most entries is normal. It is not a defect.

What to take from it as a reader

It tells you the depth of the data. For entries with false, license and file level facts, if present, came from metadata rather than from a scan of the contents. Treat licenses on those entries as declared, not verified.

For entries with true, the creator claims to have looked inside, so you can expect file lists and a verification code, and you can use the code to check whether files changed.

What to take from it as a writer

  1. Set the field deliberately. Do not rely on the true default for packages you did not open.
  2. Do not emit a verification code with false.
  3. If a customer needs file level evidence for a component, you must analyze it and set true.
  4. Explain your approach in the cover note.

For the checksum side, see SBOM component hashes.

Quick check

Is false a sign of a poor SBOM?

No. It is the honest value for dependencies you list from metadata without opening them.

What is the default if the field is missing?

True, according to the 2.3.1 spec.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.