Model-like bits shared between multiple contexts.
Database entity models, implemented via SeaORM.
The primary graph engine and API.
Importers capable of adding documents into the graph.
Ingestors/readers for various formats (SPDX, CSAF, CVE, OSV, etc, etc)
SeaORM migrations for the DDL.
The REST API server.
The server CLI tool trustd
Deployment-related (such as compose) files.
Arbitrary test-data.
Note Running an external PostgreSQL is no longer recommended for unit tests. You may wish to run one externally still for any other non-test-related activities.
Starting:
podman-compose -f etc/deploy/compose/compose.yaml upConnect to PSQL:
env PGPASSWORD=eggs psql -U postgres -d huevos -h localhost -p 5432Import data (also see: importer/README.md for more options):
env DB_USER=postgres DB_PASSWORD=eggs cargo run -p trustify-trustd -- importer csaf https://www.redhat.com
env DB_USER=postgres DB_PASSWORD=eggs cargo run -p trustify-trustd -- importer sbom https://access.redhat.com/security/data/sbom/beta/By default, authentication is enabled. It can be disabled using the flag --auth-disabled when running the server.
Also by default, there is no working authentication/authorization configuration. For development purposes, one can
use --devmode to use the Keycloak instance deployed with the compose deployment.
HTTP requests must provide the bearer token using the Authorization header. For that, a valid access token is
required. There are tutorials using curl on getting such a token. It is also possible the use the oidc client tool:
Installation:
cargo install oidc-cliThen, set up an initial client (needs to be done every time the client/keycloak instance if re-created):
oidc create confidential --name trusty --issuer http://localhost:8090/realms/chicken --client-id walker --client-secret ZVzq9AMOVUdMY1lSohpx1jI3aW56QDPSThen one can perform http request using HTTPie like this:
http localhost:8080/package/asdf/dependencies Authorization:$(oidc token trusty -b)A package exists or it does not. Represented by a pURL. No source-tracking required.
Rework to Package. VersionedPackage. QualifiedVersionedPackage. and VersionRangePackage for vulnerable references. Plus appropriate junction tables.
Probably need a fancy CPE table structure. sigh. Or two+ tables (cpe22, cpe23) and a Product table. Platonic form of a product may have 0+ CPEs/pURLs. Platonic form of a product may have 0+ known hashable artifacts.
A CVE exists or it does not. Represented by an identifier. No source-tracking required.
A CWE exists or it does not. Represented by an identifier. No source-tracking required.
An Advisory exists or it does not. Represented by a location/hash/identifier. Source tracked from an Advisory Source.
There is probably always an advisory from NVD for every CVE.
Something like GHSA, Red Hat VEX, etc. Maybe? Based on source URL? Regexp! Still unsure here.
They should just point us towards first order advisories to ingest. OSV just tells us to look elsewhere. They are helpers not nouns.
Package Range + Advisory + CVE.
QualifiedPackage + Advisory + CVE.
Both impl'd for pURL and CPE.
hashed document that claims things about stuff. All package/product relationships exist only within the context of an SBOM making the claim.
CPE (Product?) and/or pURLs described by the SBOM