Supply chain security.
A CISO's perspective.

01 / MY STARTING POINT

I cannot outsource the consequences

A supplier can provide software, operate a platform and sign a contract. It cannot make the consequences of my organisation's dependence disappear. If an update compromises a critical service, customers will not experience a neat separation between my company and its technology providers. They will experience the interruption, the loss of confidence or the exposure of their information. That is where I start as a CISO. As a cybersecurity architect, I then ask a more uncomfortable question: which technical decisions would allow that supplier's mistake, compromise or disappearance to become my emergency?

The Centre for Cybersecurity Belgium's publication on supply chain cybersecurity risks is a useful reason to have this discussion. Its scope includes software, services and hardware, with particular attention to the people and connections that carry privileged access across organisational boundaries. The accompanying announcement highlights developers, administrators, cloud services and managed service providers. I read that as an invitation to examine the authority I delegate, as well as the products I buy. CCB publication and announcement.

My position is straightforward. I want useful suppliers, productive developers and systems that can evolve. I also want an organisation that can answer four questions without assembling a crisis meeting: what entered the environment, who authorised it, what it could reach, and how that authority can be withdrawn. Those answers should remain available when the usual supplier contact, identity provider or build platform is unavailable. A diagram that only works on a normal Tuesday is an incomplete security architecture.

This is my reading of the report and my proposed operating model, written from the combined perspective of a CISO and a cybersecurity architect. It is not a CCB endorsement of SysWarden, a reproduction of the report or a claim that one tool solves supply chain risk. I separate sourced incident facts from my own recommendations. The examples of organisational decisions below are illustrative.

I will move from intelligence to governance, then into the actual paths through which dependencies enter systems: npm, APT, Go, build workflows, service integrations and operational updates. I will also discuss recovery, procurement, funding and residual risk. These subjects belong together. A package policy that ignores the business deadline will be bypassed. A board decision that ignores the privileges of a package installation script is equally detached from reality.

The standard I set for SysWarden must be the same standard I set for another security product. Useful protection does not create an exemption from scrutiny. A security tool may hold exactly the privileges that make a compromised dependency valuable to an attacker. I therefore judge the quality of a solution partly by how clearly it exposes its limits, supports verification and allows an administrator to remain in control.

02 / BUILD ON THE CCB'S WORK

The CCB gives me a foundation for action

I welcome the CCB's work because it connects a complex threat landscape to decisions organisations can make. Its contribution is particularly valuable when intelligence, governance and technical operations are too often discussed separately. The CCB developed CyberFundamentals, which provides a shared framework for organising that work. CyberFundamentals: origin and purpose. My purpose here is to build on this contribution from my perspective as a CISO and cybersecurity architect, and to show how I would translate it into operational choices.

The report is dated 29 September 2026 and states an intelligence cutoff of 14 July 2026. The web page was published on 30 September and updated on 7 October. Its trend chart concerns public reporting of supply chain techniques. I retain that context when using the report, so that my own conclusions remain aligned with what the source actually presents. CCB threat report, cover and executive summary.

The value for me is the connection between upstream compromise and downstream consequences. It gives a management team a shared starting point for discussing dependencies that may otherwise remain invisible. From there, my job is to identify the corresponding relationships in the organisation: the supplier able to alter a critical service, the build identity able to publish an update, or the integration able to read sensitive information.

I do not need to convert intelligence into an exact probability before acting on an unnecessary privilege. The report helps orient attention; architecture turns that attention into boundaries. I can ask whether a publishing credential belongs in a test job, whether a connector needs tenant-wide access, or whether a recovery path depends on the same authority as production. Each answer produces a decision that the organisation can implement and verify.

I also preserve the scope and confidence of the incident sources I use. That is a responsibility I take as the author of this article. The recommendations below are my interpretation for an operating environment, not additional findings attributed to the CCB. Keeping that distinction clear allows me to discuss tradeoffs constructively while respecting the intelligence work on which the discussion is based.

This is the continuity I want between national guidance and day-to-day practice. The CCB raises awareness and provides a structured foundation. I connect that foundation to accountable owners, enforceable permissions and evidence of recovery. The aim is to make the guidance useful in the meeting where a supplier is selected, in the workflow where a release is approved and in the incident where access must be withdrawn.

03 / MAP DELEGATED AUTHORITY

I map authority, not just suppliers

A traditional supplier inventory starts with companies and contracts. I still need it, but it leaves out many of the relationships that actually determine security. A small library may influence an Internet-facing application without a procurement record. A cloud connector may read sensitive records without installing software on any server. A contractor's support account may be more powerful than the entire application it exists to maintain. My architecture must represent these relationships explicitly.

I use three connected views. The first shows business services and the consequences of their loss. The second shows the software, platforms, identities and operational providers on which those services depend. The third shows authority: who can change code, publish an artifact, issue a credential, alter policy, read data or restore a system. The third view is often where the discussion becomes useful. It exposes connections that a component inventory alone cannot explain.

For each relationship, I ask what is transferred. Is it executable code, configuration, telemetry, administrator access, a trust anchor or a business decision? I then ask how the transfer is authorised and how that authorisation ends. A software update and a remote support session are different mechanisms, but both can carry authority into production. Treating one as a procurement problem and the other as an IT convenience hides their common risk.

I also look for concentration. Five applications may appear to use five different vendors while relying on the same identity provider, release platform or managed administrator. Redundant servers do not create independent recovery if the same compromised account can alter all of them. I want to see which boundaries remain effective when a shared control plane becomes hostile. Geographic distribution alone does not answer that question.

My inventory does not need to become an encyclopaedia before it becomes useful. I would begin with the dependencies able to change privileged production behaviour or access high-impact information. For each, I would record an accountable owner, the accepted scope of authority, a verification route and a withdrawal procedure. An incomplete but actively maintained map of critical authority is more useful than a comprehensive spreadsheet that nobody uses during change approval.

