Software supply chain security, from source to runtime.

Assess the repository and its dependency inputs

The specification includes Git repository exposure, branch and release controls, lockfiles, package provenance, vulnerable dependencies and malicious packages. Secrets in current files and repository history are part of the assessment.

A dependency declared in source may differ from the version in a deployed image. Useful evidence should preserve enough component and deployment identity to establish what is affected. Unresolved identity should remain a limitation rather than being replaced by a confident assumption.

Inspect the authority of the delivery system

CI/CD workflows, build runners, artifact integrity, deployment credentials and third-party integration privileges are explicit areas of review. A runner can become a sensitive trust boundary when it holds keys or can publish software to production.

Branch controls and review requirements describe one part of the system. The ability to change a workflow, substitute an artifact or use an overprivileged integration can introduce separate paths. The assessment should explain the relationship between repository permissions, build authority and release authority.

• Identify exposed repositories and unnecessarily broad integration access.
• Examine dependency and image provenance where evidence is available.
• Review secrets across source, history, build configuration and deployment.
• Record gaps in artifact identity or deployment traceability.

Fix the source of the risk, then check the deployed result

A proposed repair might update a dependency, tighten a workflow permission, revoke an exposed credential or strengthen a release control. Each action requires a bounded plan and appropriate review. A code change and its deployment are distinct events.

Verification should confirm that the intended correction reaches the running environment and that relevant tests still succeed. AI Defence’s ongoing scope includes new repository and dependency risks, while Remedy’s software repair discipline provides a related model for exact-state repair and deterministic gates. The cross-product integration must be confirmed before it is relied upon operationally.

Revalidate the resulting application state

A trusted publisher or signed update provides useful provenance, but does not justify permanent trust for every later module, extension or configuration change. The Continuous Integrity architecture compares the measured installation state and its authorised lineage.

An unexpected source change, modified service binary or new embedded component can require recertification. New intelligence may also invalidate a previously accepted unchanged object. The planned registry links affected observations to the evidence behind their verdict; it is not a guarantee against every supply-chain attack.