The 2026 Guide
Index

Dependencies and standards

Almost no service is built from scratch. It is assembled from parts: open-source libraries, third-party services, vendor products, and the formats and protocols that let those parts talk to each other. Dependencies and standards is about choosing and looking after those parts well. It pulls together four habits: build on open standards so the pieces can connect and be swapped; know everything the service depends on; vet a component before you adopt it; and keep what you depend on patched and watched.

What good looks like

  • The service is built on open standards, so it can connect to other systems and is not tied to one vendor.

  • A component or provider can be swapped without rebuilding the service, because the pieces are substitutable and there is an exit plan set before going to the cloud.

  • The team knows everything the service depends on, kept as a current inventory, a software bill of materials, the list of ingredients that make up the software.

  • New components and suppliers are vetted before they are adopted: is it still maintained, is it secure, is it well supported.

  • Dependencies are kept patched, and a known vulnerability is fixed promptly rather than left in place.

  • Contracts set minimum security requirements and require a supplier to report a security incident within a set time.

  • Open-source options are considered first, in line with the Government of Canada's open-first position.

The cost of skipping it

The parts a service is built from are also the ways it can go wrong. There are two risks.

  1. Lock-in.When a service is tied to one vendor's proprietary formats, that vendor controls the features, the fixes, and the price, and moving away later costs a great deal. Open standards keep the pieces substitutable, so a service can change one part without rebuilding the rest.
  2. The supply chain. A flaw or a tampering in a component you did not write becomes your problem. As the Canadian Centre for Cyber Security puts it, an organization is legally responsible for protecting its information even when using third-party services.

The Log4j flaw shows why this matters. When it appeared in a logging library used by millions of applications in 2021, the teams who came through it well were the ones who knew exactly where they used it and could patch fast. That is what knowing, vetting, and patching your dependencies buys you.

The Government of Canada's position is to use open source and open standards first, for exactly these reasons.

Whose job it is

Dependencies and standards is shared across the team, with each role holding a different part:

  • Developers and architects choose open standards, select and integrate the components, keep the inventory of what the service depends on, and apply patches.
  • Security specialists assess supply-chain risk, watch for new vulnerabilities, and judge whether a component is safe to rely on.
  • Procurement and contracting specialists write the minimum security requirements and notify-on-incident clauses into the contract.
  • The business owner of the application makes sure open options and the cost of lock-in are weighed, funds keeping dependencies current, and accepts that the service is responsible for its parts.

A closer look

Comparison

Two ways to handle dependencies

Pax

Meet Pax, a service manager. They treated the parts as something to look after:

  • built on open standards and kept an exit plan, so a vendor could be changed
  • kept a current inventory of every component and where it came from
  • vetted new components for being maintained and secure, patched promptly, and required suppliers to report incidents fast

The result: when the same flaw appeared, they knew within hours exactly where the library was used and patched it, and no vendor could hold the service hostage.

What Dependencies and standards looks like in each phase

Choosing and tending the parts is work across the whole life of a service.

The choices that matter most are made before the service is built. The team builds on open standards so the pieces stay substitutable, picks each dependency deliberately and starts the inventory, sets an exit strategy before committing to a cloud provider, and works with procurement to put security and notify-on-incident requirements in the contract. Designing to connect through open interfaces from the start is far easier than retrofitting it.

The official instruments behind dependencies and standards

Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.

  • Departmental architecture review board (DARB)Every servicesourceReview

    The department's own board, chaired by its chief information officer, that reviews a digital initiative's design against the government-wide architecture framework: look for something that already exists before buying or building, open standards, data, security and privacy.

    • AlphaSubmitSign or accept
    • GrowthKeep current
  • Government of Canada Enterprise Architecture Review Board (GC EARB)Only ifsourceReview

    The government-wide architecture board, co-chaired by the Chief Technology Officer of Canada and the Chief Technology Officer of Shared Services Canada, which reviews only the large or unusual initiatives.

    • AlphaCheckSubmit
  • Application Portfolio Management (APM)Every serviceRegister

    The register of the applications behind the services, rated for business value, technical condition, support cost and criticality, and sorted into tolerate, innovate, mitigate or eliminate. This is where criticality actually gets recorded, since the service inventory has no field for it.

    • StabilizationSubmit
    • MaturityKeep current
    • SunsetClose out
  • Application hosting decision, and the public cloud defaultEvery servicesourceReview

    The decision about where the service runs, made against a government-wide preference order rather than a local preference. Software as a service before platform before infrastructure; public cloud before hybrid before private before non-cloud. Departing from it needs a case, not a preference.

    • AlphaCheckSubmit
    • BetaSign or accept
    • MaturityKeep current
  • Cloud security profile, guardrails, and the cloud authorizationOnly ifAuthorization

    The extra security work a cloud-hosted service carries: a ready-made control profile to build against, a set of guardrails to be in place within the first days of a new cloud environment, and a security assessment that has to account for what the cloud provider does versus what the department does.

    • AlphaCheckGather
    • BetaFillSign or accept
    • GrowthKeep current
    • MaturityKeep current
  • Government of Canada credential and sign-in servicesOnly ifStanding duty

    The shared sign-in services a department uses instead of building its own: the government-branded credential service, the commercial bank-based option, and the newer federated sign-in platform. Using them is the default rather than a choice, and building a bespoke sign-in is the thing that needs justifying.

    • AlphaCheck
    • BetaFillSubmit
    • MaturityKeep current

Further reading

Beyond the sources already linked above, the Government of Canada's Open Resource Exchange lets you browse the open standards and open-source software other Canadian public administrations already use, so you can reuse a vetted solution rather than start from nothing. For the supply-chain side, NIST's cybersecurity supply chain risk management practices set out how a large organization identifies, assesses, and manages the risk in the products and services it buys, and the Secure Software Development Framework gives you a shared checklist of secure-build practices to ask a supplier about during procurement.

See also

Assumptions this page makes

You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.