The map should influence design. If a monitoring provider only needs to receive events, I should be able to explain why it also has a remote execution channel. If a build job only needs to read a private module, I should challenge a credential that can publish every package. These are architectural questions with budget and usability consequences. They are also the places where a CISO can turn a broad threat warning into a bounded improvement.

04 / CONNECT RISK TO ARCHITECTURE

My two roles need the same evidence

As a CISO, I need to explain the exposure, identify the decision maker and make the tradeoff explicit. As an architect, I need to show where the decision is enforced and how failure is detected. I do not want two separate stories: an elegant risk register for governance and a collection of undocumented exceptions for operations. The same risk statement should be traceable into the permissions, deployment gates and recovery tests that are supposed to reduce it.

NIST's supply chain risk management guidance places these concerns within organisational risk management, across different levels of responsibility. I use that as a useful framing reference, not as a claim that completing a checklist will make a supplier safe. The practical interpretation in the rest of this article is mine. NIST SP 800-161 Rev. 1, Update 1.

A risk statement should name an outcome. For example: a compromised update to a privileged infrastructure agent could interrupt a critical service and damage its recovery capability. That is more useful than writing "supplier risk: high". It identifies the change path, the privilege and the consequence. It also suggests the evidence I need: admission checks, restricted deployment scope, independent recovery access and a test of what survives removal or rollback.

I would assign a business owner for accepting the remaining exposure, a technical owner for the controls and an operational owner for keeping them effective. One person may hold more than one role in a small organisation. The responsibilities still need to be distinguishable. The person who can explain a cryptographic signature is not automatically authorised to accept several days of business interruption. The person who owns the service cannot approve a technical exception without understanding its effect.

Every significant exception needs a reason, a scope, a compensating measure and a review condition. I prefer a concrete trigger to a vague promise to revisit it later: a supplier changing its release infrastructure, an integration requesting a new scope, a maintainer transfer or the next contract renewal. Calendar expiry is useful, but a material change should force review even when the paperwork has not expired.

This also makes cost visible. If I require a dedicated release environment, independent review and restore exercises, I must account for the people and infrastructure needed to operate them. An unfunded control is often an invitation to pretend. I would rather present an honest, prioritised plan with an explicit residual risk than an impressive policy that quietly depends on exhausted staff doing unpaid work.

05 / WHAT INCIDENTS ACTUALLY TEACH

I extract mechanisms from incidents, not slogans

The XZ maintainer's account makes an important distinction: the malicious release tarballs and the Git repository were not equivalent. The triggering build machinery was present in the affected release archives, while the repository contained other relevant material. A review of one distribution channel therefore could not be treated as proof about every delivered artifact. XZ Utils maintainer's account of the 2024 backdoor.

The lesson I take is to connect the object I review to the object I install. An organisation may perform excellent source review and then deploy an archive produced through a different process. It may approve a commit and subsequently rebuild with changed dependencies. Neither situation is resolved by pointing to the original review. I want the release record to identify the actual bytes, the process that produced them and the evidence used to admit them. If an unexplained difference appears, the investigation belongs before broad deployment.

In March 2026, Aqua's Trivy advisory described malicious releases and compromised action references. The maintainer's subsequent incident report also discussed credential revocation and changes to release infrastructure. These are primary accounts of a security tool becoming part of a supply chain incident, rather than evidence that security tooling should be abandoned. Trivy advisory; maintainer's final incident report.

I draw a different conclusion from the one a product brochure might suggest. A scanner is executable software. It should receive only the credentials and network access required for its task. If I place a scanner beside every production secret, I have increased the consequence of its compromise. Running more scanners in that same privileged context does not necessarily create independent protection. I need to examine how tools are admitted, isolated and updated, including tools purchased specifically to improve security.

CERT-EU assessed with high confidence that a compromised Trivy download provided initial access in the European Commission cloud incident it reported in April 2026. Its account describes stolen credentials and subsequent data theft. It also states that it had no indication of lateral movement and observed no website interruption or tampering. I preserve those boundaries instead of expanding a serious incident into an unsupported claim of total infrastructure compromise. CERT-EU incident account.

The architectural question I take from that account is how a tool's execution context relates to the credentials available to it. I would investigate whether build, scan and publication identities are separated; whether a credential can create another credential; and whether monitoring notices that transition. The important boundary may be an identity permission rather than a network segment. A network diagram that omits credential issuance can miss the route that matters most.

Salesforce's notice about the Salesloft Drift incident distinguished compromised application credentials from a vulnerability in the core Salesforce platform. That is a useful example of why the word "supplier" needs precision: a connected service can provide a path to data without compromising the underlying platform itself. Salesforce security notice.

For my own architecture, I would therefore test connector permissions and revocation independently of platform patching. A fully patched application can still expose data through an overprivileged integration. I also ask whether the team investigating a suspicious integration can identify every tenant, scope and service account involved. The incident changes what I would verify. It does not justify claiming that every integration or every instance of the platform is compromised.

06 / PEOPLE AND PRIVILEGED ACCESS

Developers and administrators need a safer working environment

The CCB report discusses social engineering, vulnerabilities and compromised credentials, and profiles actors including Lazarus, Handala, TeamPCP, ShinyHunters and Everest. It links these threats to privileged development and administration contexts. I treat those profiles as intelligence context, not as a substitute for assessing the routes available in my own organisation. CCB report, threat actors and attack patterns.

I do not respond by telling developers to be more careful and considering the work done. A person handling repositories, support requests, release automation and production incidents is exposed to several competing sources of urgency. My architecture should make a deceptive request less powerful. Reading an issue, opening a contribution or testing a proposed fix should not automatically expose the credentials used to publish a release.

