Repository navigation
feat(supply-chain): SBOM, vuln scanning, signed releases, dep cleanup #511
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -34,6 +34,31 @@ Thanks to **@sondt99** for reporting this through coordinated disclosure. | |
|
|
||
| Operators on 26.06.1 should plan to upgrade. | ||
|
|
||
| ## Supply-chain hardening | ||
|
|
||
| Arc now ships machine-readable software bill of materials (SBOM) and signed vulnerability scan reports as first-class release artifacts, targeting EO 14028 and defense supply-chain review requirements. | ||
|
|
||
| **SBOM generation.** Every release now includes two SBOM files generated by [Syft](https://github.com/anchore/syft): | ||
|
|
||
| - `arc-VERSION-sbom-container.spdx.json` — SPDX JSON generated from the published container image; captures the DuckDB native libraries, SQLite, and all Debian packages in the runtime layer. | ||
| - `arc-VERSION-sbom-source.cyclonedx.json` — CycloneDX JSON generated from the Go source tree; names every Go module with its exact version and SPDX license expression. | ||
|
|
||
| Both files are attached to the GitHub release and can be ingested directly by DCSA/CMMC supply-chain tooling. Both formats are provided because toolchain expectations vary across prime contractors. | ||
|
|
||
| **Vulnerability scanning.** Every release container image is scanned with [Trivy](https://github.com/aquasecurity/trivy) (CRITICAL/HIGH/MEDIUM findings) and the Go module graph is scanned with [`govulncheck`](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck) (Go's official vulnerability database). Scan outputs: | ||
|
|
||
| - `arc-VERSION-trivy-report.json` — full Trivy JSON report for the container image, attached to the GitHub release. | ||
| - SARIF results are uploaded to the GitHub Security tab for every release. | ||
| - `govulncheck` runs on both build architectures (amd64 and arm64) in CI; a finding blocks the binary build. | ||
|
|
||
| The deliverable is signed scan evidence attached to each release, not "zero findings" — transitive OS CVEs from the Debian base layer outside Arc's control are reported but do not gate the release. | ||
|
|
||
| **Signed releases and SLSA Level 3 provenance.** Every release binary and container image is cryptographically signed using [Sigstore/cosign](https://github.com/sigstore/cosign) with keyless OIDC signing — no key material is stored or managed; the GitHub Actions OIDC token is the identity, anchored in the [Rekor](https://rekor.sigstore.dev) public transparency log. Air-gapped and Zarf-based deployments can verify artifacts offline using the bundled signature files. | ||
|
|
||
| - `arc-linux-amd64.bundle`, `arc-linux-arm64.bundle` — cosign signature bundles for each binary (signature + Rekor transparency-log entry). Verify with: `cosign verify-blob arc-linux-amd64 --bundle arc-linux-amd64.bundle --certificate-identity-regexp "^https://github.com/Basekick-Labs/arc/" --certificate-oidc-issuer https://token.actions.githubusercontent.com` | ||
| - Container images on GHCR are signed by manifest digest. Verify with: `cosign verify ghcr.io/basekick-labs/arc:VERSION --certificate-identity-regexp "^https://github.com/Basekick-Labs/arc/" --certificate-oidc-issuer https://token.actions.githubusercontent.com` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similarly to the binary verification, the container image verification regex should be restricted to the specific release workflow file (e.g., |
||
| - `arc-VERSION.intoto.jsonl` — [SLSA Level 3](https://slsa.dev/spec/v1.0/levels) provenance attestation for the release binaries, generated by the [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator). Proves who built the artifact, from what source commit, and with what build inputs. Verify with: `slsa-verifier verify-artifact arc-linux-amd64 --provenance-path arc-VERSION.intoto.jsonl --source-uri github.com/Basekick-Labs/arc` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To ensure the artifact was built from the expected release tag rather than an arbitrary commit or branch in the repository, it is highly recommended to include the |
||
|
|
||
| ## Bug fixes | ||
|
|
||
| **Pre-epoch (pre-1970) timestamps now partition into the correct hour (#312).** The ingest hour-bucketing used plain integer division (`time / microsecondsPerHour`), which truncates toward zero rather than flooring. A negative timestamp — a pre-1970 date, which Line Protocol and MessagePack both accept — was therefore filed one hour too late: a row at `1969-12-31 23:30` landed in the `1970/01/01/00/` partition instead of `1969/12/31/23/`, so a time-range query for the pre-1970 hour would miss it. Hour bucketing now floors toward negative infinity, so a timestamp always partitions into the hour that actually contains it; non-negative timestamps are unaffected (floor and truncation agree). The in-process CSV/Parquet import `partitions_created` count uses the same corrected bucketing. This fixes go-forward writes; any pre-1970 data already written by an affected build would need to be re-ingested or recompacted to move into the correct partition. | ||
|
|
@@ -103,7 +128,7 @@ The emergency kill-switch `replication_catchup_enabled=false` remains available. | |
|
|
||
| ## Dependencies | ||
|
|
||
| No dependency changes from 26.06.1. | ||
| **Benchmark suite moved to a dedicated repository.** The `benchmarks/` directory — containing load generators for Arc, ClickHouse, PostgreSQL, Elasticsearch, and others — has been extracted to [github.com/Basekick-Labs/arc-benchmarks](https://github.com/Basekick-Labs/arc-benchmarks). As a result, `github.com/ClickHouse/clickhouse-go/v2`, `github.com/jackc/pgx/v5`, and their transitive deps (`jackc/pgpassfile`, `jackc/pgservicefile`) have been removed from the product module — they were never part of the Arc binary or container image, only benchmark tooling. The product module now has **25 direct dependencies**, all from tier-1 OSS organizations. | ||
|
|
||
| --- | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a broad regular expression like
^https://github.com/Basekick-Labs/arc/allows any workflow run within the repository (including development, testing, or pull request workflows if they have write/id-token permissions) to produce signatures that pass verification. To adhere to the principle of least privilege, it is highly recommended to restrict the identity to the specific release workflow file (e.g.,release.yml) by using:cosign verify-blob arc-linux-amd64 --bundle arc-linux-amd64.bundle --certificate-identity-regexp "^https://github.com/Basekick-Labs/arc/\.github/workflows/release\.yml@" --certificate-oidc-issuer https://token.actions.githubusercontent.com