Software Supply Chain

Cybersecurity / 10 Sep 2026 / 9 min read

Pin Third-Party Browser Assets with Subresource Integrity

Loading JavaScript directly from another organisation’s server creates a security dependency that is easy to overlook. Your page may contain only a short <script> tag, but the downloaded file executes with the privileges that your site gives that script. If the file at that URL changes unexpectedly, your users can receive code you never reviewed or deployed. Subresource Integrity (SRI) gives the browser an expected cryptographic hash for a fetched resource. The browser hashes the bytes it receives and loads the resource only when the result matches the declared value. That turns “load whatever this URL serves” into “load the specific content I approved from this URL.”

Cybersecurity Software Supply Chain

Cybersecurity / 09 Sep 2026 / 10 min read

Keep Package Publishing Credentials Out of Untrusted Builds

A build job often needs to compile code, run tests, and create an artifact. It usually does not need permission to publish a new version that other people will install. That distinction matters because build systems process code and configuration that change frequently. A pull request, dependency update, test helper, build script, or compromised developer account can influence what runs during a build. If every such build also receives a long-lived package registry credential, code that only needed to be tested may inherit authority to release software.

Cybersecurity Software Supply Chain

Cybersecurity / 05 Sep 2026 / 11 min read

Verify Build Provenance Before Trusting Artifacts

A release artifact can have the expected filename, version, and download location without being the artifact your release process was supposed to produce. A compromised publishing account, an unexpected build path, or a mistake in release automation can put different bytes in front of users while everything around those bytes still looks familiar. Checking an artifact’s hash helps answer whether the bytes changed relative to a known hash. It does not, by itself, answer where that hash came from or whether those bytes were built from the intended source by an approved build process.

Cybersecurity Software Supply Chain

Cybersecurity / 05 Sep 2026 / 11 min read

Verify Artifacts Before Running Them

Downloading software is often treated as the end of a trust decision: the file came from the expected page, so the next step is to run it. That shortcut is risky. A release archive, installer, container image, or build tool can be corrupted in transit or storage, replaced at a distribution point, or fetched from an unexpected source while keeping a plausible filename. Running the wrong bytes can turn a distribution failure into code execution inside a developer workstation, build system, or production environment. The defensive goal is therefore not merely to obtain an artifact. It is to establish that the bytes you received are the bytes an accepted publisher intended you to use.

Cybersecurity Software Supply Chain

Cybersecurity / 05 Sep 2026 / 8 min read

Prevent Dependency Confusion with Explicit Package Sources

A dependency declaration can look precise and still leave an important security question unanswered: where is this package allowed to come from? This matters when an organisation uses both private packages and a public package registry. If a package manager or build configuration can resolve the same package name from more than one source, an attacker may be able to publish a public package that competes with the intended private one. A build that selects the wrong source can then run attacker-controlled package code inside a trusted development or build environment.

Cybersecurity Software Supply Chain

Cybersecurity / 04 Sep 2026 / 8 min read

Verify Dependency Integrity Before Installation

A dependency declaration such as library = 2.4.1 tells a package manager which release you intend to use. It does not, by itself, prove that the bytes being installed are the same bytes you previously reviewed, tested, or approved. That distinction matters when dependencies cross a trust boundary. Packages may come through registries, mirrors, caches, proxies, build systems, or internal artifact stores. If unexpected bytes are accepted somewhere along that path, a familiar package name and version can create false confidence.

Cybersecurity Software Supply Chain