I distinguish the environment used to inspect untrusted work from the environment authorised to distribute trusted output. That can mean separate identities, short-lived workspaces and a promotion step with narrowly defined inputs. The point is not to make every engineer operate an elaborate ceremony for a small change. It is to prevent an ordinary review activity from silently inheriting the authority of the release process.

Administrative access deserves the same treatment. A support session should have a defined purpose and duration, with an accountable sponsor and an observable record. I challenge shared accounts that prevent attribution, standing privileges that outlive the contract and remote access paths that nobody includes in the recovery plan. Emergency access needs to remain possible, but its existence should be deliberate and its use visible.

Maintainer succession is another control point. If a project changes hands, I would examine how publication rights, signing identities and communication channels change together. A long history of a package name does not automatically establish continuity of control. I do not demand personal information from a volunteer to compensate for my own lack of technical boundaries. I would decide what evidence and restrictions are appropriate to the authority I intend to grant the software.

Training helps when it is connected to these controls. I want a developer to know where to report an unusual request and to be able to stop a release without being treated as the cause of the delay. I want administrators to recognise a new permission request and have an alternative to approving it under pressure. Security culture becomes tangible when the safer choice is supported by tools, time and management, rather than rewarded only in a presentation.

07 / ADMIT DEPENDENCIES DELIBERATELY

A dependency request is a small architecture decision

I do not consider every new library a procurement event, but I do consider it a change to the system's dependency graph. Before adding one, I want the team to be able to describe the function it supplies and the authority it will receive. A parser used on hostile input, a build plugin with filesystem access and a formatting helper are not equivalent decisions. The same package may also have a different risk profile in a disposable developer environment and in a privileged production process.

My first question is whether the dependency is needed. Reimplementing complex cryptography to reduce a package count would be a terrible interpretation of minimalism. Adding an entire framework for a trivial formatting operation may be a different matter. I prefer a short explanation of the tradeoff over a numerical target. The objective is a dependency set the team can understand and maintain, not a leaderboard for the fewest imports.

I would review direct and transitive changes together. A minor update to one direct package can bring a materially different collection of code into the build. The approval record should make the actual change visible: new packages, removed packages, source locations, permissions used during installation and significant changes to the build process. An automated change proposal is useful precisely because it can assemble this evidence consistently. It should not approve its own conclusion.

I separate vulnerability review from malicious behaviour review. A component with no known advisory may still be inappropriate, abandoned or intentionally harmful. Conversely, a component listed in an advisory may not expose the affected function in a particular product. I want the team to investigate context without using context as an excuse to ignore findings. The result should identify what was assessed, what remains uncertain and what would trigger a different decision.

For higher-impact dependencies, I would inspect the release process and maintenance arrangements as well as the code interface. Who can publish? Is the distributed archive traceable to a source revision? Can I obtain the exact previous version? Is there a usable vulnerability reporting channel? What happens if the maintainer stops? These questions should influence the scale of deployment and the investment in alternatives. They do not require pretending that a small open-source project has the resources of a multinational vendor.

I would keep the record proportionate. A low-impact library may need a brief automated report and an ordinary code review. A component that controls authentication or runs as root may need an explicit architectural decision and a recovery exercise. The rule should be understandable enough that teams can apply it without waiting for a weekly security committee. When the rule produces unreasonable friction, I want to improve the rule before shadow processes become the normal way of working.

08 / NPM: INSTALLATION IS EXECUTION

For npm, I treat installation as part of the trust boundary

The npm documentation describes npm ci as a clean installation using an existing lockfile, failing when the lock and package manifest disagree and leaving those manifests unchanged. Its --ignore-scripts option suppresses package lifecycle scripts, but an explicitly requested command such as npm test still runs the requested script. These are useful mechanics, not a verdict on whether a dependency is trustworthy. npm ci documentation.

My policy would distinguish acquiring dependencies from allowing their code to execute. For a suitable project, an initial installation with lifecycle scripts disabled can reduce the immediate execution surface during inspection. It is not a universal build recipe: some projects need native compilation or generated assets. I would document the scripts actually required and the environment in which they are permitted to run. I do not present one command as a safe way to execute arbitrary packages.

The environment is decisive. I avoid handing a dependency installation job the token used to publish the resulting package. I also examine what it can read from the workspace, the runner's home directory, mounted sockets and network services. A read-only source token may be necessary for a private dependency, but that does not justify broad write access. The build should receive the smallest useful set of capabilities for the shortest useful period.

A lockfile is valuable because it makes selection explicit and reviewable. My review still needs to examine what changed inside it. A large lockfile diff should not become a reason to click approve without context. I would expect the tooling to identify new publishers or package names, unexpected source changes and a sharp expansion in the dependency tree. Those signals prompt investigation; none is, by itself, proof of compromise.

For publishing, npm's trusted publisher mechanism ties short-lived authentication to an authorised CI workflow. Its documentation also explains that traditional token-based publishing is a separate access path that can remain enabled. I would review both paths rather than assuming that adding OIDC removes every older credential. npm trusted publishing.

My architectural interpretation is that OIDC changes where I need to defend authority. The workflow, repository settings, environment approvals and identities allowed to change them become central. A compromised authorised workflow can still perform an authorised-looking publication. I would therefore examine who can alter publication configuration, which event starts it and which source revision it consumes. Short credential lifetime is useful; it does not replace control over the decision that requests the credential.

I also plan for withdrawal. If a package release becomes suspect, the team should know which applications consumed it and which credentials were available during installation or testing. Replacing a dependency may repair the next build while leaving stolen credentials usable. I avoid claiming recovery until those separate questions have been assessed. The package inventory and the identity inventory need to meet at the build record.

09 / APT: REPOSITORY TRUST AND ROOT

For APT, I examine the trust I add to the operating system

