Wayfinder / Case study / CSI reports

CSI baseline CSI-IFX-2026-10-22 · 22 October 2026. Limited to the registered source set. Application execution and proposed tests were not run; source findings do not establish runtime behaviour.

Informix4GL Demo: baseline, provenance and limitations

In this document

Baseline date: 22 October 2026 · Preserved assessment

The baseline being preserved

This report set presents a dated assessment of retained application documentation, evidence summaries and external source checks. The external observations were recorded on 22 October 2026. Publication expands the assessment into nine readable reports without changing the original baseline's finding states or marking any proposed task complete.

The retained output is documentation. It does not establish a completed specification, a modernisation implementation, a later production result or a verified deployed application. The exact upstream source revision analysed by that documentation is not bound by the retained provenance. A repository reference cannot supply that missing attestation. IFX-S-README IFX-S-STATUS IFX-S-PROVENANCE

Baseline counts and states

Record type Baseline state
Component inventory 8 declared component records; incomplete deployment and binary identities.
Source register 17 sources: 11 retained evidence records and six external vendor/advisory records.
Findings 4: one externally correlated support finding, one qualified vulnerability candidate, one conditional compatibility finding, and one rejected family-only vulnerability match.
Relationship model 22 source-mapped relationships, including unresolved iText/framework use and target/Java compatibility.
Verification tasks 5, all not run.
Historical lookup records 8, including non-results and partial retrievals.

The counts describe the preserved assessment model, not a measure of application completeness or security coverage. The individual sources, findings, relationships and tasks are enumerated in the accompanying reports.

Finding state preserved for comparison

Finding State on 22 October 2026 Evidence needed to revise it
IFX-F-001 Declared iText 2.1.7 belongs to an unsupported family. Exact artifact, actual use, and the resulting support/removal/replacement decision.
IFX-F-002 CVE-2017-9096 candidate; package identity and application parsing path unresolved. Binary and patch provenance, parser callers, input origins, runtime use and controls.
IFX-F-003 Conditional Informix/Java upgrade prerequisite. Precise target and evidence that its Java requirements are provisioned and verified.
IFX-F-004 Family-only CVE-2021-20515 match rejected for the declared FC5 archive. Actual server identity for any environment-specific disposition; a different build needs its own comparison.

Sources: IFX-S-E0014 IFX-S-E0012 IFX-S-ITEXT-EOL IFX-S-XXE IFX-S-IBM-JRE IFX-S-IBM-20515.

Limits that affect a decision

Source and deployment identity

The analysed source revision is unbound. Jar hashes and manifests are absent, and the live server, edition, image digest, Java distribution and relevant driver/framework versions have not been observed. Findings based on a declaration must remain scoped to that declaration until IFX-V-001 supplies the missing binding. IFX-S-PROVENANCE IFX-S-C10 IFX-S-E0014

Framework and parser behaviour

The report framework implementation is not available in the retained analysis. Its relationship to iText, report buffering, exception cleanup and monetary semantics are unresolved. Named report callers and post-commit invoice invocation establish useful business context, but they do not prove an iText call or a vulnerable PDF/XML parsing route. IFX-V-002 addresses that missing evidence. IFX-S-E0012 IFX-S-XXE

Different implementation surfaces

The retained documentation contains Java and Informix-4GL materials with overlapping business names and different implementation details. Java menu stubs cannot be described as implemented because a 4GL path has corresponding logic. Conversely, a local evidence gap in one analysis does not prove that a component is absent from every retained source. The executable and build must be named when comparing behaviour. IFX-S-C07 IFX-S-C13 IFX-S-C14

Test and remediation status

IFX-V-001, IFX-V-002, IFX-V-003, IFX-V-004 and IFX-V-005 are all not run. Proposed report, order, rollback, invoice and totals scenarios have no recorded execution result in this assessment. No dependency removal, replacement or server upgrade is claimed complete. IFX-S-C13

External lookup coverage

The source checks were bounded. No applicable SwingX finding was established; this does not prove support or absence of vulnerabilities. The Informix lifecycle lookup did not establish an EOS date or an entitlement conclusion. Some linked Log4j bulletin retrievals timed out. Unversioned dependencies and images prevented precise matching. Those outcomes remain explicit in the evidence report's coverage summary. IFX-S-C10 IFX-S-E0014 IFX-S-IBM-LIFECYCLE IFX-S-IBM-LOG4J

Public review surface

Public vendor and advisory sources are linked. Private application evidence remains retained for review under its citation IDs. The public edition omits private repository locations, raw evidence packs, operational identifiers, endpoints and credentials. This means a reader can inspect the external correlation directly, while application-specific claims may require access to the retained evidence through an appropriate review.

How a later assessment should record change

Preserve this dated baseline and create a new dated assessment. For each changed component, finding or relationship, record the previous state, new state, evidence collected, observation date and reason for the decision. A new source retrieval is a new observation even if the URL is unchanged. A newly observed server or jar must not be retroactively treated as the environment that the original documentation analysed.

Carry task outcomes forward with the exact build, environment, scenario and evidence. Mark an unresolved relationship documented only when evidence supports it. Keep a rejected candidate's scope and rationale visible, and separate a support decision from a vulnerability disposition. This allows a reader to see whether the change came from a new artifact identity, new external information, a resolved application path or an executed verification result.