CSI baseline CSI-CARD-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.

CardDemo: component inventory

Assessment baseline: 22 October 2026. Eight component records identify the inspected application elements and their dependencies. They describe the retained evidence, not a verified inventory of a running installation. Installed middleware releases, maintenance levels and executable bindings remain unknown. CARD-SRC-01 CARD-SRC-05 CARD-SRC-06

Components supported by the inspected material

This is a focused inventory for the two assessed paths. It is not an exhaustive software bill of materials, an installation discovery result or proof that every optional dependency is enabled.

What the inventory can already connect

The authorisation trace connects the handler, MQ, IMS and CICS to an externally visible credit decision and the recorded authorisation state. The account-maintenance trace connects COACTUPC, CICS and the two file resources to paired update integrity and concurrent-change handling. These are useful relationships even before a vendor notice is matched. CARD-SRC-02 CARD-SRC-03 CARD-SRC-04 CARD-SRC-08

Installed information required to complete the inventory

The next inventory should be dated and tied to the actual environment selected for review. For each MQ, CICS, IMS, Db2, COBOL compiler and z/OS dependency in that environment, collect the exact product name and edition, platform, release, maintenance or fix level, and the evidence used to establish those values. The inspected material does not provide that binding. CARD-SRC-05 CARD-SRC-06

Record the application-to-runtime deployment relationship as well. Confirm whether the optional authorisation extension is enabled, identify the deployed COPAUA0C and COACTUPC builds, and reconcile them with the selected source baseline. A technology named by a README can only be matched to a notice once the relevant installed component has been established. CARD-SRC-01 CARD-SRC-05 CARD-SRC-06

The two paths also need configuration evidence:

• For authorisation, record request/reply queue definitions, message persistence policies and transaction integration settings alongside the installed MQ/CICS/IMS identities. These determine the environment in which the source boundary will be characterised. CARD-SRC-02 CARD-SRC-06
• For account maintenance, record installed ACCTDAT and CUSTDAT FILE definitions, corresponding ICF catalog LOG attributes and the effective recovery interpretation. The retained sample declaration cannot substitute for this evidence. CARD-SRC-04 CARD-SRC-12 CARD-SRC-13
• For lifecycle assessment, attach the applicable support arrangements to the exact installed product and release. No support deadline is supplied by the current inventory. CARD-SRC-05 CARD-SRC-06

Values that must remain separate

The sample project's version badge, an IBM documentation URL's version, an archive identity and an installed runtime release answer different questions. None can fill another field by inference. In particular, the MQ 9.4.x and CICS 6.x documentation references provide API or configuration context; they do not establish those product versions in CardDemo. CARD-SRC-05 CARD-SRC-10 CARD-SRC-12 CARD-SRC-13

CARD-TEST-04 remains not run. Until the inventory is bound, the application graph can guide a future notice review, but it cannot establish a vulnerability or lifecycle match.