Debian's apt-secure documentation describes a chain from signed repository metadata to package checksums. It distinguishes that archive authentication from checking an individual package signature and from deciding whether package contents are safe. It also documents scoping repository keys with Signed-By. A correctly authenticated repository can still distribute harmful content if the authority controlling it is compromised. Debian 13 apt-secure manual.

Adding a third-party repository is therefore a trust decision, even when the installation instructions fit on two lines. I would record why the repository is needed, which packages it should supply and who owns its continued use. I would scope its signing key to the intended source, review package selection policy separately and monitor changes to both. Key scoping does not, by itself, constrain every package a repository could offer. The trust anchor and the candidate selection rules solve different problems.

I would resist the familiar troubleshooting shortcut of disabling authentication because a repository update failed. A failure can be caused by an expired key, a clock problem, an incomplete mirror or a legitimate rotation, but it can also be a warning worth preserving. The recovery procedure should identify the cause and establish the replacement authority through an approved channel. It should not teach operators that security checks are optional whenever they obstruct installation.

Debian policy describes maintainer scripts that participate in installation, upgrade and removal, including preinst, postinst, prerm and postrm. Their behaviour matters during failures and retries as well as normal operation. Package management is therefore more than copying a binary to a directory. Debian Policy, package maintainer scripts.

For a privileged product, I would include those scripts in the review scope. I want to know whether they download additional material, change service definitions, alter shared firewall state, adjust permissions or make assumptions about the administrator's configuration. I would test what happens when a dependency is unavailable halfway through installation. A signed package can faithfully execute an unsafe installation procedure; the signature cannot repair the procedure's design.

Standalone package files need a clear admission route too. A file fetched from a release page is not automatically covered by the same repository metadata chain as a package selected from a configured archive. I would follow the project's documented verification procedure and bind the result to the exact local file subsequently installed. The expected digest or signature identity must come from a trust decision, not merely from another unauthenticated file sitting next to the download.

I also include removal in supplier acceptance. On a representative test system, installation should be followed by upgrade, interrupted-operation recovery and the native removal paths the organisation intends to support. I would inspect shared resources after the operation and after a reboot. A successful package-manager exit is useful evidence, but it does not tell me whether an unrelated service still behaves correctly or whether a persistent rule will recreate product state later.

This is an exit requirement, not an argument for deleting aggressively. A product should remove the resources it can demonstrate it owns and preserve administrator customisation. If ownership is ambiguous, the operator needs a precise explanation and a bounded recovery procedure. Silently deleting a shared configuration file may make a cleanup report look tidy while damaging the host. My preference is verified ownership, explicit exceptions and a recovery path that respects the rest of the system.

10 / GO: RESOLUTION AND VERIFICATION

For Go, I keep integrity, selection and safety separate

Go's module reference explains how downloaded module content is checked against go.sum and, where applicable, the checksum database. It also describes the effect of private-module patterns and disabling the database. Version selection, replacement directives and workspace configuration influence what is built; go.sum is not simply an npm-style lockfile. These mechanisms provide useful integrity and selection properties, not an assessment of the intent of a module's code. Go Modules Reference.

I would review a Go dependency change as a change to the effective build graph. Looking only at an import statement is insufficient. The review should include the module manifests, relevant workspace settings, replacements, toolchain selection and any vendored content used by the build. I want a reviewer to be able to explain why the resulting dependency set is expected. An apparently familiar module path should not hide a replacement with different local content.

For private modules, I would define narrowly scoped patterns and a documented acquisition path. Privacy is a valid reason to avoid sending internal module names to a public service. It is not a reason to disable integrity checks indiscriminately for every dependency. Where public verification does not apply, I would establish an internal source of authority and preserve the evidence used to admit a version. The exception should be intentional, limited and visible in the release record.

I distinguish a repeatable download from a trustworthy dependency. If malicious content was accepted as the expected content, a successful checksum comparison can reproduce the problem perfectly. That does not make checksums pointless. It tells me why acquisition integrity and code assessment belong to different controls. The same principle applies to local caches: preserving the bytes I previously used is useful, but it is not a fresh judgement about whether I should continue using them.

The Go security tooling describes govulncheck as a way to identify known vulnerabilities affecting a project, with analysis intended to reduce irrelevant findings. I would use that evidence when assessing exposure, while keeping its scope distinct from malicious dependency detection and architectural review. Go vulnerability management.

My build review would also include tools invoked around the compiler. Code generation, packaging helpers, shell scripts and optional native compilation can introduce capabilities outside a simple list of Go imports. A release may depend on a container image or a system compiler that the application module inventory does not describe. I would make those inputs explicit because the final executable is the result of the whole process, not just the language's dependency resolver.

For an operational product, I would retain enough release evidence to answer a later question without rebuilding history from memory: which source revision, dependency selections, toolchain and packaging inputs produced this file? I would then verify that the distributed file matches the admitted artifact. This is particularly important when a project produces several architectures or package formats. Evidence for one variant should not silently stand in for another.

11 / PROTECT THE RELEASE PATH

The build pipeline is a production system

I consider a release pipeline part of the production security boundary even when it runs outside the production network. It can create the software that production will trust. If it can publish an update accepted by hundreds of systems, its effective reach may exceed that of an individual administrator. Treating it as temporary developer infrastructure understates its importance.

GitHub's guidance warns about executing untrusted contributions in privileged workflow contexts, including unsafe uses of pull_request_target. Its broader security guidance recommends pinning third-party actions to a full commit SHA. These controls address distinct routes by which workflow behaviour can change. GitHub guidance on privileged pull request workflows; GitHub Actions security guidance.

I would draw the path from an external contribution to a published artifact and mark every increase in trust. Who can supply the source? Which workflow definition is used? Which job obtains credentials? Who can approve the protected operation? What evidence is consumed at that point? I want each transition to be deliberate. A file produced by an untrusted job should not become trusted merely because a later job downloads it with a familiar filename.

