Skip to content

[REQ] Manual "hash to hash" patch rules for images without supported package managers #1033

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 task
robert-cronin opened this issue Apr 29, 2025 · 4 comments · May be fixed by #1070
Open
1 task

[REQ] Manual "hash to hash" patch rules for images without supported package managers #1033

robert-cronin opened this issue Apr 29, 2025 · 4 comments · May be fixed by #1070
Assignees
@robert-cronin
Labels
enhancement New feature or request
Milestone
v0.11.0

Comments

@robert-cronin
Copy link
Contributor

robert-cronin commented Apr 29, 2025 •
edited
Loading

What kind of request is this?

New feature

What is your request or suggestion?

Copas current patch flow depends on the target image exposing a package manager (apk, dpkg, rpm) so it can:

  1. locate an installed version (i.e. fixed version mapping) and
  2. apply an update with dependency/backwards compatible safety

That leaves a gap for images that do not ship a conventional package manager (e.g. scratch images, tiny statically linked distroless builds, language specific buildpacks) or for scenarios where operators already know exactly which artifact hash remediates a CVE and simply want to swap it in

e.g. there might be a CVE that shows up for a non-packaged file when using rekor:

trivy image --sbom-sources rekor <image>

Are you willing to submit PRs to contribute to this feature request?

  • Yes, I am willing to implement it.
@robert-cronin robert-cronin added the enhancement New feature or request label Apr 29, 2025
@ashnamehrotra ashnamehrotra added this to the v0.11.0 milestone Apr 30, 2025
@robert-cronin robert-cronin self-assigned this May 19, 2025
@robert-cronin
Copy link
Contributor Author

For this, we could have something like copa patch -i <image> -m manual-rule.yaml where we define a yaml schema like this:

target:
  path: /usr/local/bin/foo
  sha256: "a3b1…deadbeef"
replacement:
  source: registry.example.com/patches/foo-fixed:1.0
  internalPath: /bin/foo
  sha256: "9c55…cafefeed"
  mode: 0755

@robert-cronin robert-cronin linked a pull request May 22, 2025 that will close this issue
Draft
@robert-cronin
Copy link
Contributor Author

Below are some potential use cases that might benefit from manual patching:

  • binary plugins/extensions (e.g. PostgreSQL extensions, nginx modules)
  • quick emergency patching (e.g. zero-day vulnerabilities where you have a patched binary but package repos havent updated yet)
  • configuration files with security issues (e.g. client-side TLS certs that need updating)

@ritazh
Copy link
Contributor

ritazh commented May 29, 2025

The scenario I would like to address is when vulnerabilities are discovered in frameworks like .NET, Python, NodeJS, etc., how can Copa be used to automate patching for that vulnerability if I know the hash for the vulnerable version and the hash for the patched version.

@amanycodes
Copy link
Contributor

Correct me if I am wrong but what @ritazh mentioned would come under app-level patching, right? Like even if hash to hash patching is supported, will this cover the patching for vulnerabilities in these kind of packages? 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@robert-cronin robert-cronin

Labels
enhancement New feature or request
Projects
Copacetic Workboard
Status: 🆕 New
Milestone
v0.11.0
Development

Successfully merging a pull request may close this issue.

feat: add manual rule hash to hash patching robert-cronin/copacetic
4 participants
@ritazh @robert-cronin @ashnamehrotra @amanycodes