Interpreting CVE Scan Findings in Adobe PDF Library

Overview

If your organization runs software composition analysis (SCA) against the binaries you ship, APDFL will eventually appear in a report. The libraries APDFL incorporates are statically linked into the binaries we build, so you cannot update them yourself, and a list of CVEs attributed to a library you have no direct control over is an uncomfortable thing to hand to a security team.

Some of those findings are genuine, and are best resolved by moving to a current APDFL release. Many are artifacts of how a scanner determines a component's version from a compiled binary.

This article explains how APDFL is assembled, why version detection behaves the way it does against our binaries, and how to work out which category a given finding falls into before raising a case.

It is deliberately not tied to a particular APDFL release, component version, CVE, or scanning product. The specifics change every month; the reasoning does not.

Step 1: Identify Exactly Which Build Was Scanned

Almost every confusing report begins here. A finding against "APDFL v21" is not actionable until it is a finding against a specific patch release.

There are two reliable ways to identify a build:

1. File version resource
   Right-click any `DL*.dll` → Properties → Details, or read the resource programmatically. The `ProductName` field names the exact release — major version and patch level together, in the same form used in the release notes and on the download site. This is usually the fastest answer.
2. File hashes
   SCA reports normally include a SHA1 or SHA256 per object. Datalogics Tech Support can match those against our build archive and tell you precisely which release produced them, including whether it is the release you believe you shipped.

Be careful with a report's "compilation date" or similar fields. Depending on the tool, these can reflect when a package was assembled rather than when the binary was built, and they can sit close to a release date without corresponding to it.

It is common for the scanned build to be one or more releases behind the current one, in which case some findings resolve simply by upgrading.

Step 2: Read the SBOM for That Build

APDFL ships CycloneDX SBOMs in `Documentation\sboms\`. These are the authoritative record of which component versions went into that release.

Component identifiers take the form `pkg:conan/<component>@<version>`. The `conan` prefix matters, and is explained in Step 3.

Two things to know about scope:

1. SBOMs are published **per subsystem**. The core library has one, and separately packaged subsystems have their own. A component absent from one file may be recorded in another.
2. Coverage of some subsystems is still being extended. If a component you can see in the product is not enumerated in any SBOM, that is a gap in the SBOM rather than evidence the component is absent. Ask Tech Support and we will tell you the version.

Step 3: Understand How APDFL Is Composed

Four characteristics of the product account for most misattributed findings.

1. One Source Package per Component
   APDFL is assembled using **Conan packaging**. Each third-party component has a single source package, and every part of the product that uses that component is built from it. Subsystems do not carry private copies that drift apart.
   
   The practical consequence: when an SCA tool reports the same component against several APDFL binaries at *different* versions, those cannot all be right. There is one version of that component in the product, and the SBOM states it.
   
   
2. A Component Can Be Linked into Several Binaries
   Conversely, one component legitimately appears in several binaries. A library statically linked into three DLLs will be reported three times. That is three reports of one component, not three separate copies to update, and the CVE count in a report inflates accordingly.
   
   
3. Some Components Are Patched, Not Stock
   Certain components in APDFL are not stock upstream code. Some were customized for APDFL by Adobe; Datalogics maintains them and applies upstream security fixes to keep them current.
   
   This defeats version fingerprinting. A patched fork does not match upstream signatures exactly, so a scanner comparing against stock releases tends to settle on an older baseline even where current security patches have been applied. The reported version number describes the closest signature match, not the patch level.
   
   
4. Some Components Are Not Third-Party at All
   Parts of APDFL originated with Adobe and are now Datalogics-maintained source rather than a third-party dependency. They do not appear in our SBOM as components because they are not components.
   
   A scanner has no way to know this. If it recognizes such code and matches it to a separately published Adobe product of a similar name, it will attach that product's CVEs. Those CVEs are raised against a different codebase.

Step 4: Understand Why a Detected Version May Be Wrong

Whether a scanner can read a version or has to infer one makes a large difference to accuracy, and you can often tell which happened.

**Where a component publishes a version banner in the binary**, detection is usually accurate, and a version reported this way is worth taking seriously.

**Where it does not**, the tool must infer from a code signature. There are two common causes of a missing banner:

- The component never embeds one.
- The linker discarded it. If nothing in a binary calls the function that reports a component's version — or its error-string table — that data is unreferenced, and dead-code elimination removes it. The component is fully present; its self-description is not.

Inferred versions tend to fail in one direction: they land on an **older** release than what is actually present. That in turn attaches CVEs which were fixed before the version you are running.

A useful diagnostic: if a report shows the same component detected at different versions in different APDFL binaries, the one detected from a readable banner is likely correct and the others are inferred.

Version Resources Describe APDFL, Not the Component

Every APDFL binary carries a Windows version resource identifying the release: a `ProductVersion` holding the APDFL version, and a `FileDescription` naming the subsystem. Those fields describe our product.

If a scanner takes a `FileDescription` as a product identity and the accompanying `ProductVersion` as that product's version, the result is a component "version" that is really the APDFL release number. A detected version that looks conspicuously like the APDFL version is worth checking for this.

Step 5: Check the CVE Against the Version Actually Shipped

Once you know the component version from the SBOM, check it against the CVE directly rather than relying on the scan's verdict.

Most upstream projects publish their own advisory data, often machine-readable, stating which release each issue was fixed in. Comparing "fixed in" against the SBOM version is usually decisive, and it is evidence your security team can verify independently rather than taking a vendor's assurance.

Watch for two things:

1. CVSS scores differ between sources
   A scanning vendor's own severity rating often differs from NVD's, in both directions. Be clear which you are quoting.
2. Fixed-in versus published dates
   A fix landing in a project's repository is not the same as a release containing it. What matters is the first *release* carrying the fix.

Release Cadence: What to Expect

APDFL is released on a near-monthly cycle, and we keep third-party components current as a matter of course.

Component versions are frozen when a release build is made, and QA runs before the release is published. There is therefore an inherent, short window between a fix appearing upstream and it reaching you in a tested release. A finding whose upstream fix is only days or weeks old may simply be newer than the release you have; the following release will normally carry it.

This cuts both ways, and it is worth saying plainly: a current APDFL release can contain a component with known vulnerabilities published after that release was built. Upgrading to the latest release is the correct response to most findings, but it is not a guarantee of a clean scan at every moment in time.

What to Send Us

If a finding does not resolve through the steps above, contact Datalogics Tech Support with:

- The APDFL release, identified by `ProductName` or by file hashes.
- The component and version the tool reports, and which binaries it reports them in.
- The CVE identifiers
- The evidence the tool used to determine the version - the matched file, offset, or signature, if your tool exposes it. Where a version was inferred rather than read, this is often the only way to establish why the inference is off, and it is the most useful single thing you can send.

We are happy to assess findings individually, and to supply the SBOM for any release you need for your own records.

How to Get Additional Help

Contact Datalogics Tech Support 

Have questions while using APDFL? Fetch the answers quickly using our AI assistant Scout, available for any language. Scout also opens access to our MCP server, connecting APDFL with your favorite AI tools for faster and easier coding.