A pinned action is one input, not necessarily the end of the dependency graph. I would inspect whether it downloads another executable, resolves a moving branch or invokes an external service whose result becomes part of the release. The useful question is which mutable decisions remain after the visible pin. I would record and constrain those decisions according to their impact, instead of assuming that one immutable reference freezes the entire build environment.

I would separate ordinary checks from protected signing and publication. Tests should not need production deployment credentials. A signing job should receive the exact reviewed artifact and the minimum metadata necessary to verify its identity. If the pipeline rebuilds after approval, that new build needs an explicit relationship to the approved inputs and outputs. Otherwise the approval can refer to one object while the signature authenticates another.

Caches need the same trust analysis. They improve performance and reduce cost, but I ask who can write them and which later jobs consume them. A cache shared across incompatible trust contexts can become a route around the source review. I would use separate namespaces or avoid reuse where the security cost exceeds the performance benefit. A cache policy should state its assumptions rather than relying on the word "cache" to imply harmlessness.

I would keep the release runner's role narrow and its lifetime appropriate to the platform. An ephemeral runner can reduce persistence, but it does not prevent data theft during a compromised job. Isolation, credential scope, egress policy and controlled inputs remain relevant during those few minutes. Conversely, a long-lived runner requires a credible maintenance and recovery story. I care about the demonstrated boundary, not whether the infrastructure description contains a fashionable adjective.

Finally, I want failure to preserve useful evidence. A release should not become a detective story because a job timed out and discarded its inputs. The organisation needs enough retained information to distinguish a product defect, a test infrastructure failure and an admission failure. That evidence must be protected against exposing secrets or private operational data. Auditability and confidentiality should be designed together.

12 / WHAT EACH PROOF CAN ESTABLISH

I refuse to turn evidence into a security talisman

Checksums, signatures, provenance, inventories and vulnerability reports are valuable. The problem begins when several useful but limited statements are combined into an unlimited conclusion. I want the release decision to state what each item establishes and what remains outside its scope. A green verification result is meaningful only when I understand the property that was verified.

SLSA's verification guidance describes checking provenance against expectations about the artifact, builder and build parameters. I take the important operational point to be the existence of an explicit acceptance policy. Obtaining an attestation and evaluating it are separate steps. SLSA v1.2 artifact verification.

In my architecture, the expected identity would be configured through an approved process. I do not accept whichever identity happens to appear in the bundle accompanying an artifact. Otherwise an attacker can supply a perfectly valid statement made by an irrelevant authority. The verifier should reject the wrong repository, workflow or other required identity attributes, as applicable to the signing system, even when the underlying cryptographic operation succeeds.

Sigstore's Cosign documentation includes identity-based verification using the expected certificate identity and OIDC issuer, and verification of a file with its bundle. That provides a concrete way to express part of such a policy. I avoid permissive identity patterns that accidentally admit unrelated publishers. Sigstore verification documentation.

Reproducibility answers another question. If I build the same inputs twice on the same compromised machine, matching outputs do not establish an independent second opinion. I would state the scope of the reproduction honestly: same environment, separate environment or independently controlled builder. I also remember that reproducibly building malicious source still produces malicious software. The evidence can reveal unexplained build differences without deciding whether the source should have been accepted.

For a software bill of materials, I ask how it was generated, what it covers and whether it corresponds to the artifact actually deployed. A source-level list may miss packaging inputs or generated components. A runtime inventory may not explain the tools that shaped a binary. I would use the inventory to support concrete questions, such as locating affected products after an advisory, rather than treating possession of an SBOM file as the end of supplier assessment.

My acceptance record would combine these inputs with the relevant tests and unresolved issues. It would identify who made the decision and why. This is the point where governance becomes practical: the record explains both the evidence and its limits. If a future incident exposes an assumption that was wrong, the organisation can improve the process instead of discovering that nobody knew what the original green badge meant.

13 / SAAS, MSPS AND CONNECTORS

Service integrations deserve the same scrutiny as packages

A supply chain programme focused only on software files will miss a large part of the exposure I care about. A connected service can read, alter or export information through an authorised API. A managed provider can change infrastructure through an administration console. No suspicious executable has to arrive on a local server for either relationship to become dangerous. My review therefore follows authority across service boundaries as carefully as it follows code into a build.

For each important integration, I would record the business purpose, the identity it uses, the permissions granted, the information it can access and the owner who can disable it. I would separate tenant-wide permissions from permissions limited to a project or dataset. I also examine whether the integration can invite another identity, create a credential or change its own access. A permission that can manufacture more authority deserves particular attention.

I would test revocation in a controlled environment. Does disabling the application stop new access? Are there additional sessions, refresh mechanisms, copied credentials or downstream accounts to remove? What information has already been exported? The exact answers depend on the service, but the questions should exist before an incident. Revoking access cannot bring back data already copied, so I also need limits on what the integration can collect in the first place.

A managed service contract should make operational boundaries intelligible. I want to know which actions are routine, which require customer approval and which can be taken during an emergency. I challenge a model where every technician has permanent unrestricted access to every customer. I also challenge a customer process that demands rapid emergency response while making approved access impossible. Good design supports legitimate work without making broad standing authority the default.

Evidence should be accessible outside the provider's own administration path. If the provider is the subject of the investigation, I do not want its compromised console to be the only source of logs or the only route to revoke access. I would define retention, export and customer access requirements according to the service's importance. Independence here can be modest and practical: a protected audit stream, a separate emergency identity and a tested way to contact an accountable responder.

Hardware relationships belong in this map too. I would examine firmware update authority, management interfaces, support access and lifecycle commitments according to the system's role. I need to know what I can verify about the equipment I operate and what remains dependent on the manufacturer's assurances. Where that assurance is weak, I would consider isolation, replacement options and the consequences of a failure.

