Six essays in this series have each ended the same way, by deferring something to a closing checklist. This is that essay, and it arrives at a specific moment. The Canadian Program for Cyber Security Certification opened Level 1 in April and its requirement lands in select defence contracts this summer.1 The Defence Industrial Strategy promised a framework for identifying key strategic partners “no later than summer 2026,” and it hasn’t appeared.2 Independent policy voices have started filling the vacuum themselves: a widely-read Policy Options piece in June documented that the Strategy targets lifting the Canadian share of defence procurement from 43% to 70% without ever defining what makes a company Canadian, and proposed a three-test definition of its own.3 The evaluation machinery is switching on faster than the evaluation criteria are being written.
What follows is a checklist for one slice of that problem: the supply chain that feeds a classified Kubernetes deployment. Fifteen criteria, in five groups. Each one gives the question in plain RFP language, the evidence that answers it, and the red flag that fails it. The criteria compress the arguments this series has made since May; where a criterion rests on an earlier essay, it’s linked.
How to score the answers
Before the criteria, the rubric, because the checklist only works if every answer that comes back is scored the same way. Vendor answers arrive in three kinds.
A structural answer is a property of how the vendor and its product are built: where an entity is incorporated, where a signing key physically lives, what a verification path can reach. Structural answers can be inspected, and they hold whether or not the vendor keeps its promises. A contractual answer is a commitment in an agreement: a data-residency clause, a no-disclosure pledge, an SLA. Contractual answers are worth having and are not sufficient, for the reason the federal privacy regulator has held for over a decade: no contract, no matter how well crafted, overrides the laws of a foreign jurisdiction.4 A rhetorical answer is marketing copy, and it fails on contact.
The rubric is one line: only structural answers pass. A contractual answer earns a follow-up question about the structure underneath it. A rhetorical answer ends the evaluation of that criterion.
The vendor
1. Incorporation and governing law, all the way up. Ask: state the legal name, jurisdiction of incorporation, and governing law of the vendor and of every entity in its ownership chain, to the ultimate parent. Evidence: corporate registry extracts and an ownership chart. Red flag: an answer about office locations, data-centre regions, or headcount in Canada. Those answer geography. The question is law.
2. Control and compulsion. Ask: which governments can lawfully compel the vendor or any parent, and does the customer hold an independent legal right to operate, modify, and maintain the product if a foreign parent is compelled or withdraws? The second half is the Canadian-controlled-IP test that Policy Options proposed in June, and it belongs in every software evaluation.3 Evidence: a foreign-ownership, control, and influence disclosure, plus the licence and IP terms that grant the independent right. Red flag: “our parent company respects Canadian law.” That’s a contractual answer to a structural question.
3. Ongoing dependence. Ask: if the vendor’s foreign upstream stopped cooperating tomorrow, what stops working, and when? The Defence Industrial Strategy names reliance on ongoing foreign software updates, intellectual property, and schematics as the thing to reduce.2 Evidence: the update and maintenance model, stated as what the customer can do alone. Red flag: subscription-keyed updates from a foreign parent, with no path that keeps the deployment maintainable without them.
The trust path
4. Custody of the signing identity. Ask: where does the private key that signs deployable artifacts physically live, and what does it take to exercise it? Evidence: hardware-custody attestation and a per-signature operator action. Red flag: a signing key resident in a build runner’s memory. The last year of supply-chain incidents is a catalogue of what happens next.
5. Domicile of the trust roots. Ask: list every external service the default verification path can reach, with the jurisdiction of each: certificate authority, transparency log, trust-root distribution. Evidence: the list, and the configuration that proves it’s complete. Red flag: a public transparency log or certificate authority under foreign jurisdiction anywhere in the default path. A Canadian cluster that verifies against foreign trust infrastructure has imported that jurisdiction into every deployment decision.
6. Verification with tooling the auditor already owns. Ask: can a third party verify a deployable artifact on an offline workstation using stock cryptographic tooling, with no vendor software present? Evidence: a live demonstration and a published procedure. Red flag: a vendor binary required at audit time. Vendor dependency at the moment of audit is itself a finding.
The supply chain
7. A jurisdiction-labelled dependency graph. Ask: produce the dependency graph of everything that enters the cluster (base images, registries, runtimes, vendored code) with each node’s publishing entity and jurisdiction labelled. Evidence: the graph itself. The government already runs this kind of scrutiny at scale; the Communications Security Establishment reports 1,772 supply-chain risk assessments across government in the last fiscal year.5 An evaluation that asks for the graph is aligning procurement with what security review already does. Red flag: “available on request.” The vendor that has the graph shares it.
8. A published artifact format. Ask: is the deployable artifact’s format a published specification that a third party can validate against without the vendor’s involvement? Evidence: the specification and an independent verification walkthrough. Red flag: an opaque proprietary format whose integrity can only be checked by the tool that produced it.
9. Provenance stated honestly. Ask: what provenance accompanies each artifact, and which claims are operator-asserted versus attested by a build platform? Evidence: sample attestations and a plain statement of the level actually delivered. Red flag: conflating the two, or quoting a provenance level the customer’s own build pipeline doesn’t support. June’s npm compromise, where a dependency was quietly swapped for a malicious lookalike across roughly 141 packages, is the current reminder of why per-artifact provenance is load-bearing,6 and the UK’s NCSC warns that follow-on attacks in this pattern are going undetected longer and spreading wider.7
The deployment path
10. Disconnected by default. Ask: does the product’s default verification and apply path function with the deployment network fully disconnected, with no reach-back of any kind? Evidence: a demonstration with the network removed. Red flag: licence pings, telemetry, identity-provider callouts, or an “air-gap mode” that’s a degraded afterthought rather than the designed path.
11. The transfer model. Ask: how does a deployment cross from the connected build side to the disconnected side, and what stops an old artifact from being re-applied? Evidence: the transfer procedure for diode, removable media, or audited copy, and a demonstrated replay rejection. Red flag: a transfer story that amounts to copying files and trusting the person who carried them.
12. Atomic apply. Ask: if power fails mid-apply, what state is the cluster in? Evidence: documented and demonstrated rollback semantics. Red flag: an undefined partial state. A classified cluster in an unknown configuration is an incident, not an inconvenience.
The evidence
13. Evidence emitted, not assembled. Ask: what record does the apply event itself produce? Evidence: a sample record showing which artifact, applied by which individual identity, at which time, under which enforcement posture, hash-chained so that altering a past entry breaks the chain, held in the operator’s custody, verifiable offline. The accreditation case for emission over collection is its own essay. Red flag: evidence gathered after the fact, or logs that anyone with filesystem access can quietly edit.
14. An audited bypass. Ask: when a deployment must proceed under conditions the verification rules refuse, what happens? Evidence: an explicit, named bypass operation requiring a justification, recorded in the same tamper-evident chain. Red flag: “that’s impossible by construction.” Operational reality always finds a bypass; the honest vendor builds one and audits it.
15. Control mapping without certification claims. Ask: map the product’s properties to the ITSG-33 control families they support, and state plainly what the vendor does not claim. Evidence: the mapping document. Red flag: a tooling vendor claiming CCCS certification, an authority to operate, or compliance on the customer’s behalf. Authorization belongs to the authorizing official. A vendor that claims it doesn’t understand the accreditor’s job.
What the checklist doesn’t do
It doesn’t score price, product maturity, or fit, and an evaluation still needs all three. It doesn’t replace the foreign-ownership review or the accreditor; it feeds them. Three of its criteria trace in part to a framework proposed in an opinion piece, not adopted policy, and are labelled accordingly.3 And it doesn’t pretend the fifteen are equally weighted for every workload. For a classified deployment, though, the criteria that decide sovereignty (1, 2, 5, and 10) aren’t tradeable against the others. A vendor can be excellent and still fail them, which is the point of asking.
The macro forces behind this list keep compounding. Canada’s participation in the EU’s SAFE procurement instrument was formally concluded by the European Council in June, which means Canadian vendors will increasingly be read against European eligibility rules as well as domestic ones.8 The EU’s proposed cloud law grades sovereignty in levels and reserves the top one for defence, a rubric this series has already mapped onto Canadian evaluation. The checklist above is what those instruments look like when they’re translated into questions a single RFP can ask this quarter.
Checklists get forwarded, which is why this one closes the series. An argument needs its author in the room. A checklist doesn’t; it needs a procurement cycle and a vendor willing to answer fifteen questions with evidence instead of copy.
Northfleet builds the sovereign supply chain that wraps a customer-operated classified cluster: a deploy-time bundle protocol, attestation chain, and tamper-evident audit trail, signed with the customer’s own keys and verified offline with stock cryptographic tooling the auditor already owns. The vendor never holds customer data, and the trust path between build and apply stays inside the customer’s jurisdiction end to end. The checklist above is the evaluation this product was built to answer.
If you’re evaluating sovereign infrastructure for classified workloads, bring the checklist. The conversation is open.
Footnotes
-
Public Services and Procurement Canada, “Government of Canada introduces Level 1 of the Canadian Program for Cyber Security Certification,” April 14, 2026. Level 1 self-assessment opened April 1, 2026, and “will be required in select defence contracts beginning in Summer 2026,” with third-party Level 2 assessments to follow in spring 2027. https://www.canada.ca/en/public-services-procurement/news/2026/04/government-of-canada-introduces-level-1-of-canadian-program-for-cyber-security-certification.html. ↩
-
Office of the Prime Minister, “Prime Minister Carney launches Canada’s first Defence Industrial Strategy,” February 17, 2026, including the commitment to reduce reliance on ongoing foreign software updates, intellectual property, and schematics, and the framework for key strategic partners promised “no later than summer 2026.” https://www.pm.gc.ca/en/news/news-releases/2026/02/17/prime-minister-carney-launches-canadas-first-defence-industrial. ↩ ↩2
-
Al Vigier, “Canada’s defence procurement strategy has a software problem,” Policy Options, June 22, 2026. The piece documents that the Strategy targets lifting the Canadian share of defence procurement from 43% to 70% without defining what makes a company Canadian, and proposes a three-test framework: auditability, data residency, and Canadian-controlled intellectual property. Cited here as a proposed framework, not adopted policy. https://policyoptions.irpp.org/2026/06/canadian-defence-procurement-software/. ↩ ↩2 ↩3
-
Office of the Privacy Commissioner of Canada, standing guidance on cloud computing: “no contract, no matter how well crafted, can override the laws of the foreign jurisdiction.” https://www.priv.gc.ca/en/privacy-topics/employers-and-employees/outsourcing/02_05_d_57_os_01/. ↩
-
Communications Security Establishment Canada, 2025-2026 annual report, June 2026: 1,772 supply-chain risk assessments conducted across government in fiscal 2025-26. https://www.canada.ca/en/communications-security/news/2026/06/communications-security-establishment-canada-releases-its-2025-2026-annual-report.html. ↩
-
OX Security, “easy-day-js supply chain attack hits Mastra AI in npm,” June 2026. On June 17, 2026, attackers swapped a legitimate dependency for an attacker-controlled package across roughly 141 packages in the Mastra ecosystem; package counts vary slightly by reporting vendor. https://www.ox.security/blog/easy-day-js-supply-chain-attack-hits-mastra-ai-in-npm/. ↩
-
UK National Cyber Security Centre, “Software supply chain attacks: check your dependencies,” updated July 2, 2026: “subsequent similar supply chain attacks have gone undetected for longer and spread more widely.” https://www.ncsc.gov.uk/blogs/software-supply-chain-attacks-check-your-dependencies. ↩
-
Council of the European Union, “SAFE: Council concludes agreement with Canada,” June 15, 2026, the final EU-side legal step admitting Canadian companies and Canadian-origin products to procurement under the Security Action for Europe instrument. Canada is the first non-European country to participate. https://www.consilium.europa.eu/en/press/press-releases/2026/06/15/safe-council-concludes-agreement-with-canada/. ↩