Nordvantage Logistics SA

§ 0What you are holding

This audit changed nothing you run. No configuration was modified and no fix was applied. Every command in this report is read-only and you can run all of them yourself. The one exception is stated plainly because it matters: the restore drill (R-009) provisioned a disposable instance, restored a backup into it, and destroyed it the same day. Nothing in service was touched at any point.

Contractually out of scope, and therefore absent: any fix, development or configuration change; application security testing; penetration testing; application code review; regulatory compliance audit. Where a check touched the edge of one of these, the boundary is stated at the check. DE-01 is the clearest case: I read which paths each merge request touched and the DDL in your migration files. I did not read application logic.

Every figure drawn from your systems carries its source inline. Counts of my own checks, and my estimates of your team's effort, are mine and carry no marker. They are the only unmarked numbers in this document.

§ 1The short version

Nordvantage runs a freight booking and tracking platform on GCP: two GKE Autopilot clusters, nv-prod and nv-staging, carrying 23 services kubectl · point-in-time 13/05, a regional Cloud SQL PostgreSQL instance, a managed Kafka cluster for carrier events, and a self-hosted GitLab instance that is both your source of truth and your deploy path. Around 40 engineers reported · call 1, releasing weekly with hotfixes as needed.

I ran 58 checks across six domains. 34 came back sound, 9 produced a finding, 2 produced a cost finding, 5 I could not determine in five days, 8 did not apply to your setup.

Of the 9 findings, 1 is ranked High, meaning I observed every step of a sequence ending in credential exposure except the initiating event itself. It is R-001, your GitLab instance, and I called Marc on 12 May rather than leaving it for this document. Closing the exposure costs half a day plus a maintenance window. The other eight are three Medium and five Low, listed in full, each with the reason it did not clear the bar.

12 of the 14 items in the 90-day plan are things your team can do without outside help. The first five, which close the High and two Mediums, come to roughly two person-days plus one maintenance window. The rest spread across the quarter and each carries its own estimate in §10. The two that need a skill you may not have in-house are named as such, with the specific capability written out.

Separately from the register, the billing review identified €7,164 a year of spend attached to resources serving nothing, and a further €24,360 a year that is worth having but needs a decision from you. Cost is not risk, so none of it is in the register; it is in §7 with the method that produced it.

Two conditions I raised on Tuesday are not in the register at all. They failed their own counter-argument and ship as rejections, because a register that only ever grows is a sales document.

§ 2Coverage

58 checks, pre-registered and sent to you on 6 May, five days before the week started. You could see the list before I could see your systems. That ordering is the point: it stops the check list being written backwards from whatever I happened to find.

Where a check sampled rather than enumerated, the population, the sample size and the selection rule were recorded at the moment of sampling. Nothing here reconstructs its own sampling rationale after the fact, because a reconstructed rationale is always a flattering one.

§ 3Working, and should not be disturbed

A report that is entirely findings is both a sales document and an inaccurate description of your platform. These are load-bearing and I would argue against changing any of them.

§ 4Do not do this

Two things a well-meaning quarter might produce, which would make your platform worse.

Do not tighten gitlab-deploy@ to objectViewer without checking what it writes first

It is the obvious-looking cleanup and it can take production down. Before touching it, run git grep -nE 'terraform (plan|apply|init)' scoped to the deploy jobs, and read 90 days of bucket data-access logs filtered to that principal's writes. If either returns anything, the grant is load-bearing. If you do it anyway, the rollback is to re-grant objectAdmin. Note also that item 9 of the plan puts a Terraform job in CI this quarter, which would collide with the tightened grant.

Do not adopt a maturity model or a scoring dashboard for this register

Eight findings do not need a heat map, and the moment a register has a score, the score becomes the thing that gets managed. This is a list of specific conditions with named next actions, and it should stay one.

§ 5If you do only three things

That is one and a half days of your team's time plus one maintenance window, and it closes the only High along with two of the three Mediums.

This set is ordered differently from the short list at the end of §10, deliberately. Here the ranking is by risk reduction. There it is by what fits an afternoon. R-002 is the largest job and it sits third because item 1 does not depend on it: you can close the exposure today and upgrade in the window you already have booked.

§ 6Risk register

Levels are derived, not chosen. Each entry states a consequence class and a trigger-evidence grade, and the level is a lookup of the two in the table below. To move an entry up, I have to produce evidence that moves it a cell. I cannot type a level.

observed-in-window — the full chain, including the initiating event, occurred in your data, dated.
mechanism-present — every step of the chain observed; only the initiating event absent.
hypothetical — at least one step in the chain is assumed rather than observed.