14 / MAKE UPDATE POLICY DEFENSIBLE

I reject both automatic trust and permanent freezing

Supply chain incidents create an understandable temptation to stop updating. That response exchanges one exposure for another. Delaying a malicious update can protect a system; delaying an urgent fix can leave an exploitable weakness in place. My role is to define a decision process that can distinguish those situations well enough to act, rather than pretending that a single delay interval is always the safest answer.

I would classify updates by consequence and urgency. An ordinary dependency refresh, a change to a privileged service and a response to confirmed exploitation should not use an identical path. Each path needs an owner, required evidence, a deployment scope and a stop condition. The emergency path can be faster while still preserving artifact identity, approval and a recovery plan. "Emergency" should describe a controlled exception, not the disappearance of all controls.

A short observation period can be useful for some routine changes, but elapsed time is not proof of safety. A targeted payload may remain quiet, and a campaign may affect only a particular platform or environment. I would combine observation with review and bounded rollout. The decision should explain what I expect the observation period to reveal and what evidence would cause me to shorten or extend it.

For a fleet, I would design deployment groups around meaningful failure domains. A canary that does not resemble production tells me little about production behaviour. Equally, putting every critical role in the first group defeats the purpose of limiting exposure. I would select representative systems, verify business behaviour and management access, then expand only when the evidence supports it. Wave size and timing are design choices for the organisation, not universal numbers to copy from a blog.

I would freeze the admitted artifact identity for each rollout. If the upstream project replaces a file or changes a moving reference, I want the deployment process to notice and stop rather than silently consume the new object. The same principle applies to rollback. The organisation should preserve known recovery inputs and verify their suitability, while remembering that an older version can have known vulnerabilities or be part of the incident itself.

My stop conditions would include unexplained signature or identity changes, unexpected privileged operations, loss of management access and evidence that the update affects unrelated services. I would name who can pause the rollout and who can authorise resumption. This is one of the simplest ways to make risk management operational: give a real person the authority to act on a defined signal before a small problem becomes a fleet-wide event.

15 / CONTAIN THE CONSEQUENCES

Admission is necessary; runtime boundaries still matter

I assume that admission controls can miss something. This is not pessimism for its own sake. It is the reason to limit what an admitted component can do. A dependency that escapes review should still encounter constraints on credentials, filesystem access, service identity and network reach. The architecture should not require every upstream publisher to remain perfect for the business to remain recoverable.

I would start with the privileges that produce the largest consequences. Can the service modify its own executable or security policy? Can it read credentials belonging to unrelated applications? Can it reach a backup administration interface? Can it alter the logs used to investigate it? These questions often identify more valuable work than adding another product to an already crowded stack. The answer may be a permissions change, a separate identity or a redesigned management path.

Network filtering has a useful role, including on the host, but I would be precise about its limits. A permitted HTTPS connection can carry a malicious update or an unauthorised data transfer. An IP blocklist cannot determine whether an authenticated package publisher has been compromised. A service may also misuse a legitimate API without contacting an address already known to be hostile. I want network controls to contribute to the boundary, with application and identity controls covering what the network cannot establish.

Threat intelligence data is itself an input that deserves an admission policy. I would consider origin, integrity, freshness, format and operational impact before allowing a feed to change enforcement. An empty, malformed or unexpectedly broad dataset should not silently produce a destructive configuration. Where multiple distribution routes exist, I distinguish transport availability from independent authority. Two mirrors can carry the same compromised upstream content.

For monitoring, I would prioritise changes to authority as well as suspicious traffic. A newly issued deployment credential, a modified workflow permission, an unexpected connector scope or a changed trust key can be an early signal. The organisation needs enough context to decide whether the change was expected. Otherwise it will receive another stream of alerts that cannot be linked to an owner or a change record.

I also protect recovery from the same identity that operates the workload. If one compromised administrator can modify production, erase its backups and suppress its logs, the apparent separation between those systems may offer little practical resilience. I would test the boundaries by asking what remains available after that identity is considered hostile. The answer should include a route for restoring control, not merely a diagram showing different subnets.

16 / RESPOND AND REGAIN CONTROL

My incident plan separates containment from recovery

When a dependency becomes suspect, the first task is to establish scope without spreading the uncertainty. I would identify the affected artifact or service, stop further promotion through the relevant path and preserve the evidence needed to investigate. This is a targeted interruption of a trust relationship. It should not automatically become a shutdown of every system that shares a vendor name.

The build and deployment records should help answer who consumed the suspect object, when it executed and what authority was available at that time. Those questions are more useful than asking only whether the latest scanner reports the package. A dependency may have executed during a build and no longer exist on the production host. A service credential may have been exposed without any package being installed. I need to reconstruct the relevant execution and access contexts.

I would contain the affected trust path before issuing replacement credentials into it. Otherwise a hostile workflow or integration may simply collect the new credentials. The order needs to be designed for the specific platform and incident, with evidence preserved and legitimate emergency access maintained. Credential rotation is an action inside a recovery process, not proof that recovery is complete.

Rebuilding a system can remove persistence on that system, but it does not automatically undo actions performed through stolen authority. I would investigate newly created accounts, changed access policies, altered release configuration and downstream publications where relevant. I also distinguish confidentiality loss from availability recovery. Restoring a service does not reverse the disclosure of information, and the business response must reflect that difference.

A recovery exercise should include the unpleasant dependencies. Can the team obtain trusted installation material if the normal registry is unavailable? Can it access the management plane without the usual identity provider? Can it read the restore procedure without the collaboration platform that is currently isolated? These are practical tests of independence. I would perform them in a safe environment and record the gaps while there is time to fix them.

