Crates.io | sbom-walker |
lib.rs | sbom-walker |
version | 0.10.2 |
source | src |
created_at | 2023-09-21 07:36:06.403062 |
updated_at | 2024-11-27 13:00:05.381999 |
description | A library to work with SBOM data |
homepage | |
repository | https://github.com/ctron/csaf-walker |
max_upload_size | |
id | 979170 |
size | 222,626 |
"Walk" CSAF data from a remote server, allowing one to work with the data.
In addition, this repository also has a tool for working with SBOM data. Most of the options explained are valid for both SBOM and CSAF.
There's a command line tool, which can be used right away.
Download a ready-to-run binary from the GitHub release page: https://github.com/ctron/csaf-walker/releases
You can also use cargo binstall
to install such a binary:
cargo binstall csaf-cli
cargo binstall sbom-cli
Or compile it yourself, using plain cargo install
:
cargo install csaf-cli
cargo install sbom-cli
You can download all documents by providing a domain of the CSAF trusted provider:
mkdir out
csaf sync -3 -v -d out/ redhat.com
It is also possible to only download files, skipping the validation step (which can be done later using an already downloaded copy):
mkdir out
csaf download -3 -v -d out/ redhat.com
[!NOTE] In cases where data is signed with a GPG v3 signature, you can use the
-3
flag, which considers this still valid.An alternative is to use the
--policy-date
argument, and provide a manual policy date. Also see: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html.
By default, timestamps reported by the HTTP server will be applied to the downloaded files. When re-running, the
changes.csv
file will be used as a source to discover when a file was changed. If a file is already present and has
a newer modification timestamp in the changes.csv
file, then it will be downloaded again. Otherwise, it will be
skipped.
Using the --since
option, it is possible to provide a start timestamp, which will skip all changes reported before
this timestamp, and force all changes after this timestamp (independent of the file local file timestamp) to be
re-synced.
Using the --since-file
option, it is possible to automate the "since" value, by initially loading the "since" value
from a file, and storing it into a file at the end of a successful run. The timestamp stored will be the timestamp,
when the application started processing.
If both --since
and --since-file
are provided, then the "since file" will be used first, and the "since" value will
act as a fallback if the file is not present.
Instead of storing, it is also possible to send data to a remote instance (using the Vexination or Bombastic API).
csaf send -3 redhat.com http://localhost:8083
Of course, it is also possible to use the filesystem as a source:
csaf send -3 file:out/ http://localhost:8083
Using the crate csaf-walker
, this can also be used as a library:
use anyhow::Result;
use url::Url;
use csaf_walker::source::HttpSource;
use csaf_walker::walker::Walker;
use csaf_walker::retrieve::RetrievingVisitor;
use csaf_walker::validation::{ValidatedAdvisory, ValidationError, ValidationVisitor};
use walker_common::fetcher::Fetcher;
async fn walk() -> Result<()> {
let fetcher = Fetcher::new(Default::default()).await?;
let metadata = MetadataRetriever::new("redhat.com");
let source = HttpSource::new(metadata, fetcher, Default::default());
Walker::new(source.clone())
.walk(RetrievingVisitor::new(
source.clone(),
ValidationVisitor::new(
move |advisory: Result<ValidatedAdvisory, ValidationError>| async move {
log::info!("Found advisory: {advisory:?}");
Ok::<_, anyhow::Error>(())
},
)
))
.await?;
Ok(())
}