Skip to content
Snippets Groups Projects
  1. Jul 07, 2024
    • Jamie Tanna's avatar
      feat(sbom)!: remove the requirement for a Repo Key · 71b685f9
      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.
      71b685f9
    • Jamie Tanna's avatar
      feat(sbom): add a `component_name` field · 751be5e0
      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.
      751be5e0
  2. Apr 18, 2024
  3. Apr 08, 2024
    • Jamie Tanna's avatar
      feat(sbom)!: add `package_url` on imports · ccb812f4
      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.
      v0.92.0
      ccb812f4
  4. Nov 29, 2023
    • Jamie Tanna's avatar
      Consume licensing data from SBOMs, if present · a97561c4
      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.
      a97561c4
  5. Nov 05, 2023
    • Jamie Tanna's avatar
      Use separate parsers for SPDX · dbd46a98
      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.
      dbd46a98
  6. Oct 29, 2023
  7. Sep 19, 2023
  8. Sep 10, 2023
    • Jamie Tanna's avatar
      Add support for importing SPDX-2.3 SBOMs · 2f0fd190
      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
      2f0fd190
Loading