Removal and revocation are part of this work. If the organisation decides to retire a product, I want its active services, scheduled actions, credentials and persistent enforcement state accounted for. I also want unrelated administrator settings preserved. I would require separate evidence for the paths actually used by operators, including package-manager removal where applicable. A supplier exit should leave the organisation with a comprehensible system, not a collection of unexplained leftovers or broken protections.

Before resuming distribution, I would identify what changed in the trust model and why the new path is acceptable. Simply waiting for the supplier to publish another version is not enough if the compromised publication authority remains in place. The recovery decision needs a named owner, supporting evidence and conditions for continued monitoring. I would document uncertainty honestly rather than using a successful restart as a substitute for an investigation.

17 / BUY EVIDENCE AND EXIT OPTIONS

Procurement should buy an operating relationship

A supplier questionnaire can start a conversation. I do not want it to become a substitute for one. A positive answer about secure development is less useful than evidence relevant to the service I intend to buy. I ask the supplier to walk through how a release reaches a customer, how a security incident is handled and how customer access can be withdrawn. The level of detail should follow the consequence of the relationship.

For a high-impact service, I would want clarity on the scope of assurance reports, the systems they cover and the period they describe. A certificate can be useful evidence about an assessed management system. It does not establish that every component, integration or release is free from defects. I avoid treating the logo on a slide as an answer to a question about a particular privileged connector.

I also ask what happens when the supplier's own dependencies fail. Can it communicate through an alternative channel? Can it suspend an affected integration without taking the whole service offline? Does it know which customers received a suspect update? Can it provide useful technical information without exposing other customers? These questions assess whether the supplier can cooperate during a difficult event, not whether it can promise that no event will occur.

Commercial commitments should support the recovery model. I would seek appropriate arrangements for incident notification, evidence availability, access revocation, data return and orderly termination, with legal and procurement colleagues translating the operational needs into the contract. I do not copy a universal clause from a technical article and assume it creates a suitable legal obligation. The terms need to match the service, jurisdiction and actual ability of both parties to deliver.

Exit deserves a funded plan. If changing providers would require rebuilding years of undocumented integrations, the organisation has accepted a concentration risk whether or not the risk register says so. I would identify export formats, replacement paths, licence dependencies and the time required to withdraw privileged access. A realistic exit option can improve both resilience and the quality of the supplier relationship. It gives both parties a clearer understanding of the boundary.

For smaller suppliers, proportionality matters. I do not demand a costly assurance programme when a narrow technical integration and a modest amount of evidence provide the protection I need. I also do not excuse unlimited access because the supplier is small or familiar. The right response may be to reduce the authority granted, support a practical improvement or choose a different integration. Procurement should help make those choices visible.

18 / THE DEBATE I WANT TO HAVE

Open source, sovereignty and AI deserve a less superficial debate

I do not divide the world into trustworthy open source and dangerous proprietary software, or the reverse. Source availability can improve inspectability and the possibility of independent maintenance. It does not guarantee that someone has reviewed the code that matters, that the release corresponds to it or that maintainers have sustainable resources. A proprietary supplier may provide strong operational evidence or very little. I would evaluate the relationship and its controls rather than using the licence as a security verdict.

Digital sovereignty matters to me when it creates practical choices: the ability to inspect, operate, maintain, migrate and recover without being trapped by a single authority. Hosting everything locally does not automatically create those choices. A locally operated system can still depend on external identity, package distribution or a lone administrator. Conversely, using an external service does not make careful control impossible. I would describe the dependencies honestly and decide which ones are acceptable.

Independence has a cost. Maintaining release infrastructure, reviewing dependencies, testing recovery and commissioning external assessment consume time and money. If organisations depend on a small project, I consider supporting that maintenance part of a credible risk treatment. Funding does not purchase a guarantee of safety, and a donation should not be presented as a certification. It can, however, help make routine security work possible before a crisis creates an emergency budget.

I am equally cautious about proposals to solve supply chain risk by rebuilding everything internally. Internal builds can improve control over some inputs and reveal differences, but they also create an internal toolchain, staffing obligation and publication authority. I would compare that cost with the risk being reduced. The right choice for a critical platform may be excessive for a low-impact application. Self-hosting is an architectural option that needs evidence and maintenance, not a moral position.

AI-assisted development adds another reason to make authority explicit. I would treat generated dependency suggestions, code changes and workflow edits as proposals requiring the same admission process as other contributions. I do not give an assistant broad production credentials simply because it can complete a task quickly. The relevant questions are what it can read, what it can change and which actions require independent approval. The quality of the generated explanation does not establish the safety of the proposed package.

I also treat untrusted repository content as data, rather than as authority to change the rules of the workflow. A tool that reads issues, documentation or build output needs a boundary between information and permission. This is an architectural principle I would apply to automation generally: the component processing outside input should not be able to grant itself broader access on the strength of that input. Human review remains useful only if the reviewer sees the actual proposed action and its scope.

The debate I want is about sustainable, testable control. It should allow disagreement about cost, speed and acceptable dependence. It should also make room for the possibility that adding a control creates operational fragility elsewhere. I would rather discuss those tradeoffs openly than claim that a particular platform, country of hosting, licence or tool category makes an organisation immune to upstream compromise.

19 / ACCEPT RESIDUAL RISK EXPLICITLY

I make residual risk a decision with conditions

Consider a fictional organisation adopting a privileged agent across a business-critical server fleet. The product has a legitimate operational purpose. Its update channel can also introduce code with substantial authority. My initial risk statement would describe an upstream compromise leading to unauthorised execution, service disruption or access to protected information. I would assess the business consequences with the service owner before assigning a label in a matrix.

I would then identify the routes that remain plausible in that environment: a compromised publisher, a stolen release credential, a malicious build input, a tampered delivery path or an administrator accepting the wrong artifact. These are scenario hypotheses for the example, not claims about a particular product. They help me avoid selecting controls solely because they are easy to count.

