- Jul 07, 2024
-
-
Jamie Tanna authored
As part of #530, we want to make it possible to consume SBOMs without a Repo Key, for instance if you've been provided an SBOM from a vendor, or you're scanning a container image, which doesn't _necessarily_ correspond directly to a repository. This performs a significant breakage, removing the Repo Key fields from the `sboms` table, and instead requiring that the metadata be instead stored in the `component_metadata` table and JOIN'd on the `component_name` column. This is a significant breaking change, so we mark this as a breaking change, as well as bumping `compatible_since`. This also: - introduces a `path`, which provides a step towards #408 and better monorepo support - involves fixing /a lot/ of queries that made assumptions about Repo Keys - flags a number of places that will need to be improved in the future when we want to query for non-Repo Key results i.e. in advisories or other reports - make it optional in `component_metadata` - make it optional in `import sbom` - introduce a better UX for Repo Key validation now it's optional when importing - amending DB docs that reference the now-nonexistent `sboms.platform` (etc) - making sure we pass through `sql.NullString`'s underlying `String` to `table.Row`s, otherwise we receive i.e. `{Example true}` which isn't helpful - prioritise `component_metadata` over `owners` lookups, as the Component may have an owner but not a Repo Key (i.e. if it's vendor owned, or a Docker image) - introduce a helper for UPSERTing, as it requires we check the row is already there (or so I think, I aimed to avoid #549) Closes #530.
-
Jamie Tanna authored
As part of #530, we want to make it a much better experience for folks using SBOMs, by not requiring they present a Repo Key with their imports. As a step towards this, we can introduce the `component_name` column, which will soon become the primary identifier for a given SBOM, opposed to a Repo Key. To do this, we should attempt to auto-detect this from SBOM metadata where possible, and if not, fall back to the `basename(filename)`. This is not deemed a breaking change as we're adding a new required field to a datasource.
-
- Apr 18, 2024
-
-
Jamie Tanna authored
As it's a nicer interface than the three strings.
-
Jamie Tanna authored
To make it easier for follow-up changes in #530, as well as making it clearer the intent of the composable type, we should create a separate type for our `RepoKey`.
-
- Apr 08, 2024
-
-
Jamie Tanna authored
When importing SBOMs, we consume the Package URL (pURL) and take the parts of it that we want to keep, but then throw away the rest. Instead of doing this, we should make it available in the database, where it can then be retrieved and further processed. This allows us to take more complex pURLs like: pkg:rpm/redhat/xz-libs@5.2.4-4.el8_6?arch=x86_64&distro=redhat-8.6 pkg:deb/debian/login@1:4.8.1-1?arch=arm64 And then we're able to perform more complex processing on them. This is a breaking change due to the definition in https://dmd.tanna.dev/concepts/compatible-since/: > Introducing a required column, which doesn't have a default In which we've added the `package_url` field, so need to appropriately note that this is a breaking change. This also requires refactoring the parameter to `newSBOMDependenciesQuery` as it's no longer getting a full SBOM row, as we don't query the `package_url`. Closes #528.
-
- Nov 29, 2023
-
-
Jamie Tanna authored
As part of #223, we want to consume licensing information from SBOMs, if found. We've now introduced the `external_licenses` table, which will house this data, we need to consume it. We can update each SBOM parser and also pull out licensing information, if present. With this data, we can then insert it in bulk into the `external_licenses` table. This requires we introduce a new `License` domain model, which matches the schema for `external_licenses` and does _not_ match `depsdev_licenses` due to us not storing a `package_manager`. Although not many SBOMs - including those from Dependabot - include any licensing information, we can at least wire it in, so as and when we have the data made available, we can report on it. Closes #223.
-
- Nov 05, 2023
-
-
Jamie Tanna authored
Unfortunately this breaks when we perform parsing JSON files that (allegedly) contain control characters, so a short-term solution for this can be to duplicate the JSON and YAML parsers.
-
- Oct 29, 2023
-
-
Jamie Tanna authored
To allow partial interop with ORT as part of #206. Closes #227.
-
Jamie Tanna authored
To correctly support YAML, which we say we do, we should instead unmarshal as YAML, which allows either JSON or YAML documents to be parsed.
-
- Sep 19, 2023
-
-
Jamie Tanna authored
As noted in #180, SPDX SBOMs escape the character for us, which we can then decode. Closes #180
-
- Sep 10, 2023
-
-
Jamie Tanna authored
As part of #21, we can add support for the parsing of SBOMs on the command-line through a new `import sbom` subcommand. Because the SBOM may not reliably tell us where it's come from (platform/org/repo-wise) we can require this on the command-line. Although it'd be good to use github.com/anchore/syft for the managing of parsing types of SBOMs, it's unfortunately blocked by [0], and is a fairly heavyweight library due to other functionality within it, which would bloat the project. Instead we can perform a lightweight version of the `formats.Identify` functionality to produce a consistent way to expand supported types of SBOMs. To start with, we can add support for SPDX-2.3 SBOMs. [0]: https://github.com/anchore/syft/issues/2112
-