Note what the bottom two rows delete: a hypothetical annoyance is not a finding, it is nothing. Two conditions were removed by that rule this week and appear in §8.

4 of the 9 entries were already on your board, including 0 of the 1 High. On those four the contribution is the dating, the consequence and the ordering, not the discovery. 7 of the 9 are fixable by your team alone.

# 1. Reachable from outside? Run this from a host that is NOT on your network.
curl -sS -o /dev/null -w 'HTTP %{http_code} from %{remote_ip}\n' \
  https://gitlab.nordvantage.example/users/sign_in

# 2. Which ingress rules create a public path (scoped: ingress only, enabled only)
gcloud compute firewall-rules list \
  --filter='direction=INGRESS AND disabled=false AND sourceRanges:0.0.0.0/0' \
  --format='table(name,priority,network,targetTags.list(),
                  allowed[].map().firewall_rule().list())'

# 3. What actually applies to the instance, not what merely exists in the project
gcloud compute instances network-interfaces get-effective-firewalls gitlab-01 \
  --zone=europe-west1-b \
  --format='table(type,direction,disabled,priority,sourceRanges.list())'

# 4. The six variables, metadata only. jq drops .value before anything reaches disk.
curl -sS -H "PRIVATE-TOKEN: $TOKEN" \
  'https://gitlab.nordvantage.example/api/v4/groups/nordvantage/variables?per_page=100' \
  | jq -r '.[] | [.key, .protected, .masked, .environment_scope] | @tsv'

# Symbolic status, and only what has not finished. status_name avoids the
# integer enum, which is what makes the raw table hard to read.
sudo gitlab-rails runner '
  Gitlab::Database::BackgroundMigration::BatchedMigration
    .where.not(status: :finished)
    .each { |m| puts [m.id, m.job_class_name, m.table_name,
                      m.status_name, m.updated_at].join("  ") }'

# The failing jobs underneath one of them. `attempts` and the exception live
# here, on the jobs table, not on the migration row.
sudo gitlab-psql -c "select batched_background_migration_id as mig, status, \
  attempts, left(exception_class, 48) as exception, updated_at \
  from batched_background_migration_jobs \
  where batched_background_migration_id = 4291 \
  order by updated_at desc limit 10;"

gcloud compute ssh bastion-ops --tunnel-through-iap --command \
  '/usr/lib/update-notifier/apt-check --human-readable; uname -r; dpkg -l "linux-image-*" | tail -5'

kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] as $w
  | ($w.spec.template.spec.containers
     + ($w.spec.template.spec.initContainers // []))[]
  | select(.image | test("@sha256:") | not)
  | [$w.kind, $w.metadata.namespace, $w.metadata.name, .name, .image] | @tsv'

kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] as $w | $w.spec.template.spec.containers[]
  | [(.resources.requests.cpu // "unset"),
     (.resources.requests.memory // "unset")] | @tsv' \
  | sort | uniq -c | sort -rn

gcloud logging sinks list --format='table(name,destination,filter)'
gcloud logging buckets describe _Default --location=global --format='value(retentionDays)'

kubectl -n nv-staging get configmap integration-endpoints -o yaml

One thing to accept and not fix

The nv-edi bridge does not use the shared CI template, and should not be made to. It is the legacy EDI connector, it deploys twice a year, and its pipeline is 40 lines that one person understands GitLab · .gitlab-ci.yml, 13/05. Migrating it would cost days and buy consistency on a service whose whole value is that it has not changed since 2023. Recorded here so the next person who greps for non-conforming pipelines does not spend a sprint on it.

§ 7What this costs you, and what it need not

Cost is not risk, so none of this is in the register. It is here because it is the part of the week that carries a number, and because the first table is true whatever you decide about anything else.

How these figures were produced. Every line comes from the billing export, compared month over month across the three months to 30 April GCP billing export. Where a line grew because you shipped more, that growth is separated out and is not counted as waste. Your platform cost €14,200 a month on average across that window GCP billing export.

Removable now, with no argument against it

Each of these is a resource attached to nothing, serving no request. There is no counter-argument to make, which is why it is separated from the table that follows.

One caution on the image line. R-004 found that 9 of 23 workloads pull by mutable tag, so an untargeted cleanup policy can delete an image production is about to reschedule onto. Difference the registry against the running set first and delete only unreferenced digests. That is fifteen minutes, not a decision, which is why the line stays in this table rather than the next.

That is 4.2% of your monthly bill and about two hours of work. It is item 1 of the 90-day plan for that reason: nothing in it needs a decision from anyone.

Worth doing, but each needs a decision

These are larger and none of them is free. The argument against each one is real, and it is stated rather than left for you to find.

Not costed, deliberately

R-005 — Autopilot request sizing. The reservation is the invoice, but the direction is not uniform: two services need more. No figure until the 30-day utilisation view exists, which is plan item 11.

U-001 — Kafka provisioning. Throughput is measured; the floor set by partitions, replication and retention is not. Quoting a saving before that is answered would be quoting a number I cannot defend.

§ 8Considered and not raised

Things I checked that turned out fine, and two conditions that died on their own counter-argument. Both were on my list on Tuesday. Neither survived Thursday.

Checked and sound, briefly: user-managed service account keys (none) · service account key age · public bucket ACLs (none) · secret scanning across all 23 repositories · branch protection on main group-wide · Terraform drift on the nightly plan · on-call rota currency and depth · merge request approval settings · runner tag scoping · Cloud SQL public IP (disabled) · org policy inheritance on the production folder.

§ 9What I could not determine in five days

Five checks did not resolve. This section is a property of a five-day audit, not an admission. Note what is not here: whether your backups restore. That question is answered in R-009, because the drill is in scope.

§ 10The 90-day plan

Ordered by value against effort. 12 of 14 items are yours to do without me. The two marked flochai name the capability rather than the company, so you can price hiring it against buying it.

Days 1 to 14 — configuration only, each closeable in an afternoon

Days 15 to 45

Days 46 to 90

If you cannot spend six days

Do items 1, 2 and 3. That is one afternoon plus a window. It closes the High, one Medium, and the whole of the first cost table. This is not the same set as §5, and the difference is deliberate: §5 ranks by risk reduction and this ranks by what fits an afternoon. R-002 is the larger job and its value depends on the upgrade actually being attempted, so if you have one afternoon rather than three, buy the exposure closure first.

Not in the 90 days, and why

Migrating nv-edi to the shared template (accepted, §6). A chat notifier for CI (rejected, §8). Per-service latency objectives beyond the two in U-004, which is a quarter of its own and should not start in the same quarter as the sizing work.

§ 11Method, and how to argue with this document

One person cannot have separation of duties. This is the honest substitute.

The check list was fixed before the week. 58 checks, sent 6 May. Findings could only come from that list, which stops the list being written backwards from what I found.

Severity is a lookup, not an opinion. Every entry states its two inputs. If you disagree with a level, disagree with one of the inputs, and there is then a defined thing to argue about rather than a feeling to trade.

The register froze Friday at 17:00 and access ended Monday. An unevidenced thought on Tuesday is not a finding, and nothing was added after the freeze. The 90-day plan was written after it, deliberately, so severity could not be retrofitted to fit a plan.

You argued with it on Thursday. Call #2 put the draft register in front of you while there was still a working day to act on a demotion. R-002 was demoted from High to Medium as a direct result, and the reason is written into the entry. What you did not see before the freeze: the five Low entries and the two rejections, which I raised on Thursday but did not walk through line by line.

I do not price consequences in euros, because I do not know your revenue per hour. I do price savings in euros, from your own vendor bill, and §7 is the only place that happens.

Corrections are free for 30 days after delivery. After that the register is yours. Every entry carries a command you can re-run alone, so an entry that still returns the same answer in six months, with nothing having happened and nothing having fired, means I was wrong about it. You do not need me to see that.

The walkthrough call

One hour, agenda fixed: R-001 and its window, then R-002 because item 6 depends on it, then the two flochai items so you can decide whether they are worth outside help or worth hiring for. Ten minutes at the end for the rejections, because how a finding gets killed is more useful to you than how one gets raised.

Please revoke my access at the end of that call, not before. I have committed to correcting anything you can disprove for 30 days, and I need to be able to check.

AppendixAccess, evidence and checks

Access requested, granted and refused

Deliberately not requested: production database data access; application source beyond CI configuration and migration DDL; Auth0 read:users; customer records of any kind.

Evidence

71 items, filed automatically as each command ran. Nothing unscrubbed touched disk. The scrubber runs before anything is written, and the capture tool exits if it is not present. The day-1 smoke test, run before any other command: a fake AWS key piped through the tool filed output reading AWS_KEY_REDACTED. Had it failed, nothing else would have run.

Secret values. For GCP the capture is value-free by construction, because the role held cannot read secret payloads. For GitLab that is not true: the variables endpoint returns values. The capture was filtered at the command so no value reached disk, the grant was scoped to CI-01, and it was time-boxed to 12–15 May.

Personal data. The bundle contains personal data: IAM identities, incident participants, alert routing handles. It is encrypted to your key, the local copy is destroyed at delivery plus 30 days, and the processing terms in the signed general terms apply to it.

The 58 checks — representative rows