I do not invent a numerical probability to make this table look scientific. If credible loss data and a suitable model are available, quantitative analysis may help. If they are not, a clear qualitative argument is more honest than an exact-looking number assembled from guesses. The assessment should show why a consequence matters and why the proposed treatment is expected to reduce exposure.

The risk owner may decide that the remaining uncertainty is acceptable because the business benefit is substantial and the recovery capability is credible. That is a legitimate decision when made by the right person with the relevant information. I would record it as conditional acceptance, not as a declaration that the product is safe in every context. A later change in privilege or distribution authority can invalidate the assumptions that supported it.

The CCB report connects its recommendations to CyberFundamentals controls covering governance, assets, access and monitoring. I see that mapping as a useful bridge between intelligence and an existing control programme. It should help organise evidence; it does not certify a product or establish that adopting one tool satisfies every applicable requirement. CCB report, recommendations and CyberFundamentals mapping.

I would connect this decision to the organisation's wider risk process rather than create a separate supply chain universe. The same business impact criteria, ownership rules and review process should apply. My earlier comparison of ISO 27005 and EBIOS RM explores that connection through an illustrative deployment case. The important point here is continuity: the decision should remain visible from assessment through operation and eventual retirement.

20 / A PRACTICAL FIRST 90 DAYS

I would start with a small programme that changes real decisions

A large policy launch is not my first objective. I want a working example that demonstrates how the organisation will make a better decision and recover more effectively. The following sequence is my proposed starting plan, not a timetable guaranteed to fit every organisation. A regulated critical service, a small software company and an internal IT team will need different depth and resources.

First month: identify the authority that matters

I would select a small number of critical services and map their principal software and service dependencies. The work would include release credentials, third-party administration, connected applications and recovery access. I would assign owners to unexplained privileges and remove clearly unnecessary access through the normal change process. The deliverable would be a usable map and a prioritised list of decisions, rather than a promise to inventory everything eventually.

I also establish a minimal admission record for one important software path. It would bind the approved source or supplier release to the actual artifact, record the relevant verification result and identify who authorised deployment. I would test whether someone outside the original implementation team can follow the record. If the process depends on undocumented knowledge, the first improvement is to make that knowledge explicit.

Second month: make the boundary enforceable

I would apply the model to a representative build and deployment workflow. I would separate credentials by purpose, restrict publication authority and verify how untrusted contributions are handled. For a service integration, I would review permissions and rehearse revocation. For a native package, I would test the lifecycle paths that operators actually use. The outcome should be evidence of a narrower, observable authority boundary.

I would involve developers and administrators in evaluating friction. If the approved path is slower because of unnecessary duplication, I would simplify it. If a delay comes from an important independent check, I would explain the reason and ensure the team has the resources to operate it. Controls that cannot be used under ordinary delivery pressure tend to become controls that exist only during audits.

Third month: exercise a failure and review the decision

I would run a scoped exercise involving a suspect update or service credential. The team would identify affected consumers, pause the relevant trust path, preserve evidence, withdraw authority and recover a representative service. I would measure what the exercise actually demonstrates and record what it does not. The exercise should expose missing information and dependencies, not reward a scripted performance with a prearranged successful outcome.

The management review would examine a few operational measures: critical dependencies with accountable owners, releases traceable to admitted artifacts, time required to locate consumers of a suspect component and time required to revoke a tested integration. Each measure needs a defined denominator and scope. I avoid reporting a broad percentage of "secure suppliers" that conceals several incompatible assessments.

I would then expand the programme where the consequences justify it. Some dependencies will need deeper review; others may be adequately controlled by a narrow interface and limited authority. The programme should become more discriminating as it matures. If every supplier remains equally critical and every update requires the same committee, the organisation has probably created administrative workload without enough architectural insight.

21 / THE STANDARD I SET FOR SYSWARDEN

I apply the same questions to SysWarden

I build and maintain SysWarden, so I should be particularly careful about the claims I make for it. I want the project to contribute useful host protection while leaving administrators able to understand and control their systems. That ambition does not mean a host firewall can validate an upstream maintainer, determine the intent of an authenticated update or repair a compromised release identity. Those responsibilities require a broader process.

For a SysWarden deployment, I would expect the organisation to use the canonical documentation, verify the release it intends to install and test it against its own operating assumptions. I would include the interaction with existing administration, networking and security controls. Product behaviour established in one environment should not be expanded into a claim about every distribution, configuration or upgrade history.

I also want the administrator to have an intelligible exit. A product that requires privilege should be able to explain the state it creates and the state it intentionally preserves. Recovery backups should be distinguishable from active configuration. Removal should respect unrelated protections and shared resources. These are engineering expectations I advocate for security products generally, including my own. They need tests and clear documentation, not reassuring adjectives.

The same scrutiny applies to Data-Shield threat intelligence. A useful list is one input to defence. It does not establish the authenticity of a software release and should not be presented as a cure for supply chain compromise. I would combine intelligence with origin checks, cautious integration and operational review. My Data-Shield article explains the intended role and maintenance effort without turning a feed into a universal answer.

My position as a CISO is that the organisation remains accountable for the dependencies it accepts. My position as an architect is that accountability needs enforceable boundaries and a recovery path. My position as a maintainer is that those boundaries cost effort to design, test and sustain. I want those three perspectives to reinforce one another, including when they make a release slower or expose work that still needs to be done.

The discussion I would like to have with another practitioner is concrete: which supplier can currently change your critical systems, which evidence supports that authority, and what would happen if you had to withdraw it tomorrow? I ask the same questions about my own work. That is the useful challenge I take from the CCB report, and the standard I want to keep applying after the headline has left the news cycle.