Borehole · Project · free tier

akuity/kargo

Free reading: not for reliance

e1c6edd · 3,628 commits · 3,352 files
Read 2026-11-03

akuity/kargo: technical due diligence, read from its repository

What Borehole read in akuity/kargo's code and history at e1c6edd: its licence, security advisories, releases, review practice, tests, dependencies and operations. Every finding cites the file and line it rests on. The full report also covers the team and asks the questions the code cannot answer.

Dimension	Rating
Architecture & Codebase — including AI provenance	adequate
Engineering Process & SDLC Maturity	adequate
Product & Engineering Maturity	adequate
Security & Reliability Posture	adequate
Observability & Operations	adequate
Fit with the Acquirer	not assessable

What the repository says

Releases are cut from another branch than the one surveyed
.github/PULL_REQUEST_TEMPLATE.md:28: states a policy on AI-generated contributions

Architecture & Codebase — including AI provenance

adequate

01.6

pkg/controller/stages/regular_stages.go is 2,513 lines, 24× this codebase's median file

adequate

The median source file here is 101 lines. 6 files exceed 1,010 lines, the largest being 2,513. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.

Evidence

pkg/controller/stages/regular_stages.go:1 — 2,513 lines (24× median)

pkg/server/rbac/roles.go:1 — 1,456 lines (14× median)

pkg/expressions/function/functions.go:1 — 1,401 lines (13× median)

pkg/controller/management/projects/projects.go:1 — 1,271 lines (12× median)

pkg/promotion/runner/builtin/argocd_updater.go:1 — 1,178 lines (11× median)

01.25

1 base image floats: no version, or `latest`

adequate

1 of 6 `FROM` lines in product Dockerfiles name an image without a version, or with `latest`. Each build pulls whatever the registry serves that day, so the image that ships can change without a commit, and last month's build cannot be reproduced. Pin a version, or a digest.

Evidence

Dockerfile:131 — base image without a version

Engineering Process & SDLC Maturity

adequate

02.24

5% of recent commits change more than 2,000 lines

adequate

65 of 1239 commits in the last 24 months changed over 2,000 lines of code, not counting reformatting, renames, vendored or generated code. A change that size is rarely reviewed line by line. Ask how they were reviewed, and what made them that large.

Evidence

65 commits over 2,000 lines

Product & Engineering Maturity

adequate

04.3

93 direct dependencies in a single manifest

adequate

go.mod declares 93 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

Evidence

go.mod — 93 declared

ui/package.json — 35 declared

api/go.mod — 5 declared

pkg/x/client/fidelity/go.mod — 4 declared

04.62

Releases are cut from another branch than the one surveyed

adequate

The newest release, v1.12.5, is not on the branch this survey read; the newest release on it is v1.0.0. The shipped product may differ from what this report describes. Survey the release branch too.

Evidence

tag v1.12.5

Security & Reliability Posture

adequate

05.13

2 outbound calls can wait forever

adequate

2 HTTP calls use a client with no timeout (Python `requests` without `timeout=`, or Go's default client). When a dependency slows down, each one holds a worker until the connection gives up, and enough of them take the service down with the dependency.

Evidence

pkg/gitprovider/bitbucket/cloud/zz_bitbucket_cloud_client.gen.go:3691 — outbound call without a timeout

pkg/gitprovider/bitbucket/datacenter/zz_bitbucket_datacenter_client.gen.go:272 — outbound call without a timeout

05.26

18 locked dependencies have published vulnerabilities, 8 high or critical in what ships

adequate

18 of 1,159 locked dependencies match 48 published advisories in OSV, 27 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version.

Evidence

ui/pnpm-lock.yaml — fast-uri 3.1.2: GHSA-4c8g-83qw-93j6 (high), fixed in 3.1.3

ui/pnpm-lock.yaml — zod 4.4.3: GHSA-mrhx-c7xc-m3w5 (high), fixed in 4.6.6

ui/pnpm-lock.yaml — brace-expansion 1.1.12: GHSA-3jxr-9vmj-r5cp (high), fixed in 1.1.16; a development dependency

05.65

13 advisories against this project in the last 24 months, 3 high or critical

adequate

The newest was published on 2026-10-09. A project that publishes advisories is telling its users about its fixes, and the count and pace say how much security work it carries. GHSA-wp4p-hr79-q4g8 (moderate), GHSA-g7gw-m874-7rmf (low) are fixed in the surveyed commit; which release carries them cannot be told from this history, which does not place the release users run. Answer lives in: the version you run. The record is incomplete: NVD: 5 records name kargo with nothing tying them to this repository (CVE-2025-26908, CVE-2025-5816, CVE-2026-103378, …).

Evidence

2026-10-09: GHSA-927c-fm24-cq67 (critical), fixed in v1.8.18: Argument Injection Vulnerability in Promotion `kustomize-build` Step

2026-10-02: GHSA-rx5g-3338-f2mf (moderate), fixed in v1.12.0: Missing Authorization Vulnerability in Freight Approval Through the Kubernetes API

2026-09-30: GHSA-8p8c-cfj9-vc94 (moderate), fixed in v1.8.17: SSRF in Promotion http/http-download Steps Enables Access to the IPv6 Cloud Instance Metadata Endpoint

2026-09-05: GHSA-gp97-g7w8-w8c7 (moderate), fixed in v1.8.15: Missing Authorization Vulnerability in Resource Refresh API Endpoints

2026-09-05: GHSA-mmqq-9f45-g6rh (critical), fixed in v1.8.15: Incorrect Authorization Vulnerability in Generic Resource API Endpoints Permits Unauthorized Writes to Cluster-Scoped Resources

Observability & Operations

adequate

06.9

No error reporter is wired in

adequate

Nothing in the service initialises an error reporter (Sentry, Rollbar, Bugsnag, Honeybadger or an APM agent). An exception in production reaches a person only if someone is reading the logs, which usually means a customer reports it first.

Evidence

no error reporter initialised

06.14

Readiness and liveness probes are identical in 2 of 3 workloads

adequate

Both probes call the same endpoint. When a dependency slows down, the liveness probe fails with the readiness probe, so the platform restarts pods that only needed taking out of rotation, and a partial outage becomes a full one. Liveness should ask whether the process is alive; readiness whether it can serve.

Evidence

charts/kargo/templates/api/deployment.yaml — same probe endpoint twice

charts/kargo/templates/external-webhooks-server/deployment.yaml — same probe endpoint twice

Fit with the Acquirer

not assessable

Not rated: structurally not assessable from a repository.

akuity/kargo: technical due diligence, read from its repository

What the repository says

Architecture & Codebase — including AI provenance

pkg/controller/stages/regular_stages.go is 2,513 lines, 24× this codebase's median file

1 base image floats: no version, or `latest`

Engineering Process & SDLC Maturity

5% of recent commits change more than 2,000 lines

Product & Engineering Maturity

93 direct dependencies in a single manifest

Releases are cut from another branch than the one surveyed

Security & Reliability Posture

2 outbound calls can wait forever

18 locked dependencies have published vulnerabilities, 8 high or critical in what ships

13 advisories against this project in the last 24 months, 3 high or critical

Observability & Operations

No error reporter is wired in

Readiness and liveness probes are identical in 2 of 3 workloads

Fit with the Acquirer

Read more, or read your own