How Putki's security scanning and patching actually works.
Putki is scanned with Trivy and Docker Scout on every release, and every finding gets published. This page covers how we harden the distribution, how patching works, and where to check the current numbers yourself.
Four things that reduce your attack surface before a single pipeline runs.
Multi-stage builds
Build tooling — compilers, package managers, source archives — never reaches the runtime image. What ships is only what's needed to run.
Continuous base image tracking
Base images are tracked continuously by Renovate — not reviewed manually before each release. Drift gets caught the day it happens.
SBOM per release
A CycloneDX Software Bill of Materials is generated and published with every release — the same artifact your procurement team would otherwise request separately.
Gated admin surfaces
Scheduler and other admin surfaces sit behind HTTP auth at the edge, not open by default. The access model is the same one your production deployment would use.
Both get scanned. Only one gets patched for you.
Apache Hop is scanned and its advisories are public — you can and should check them. What changes with Putki is what happens after a finding: on Apache Hop, mitigation is manual — remove the affected plugin, replace a JAR by hand. On Putki, mitigation ships as a patched image.
The advisory list and the raw scan output, both public.
These pull from the same scans our own team reviews, and they update every release — so there's nothing here to keep in sync manually.
Security advisories & mitigation
Every known CVE affecting Apache Hop or its bundled plugins, by version — with the mitigation path for each: which plugin to remove, which library to update, or confirmation it's out of scope for Hop specifically.
Open advisoriesFull vulnerability scans
Complete Docker Scout output, per Apache Hop version — severity breakdown and every CVE ID, score, and description.
Open scan resultsFound something? Tell us before it goes public.
If you find a vulnerability in Putki or in our packaging of Apache Hop, tell us before it's public. We commit to acknowledging reports and keeping you updated as we investigate and patch.
[Placeholder — needs a real inbox and PGP key before this page goes live. See note below.]
Where your data lives, and who can touch what.
EU-based support
Support communications and any shared diagnostics stay in the EU, under GDPR-aligned processes — part of the Enterprise tier.
Least-privilege access, by default
Monitoring and lineage are open, read-only, no credentials required. Scheduler, studio, and the orchestrator API are issued per deployment.
Ready before the audit starts
SBOMs, scan history, and patch records are already published — no need to assemble them the week your auditor asks.
See it running for yourself.
The security posture card on demo.putki.io reads live status at page load — no login required.
How Putki's security scanning and patching actually works.
Putki is scanned with Trivy and Docker Scout on every release, and every finding gets published. This page covers how we harden the distribution, how patching works, and where to check the current numbers yourself.
Four things that reduce your attack surface before a single pipeline runs.
Multi-stage builds
Build tooling — compilers, package managers, source archives — never reaches the runtime image. What ships is only what's needed to run.
Continuous base image tracking
Base images are tracked continuously by Renovate — not reviewed manually before each release. Drift gets caught the day it happens.
SBOM per release
A CycloneDX Software Bill of Materials is generated and published with every release — the same artifact your procurement team would otherwise request separately.
Gated admin surfaces
Scheduler and other admin surfaces sit behind HTTP auth at the edge, not open by default. The access model is the same one your production deployment would use.
Both get scanned. Only one gets patched for you.
Apache Hop is scanned and its advisories are public — you can and should check them. What changes with Putki is what happens after a finding: on Apache Hop, mitigation is manual — remove the affected plugin, replace a JAR by hand. On Putki, mitigation ships as a patched image.
The advisory list and the raw scan output, both public.
These pull from the same scans our own team reviews, and they update every release — so there's nothing here to keep in sync manually.
Security advisories & mitigation
Every known CVE affecting Apache Hop or its bundled plugins, by version — with the mitigation path for each: which plugin to remove, which library to update, or confirmation it's out of scope for Hop specifically.
Open advisoriesFull vulnerability scans
Complete Docker Scout output, per Apache Hop version — severity breakdown and every CVE ID, score, and description.
Open scan resultsFound something? Tell us before it goes public.
If you find a vulnerability in Putki or in our packaging of Apache Hop, tell us before it's public. We commit to acknowledging reports and keeping you updated as we investigate and patch.
[Placeholder — needs a real inbox and PGP key before this page goes live. See note below.]
Where your data lives, and who can touch what.
EU-based support
Support communications and any shared diagnostics stay in the EU, under GDPR-aligned processes — part of the Enterprise tier.
Least-privilege access, by default
Monitoring and lineage are open, read-only, no credentials required. Scheduler, studio, and the orchestrator API are issued per deployment.
Ready before the audit starts
SBOMs, scan history, and patch records are already published — no need to assemble them the week your auditor asks.
See it running for yourself.
The security posture card on demo.putki.io reads live status at page load — no login required.