The canary in the code

A promise that has to be verifiable

Documentation is patient. One can write into a manual that a program only talks to certain configured destinations, and that may even be true — until the next dependency that brings along a tiny function which quietly opens a connection somewhere in the background without anyone noticing. Precisely this scenario is real in the software supply chain: a library that looks harmless, deep down in a dependency tree, is compromised or behaves differently from what its description suggests, and begins sending data somewhere it has no business being.

For a tool like JiCo, which works with sensitive Jira and Confluence data anyway, such a silent outflow would be the worst case imaginable — and it is exactly the case against which a promise in a manual helps least. That is why, next to the description, there is an actual automated test that checks precisely this.

A prepared intruder, built for the purpose

The test — affectionately called the "canary" in the code, after the bird that used to warn of invisible danger in mines — simulates exactly the feared scenario: a prepared library that actively tries to smuggle raw data out of the process. This test runs in the continuous integration pipeline, on every single commit, without network access, and checks that nothing in fact leaves the process.

What matters about this test setup is that it runs without a network. It is not checked whether a destination server received the data — that would be a weaker, after-the-fact control. What is checked, directly at the exit of the process, is whether an attempt to send anything was made at all. A test that relies on a real network call could be fooled by a single successful block; a network-free test does not have that weakness, because it catches the attempt itself at its origin.

The second layer: a guard that runs along at runtime

The canary checks behaviour in the test. In actual operation a second, independent layer takes on the same job: the egress guard. It runs inside the live process and, as a rule, permits only connections to the machine's own loopback, to explicitly configured hosts, and to JiCo's own programs recognised by their canonical path — with a default that blocks in case of doubt rather than letting things through. Every attempt beside that is not only prevented but also recorded in the audit trail and in the log, visible and verifiable afterwards.

These two layers complement each other rather than repeating each other: the canary checks during development, before code is shipped at all. The egress guard checks in operation, at every single customer, with their own actual configuration. A fault that slips past one layer still has to get past the other.

Why not even the licence check gets an exception

The real stress test for a rule like this is not the obvious case but the obvious exception. With JiCo that would have been its own licence check — a legitimate purpose of one's own, for which one might be tempted to grant the egress guard a small special rule. That is exactly what does not happen: JiCo fetches the licence from the licence portal only on a click — like "Check for update" and the optional remote access, a narrowly limited, named exception, always triggered by a person and never carrying Jira content; the licence is then checked entirely offline. Anyone looking at the firewall log will find, for JiCo itself, no connection that does not belong to the configured Jira host or to an explicitly approved destination.

Where the libraries themselves come from

The canary checks behaviour at runtime. A further layer starts even before that, with the question of which third-party libraries may end up in JiCo at all. Every dependency is included exclusively with a verified cryptographic hash — a version of the same library that was swapped out or manipulated afterwards would simply no longer match on the next build attempt and would abort the build, instead of slipping through unnoticed. From exactly this lock file a bill of materials is also derived automatically (SBOM, software bill of materials) — a complete list of all included components, as is needed for audits and security reviews anyway, rather than being maintained separately by hand. This list is never updated casually alongside some ongoing topic, but as a separate, clearly recognisable step with its own pull request.

One building block among several, not the only one

The canary and the egress guard answer one question very concretely: does something leave the process that should not leave it? In doing so they expressly do not answer every conceivable security question — a targeted attack on JiCo itself, carried out by somebody with access to the same machine, is a different category of threat, for which other measures such as the operating system's own per-program network rules are responsible. That is stated openly in JiCo's own review programme for security officers — as a named boundary, not as a concealed gap.

Together with the hash-locked dependencies and the bill of materials (SBOM) derived from the lock file, what emerges is not a single proof but a chain of overlapping controls — each incomplete on its own, but together considerably harder to get around than a single promise in a manual.