TC-16 Vulnerability identification and remediation
| Objective | TC-16 |
| Evidence level | Evidence, Integrate |
| Domain | Security and risk fit |
| Owner | Raidiam for the platform and the demonstration components. CBA's process applies to the Formal Proof of Concept environment. |
| Phase | Formal Proof of Concept |
| Proven by | content-vulnerability-management |
On what is claimed here. Where this document describes the demonstration, it states what the Enhanced Vendor Demo of 24 August 2026 is built to prove, not what has already been built, recorded or verified. Status for every scene is tracked in objectives/tc-objectives.yaml.
1. What CBA asked for
Vulnerability identification and remediation approach for PoC components.
2. Three estates, three answers
As in content-hardening.md, the answer differs by estate and merging them would be misleading.
2.1 The Raidiam Connect platform
A production service carrying live traffic for schemes including ConnectID. It is covered by Raidiam's production vulnerability management process. The specific artefacts CBA will want, including the remediation targets by severity, the scanning coverage and the most recent independent test results, are documentation requests and are supplied through ID Partners under the appropriate agreement. They are listed in section 5 rather than paraphrased here, because paraphrasing a service level from memory is how a commitment gets made by accident.
2.2 The demonstration components
Built for 24 August 2026, vendor hosted, synthetic data, no CBA connectivity, torn down afterwards.
| Practice | Position |
|---|---|
| Dependency provenance | All dependencies pinned by lockfile. The build resolves nothing at build time. |
| Dependency scanning | Automated advisory scanning against the lockfile in continuous integration, so a known vulnerable dependency is visible before deployment rather than after. |
| Base images | Pinned and rebuilt from a current base on every deployment, so operating system level fixes are picked up by redeploying rather than by patching a long lived host. |
| Patch route | Redeploy. There are no long lived hosts to patch, and the environment is redeployed frequently during build. |
| Remediation | For an environment holding no real data and reachable only as a public demonstration, a high or critical finding on a component is fixed by upgrading and redeploying before the demonstration. There is no ticketed service level because there is no service. |
| Exposure window | The environment has a defined end date and is destroyed rather than abandoned. An unmaintained demonstration environment is a common source of real incidents and this one is not left running. |
2.3 The Formal Proof of Concept environment
Not built. CBA's vulnerability management process applies to anything holding CBA data or touching the CBA network, and ID Partners delivers against it. The scoping questions are in section 4.
3. How CBA reports a vulnerability to us
A finding in the platform or in any component supplied for this engagement should be reported through ID Partners as the contracting party, who route it to Raidiam engineering. For anything believed to be exploitable, that route should be used rather than a demonstration feedback channel, and CBA should expect an acknowledgement and an owner rather than a fix on first contact.
If CBA prefers a direct disclosure route to Raidiam for security findings, that should be agreed at contracting rather than improvised during an incident.
4. Scoping questions for the Formal Proof of Concept
Answers needed from CBA and ID Partners before the environment is built.
- May CBA's scanners point at vendor operated infrastructure? Ordinarily they may not, without written authorisation from the operator and, for cloud hosted services, from the cloud provider's testing policy. This is a permission question with a lead time, and it should be raised early rather than the week before.
- Which components fall inside CBA's vulnerability management scope, and which are treated as vendor supplied service.
- Whether a penetration test is required for the Proof of Concept, who performs it, against which scope, and who remediates.
- The severity model and remediation windows CBA expects to apply, and to which estate.
- Whether a software bill of materials is required for components delivered into the CBA environment. Worth noting that recording a bill of materials reference against an Agent Identity is demonstrated in scene 08 as an evidence pointer, which is a different question from producing one for the platform, and the two should not be conflated.
- Who accepts residual risk for the Proof of Concept environment, and at what point.
5. Documentation to request through ID Partners
- Vulnerability management policy, including scanning coverage and remediation targets by severity.
- Current certification and independent assurance status.
- Most recent penetration test summary and remediation position.
- Patch and release cadence, and the process for an out of band security release.
- Security incident notification commitments.
These are contractual and commercial artefacts. They route to ID Partners and are not scoped or priced here.
6. Status
Practices for the demonstration estate are as described in section 2.2 and are proportionate to an environment with no CBA data and no CBA connectivity. Platform level artefacts are available on request through ID Partners. Formal Proof of Concept scope is not agreed and is listed as questions rather than claimed as answers.