apache / apache/iggy

feat(ci):Make production binaries auditable via `cargo auditable`

Open
#3,700 0 comments 0 reactions 1 assignee Claimed by @ryerraguntla View on GitHub
CI/CD
Dominant language
Rust
Stars
4.9k
Forks
432
Avg merge
2d 10h
Merged PRs (30d)
173

Description

### Description

**Type:** ci / security / release
**Labels:** `security`, `ci`, `release`, `A-tooling`
**Source:** discussion [#3678](https://github.com/apache/iggy/discussions/3678)

## Summary

Build shipped Iggy binaries (`iggy-server`, `iggy` CLI, `iggy-connectors`, and
release connector `.so` plugins where applicable) with `cargo auditable` so the
complete dependency tree is embedded in each artifact. Deployed binaries can then
be scanned for CVEs post-release with `cargo audit bin`, even when the source
tree or `Cargo.lock` is no longer available.

## Motivation

The audit and cargo-deny gates protect the source tree at merge time. They do
not help an operator running a binary shipped months ago when a new advisory
drops. `cargo auditable` embeds the dependency manifest into the binary at build
time, enabling point-in-time CVE scanning of any deployed artifact. This closes
the loop: scan at merge (cargo-deny), scan at rest (cargo-auditable +
`cargo audit bin`).

Reference:

### Affected area / component

CI / build / tooling

### Proposed solution

## Proposed approach

1. Use `cargo auditable build --release` in the release build workflow
(`.github/workflows/_build_rust_artifacts.yml` and any binary-producing
release jobs) in place of `cargo build --release` for shipped artifacts.
2. CI installs `cargo-auditable` on demand (do not pin in
`rust-toolchain.toml`; follow the on-demand cargo-tool install pattern).
3. Add a verification step: `cargo audit bin ` on each produced binary,
confirming the audit data is present and scannable. Non-zero on new findings
(or warn-only initially, aligned with the audit-remediation issue).
4. Document the operator workflow (how to run `cargo audit bin` against a shipped
Iggy binary) in release docs / `SECURITY` guidance.
5. Confirm no meaningful binary-size or build-time regression; note the delta.

## Scope / tasks

- [ ] Switch release artifact builds to `cargo auditable build --release`.
- [ ] Install `cargo-auditable` on demand in the relevant workflows.
- [ ] Add a `cargo audit bin` verification step over produced artifacts.
- [ ] Confirm connector `.so` plugin builds embed audit data (or document why not).
- [ ] Document operator-side `cargo audit bin` usage in release/security docs.
- [ ] Measure and record binary-size / build-time impact.

## Acceptance criteria

- Shipped release binaries contain embedded audit data (`cargo audit bin`
returns dependency data, not "no audit data found").
- Release workflow verifies embedded audit data per artifact.
- Operator-facing documentation describes how to scan a deployed binary.
- No unacceptable size/build-time regression (delta documented).

## Related

- Audit and remediate known CVEs (sibling issue).
- Add `cargo deny` as a pre-merge check (sibling issue).

### Alternatives considered

_No response_

### Contribution

- [x] I'm willing to submit a pull request to implement this feature

### Good first issue

- [ ] I think this could be a good first issue for a new contributor

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.