Add automated Rust dependency advisory checks
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 121
- Forks
- 45
- Avg merge
- 18h 43m
- Merged PRs (30d)
- 10
Description
Context
The Rust host is statically linked into every produced application and includes networking, TLS, terminal, randomness, and bundled SQLite dependencies. The repository pins exact dependency versions and commits Cargo.lock, but no workflow currently runs cargo audit, cargo deny, or an equivalent RustSec advisory check.
Because the resulting code is embedded into released binaries, users do not receive fixes unless basic-cli updates and rebuilds its host.
RustSec advisory database:
https://rustsec.org/advisories/
Suggested direction
Add automated dependency monitoring with:
- a pull-request advisory check;
- a scheduled workflow so newly published advisories are detected without a code change;
- Dependabot/Renovate or another deliberate update mechanism;
- a documented, time-bounded exception format for advisories that do not affect enabled features or reachable code.
Consider scanning both the main Cargo.lock and ci/rust_http_server/Cargo.lock, while clearly distinguishing release dependencies from test-only dependencies.
Acceptance criteria
- Pull requests fail on applicable unacknowledged vulnerabilities.
- A scheduled job checks for new advisories.
- Both lockfiles are covered with release/test scope clearly reported.
- Advisory exceptions require rationale, owner, and expiry/review date.
- Dependency update ownership and release rebuild expectations are documented.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the repository's existing workflow configuration and both Cargo.lock files: Cargo.lock and ci/rust_http_server/Cargo.lock. Compare cargo audit, cargo deny, and the suggested update mechanisms against the release and test dependency scopes. Done means pull requests and scheduled checks cover both lockfiles, and documented exceptions include rationale, owner, and expiry or review date.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, rust
- Domain
- ci-cd, devops, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100