Loosen constraints on SBOM/SPDX validation #572
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…and RelationshipType in SPDX files. This worked acceptably when we only ever had to validate SPDXs that we ourselves created (so we controlled the possible range of values). However, this requires us to know and enumerate every possible legal value for each enum, and it is vulnerable to breaking changes between minor versions of SPDX when deserializing. For example, when processing 3P SBOMs that were produced by other tools, we may encounter values that are legal by the SPDX spec, but not defined in our enums; this prevents us from parsing those files successfully. It also is a factor preventing us from flexibly handling all 2.x SPDX rather than just 2.2.1, which is a feature we require for redaction. This change models RelationshipType and ExternalRepositoryType as strings, rather than enums. That allows us to tolerate a wide range of possible input values without worrying if they align with our known range. The SBOM generation code still uses the enum types to enforce expected output values, simply converting to string at serialization time. The test case that asserted known values for RelationshipType has been removed since it is no longer relevant; an unrecognized RelationshipType should not cause failure anymore.
…XFile and SPDXPackage entities. It's not clear why we previously required them, but they are not required by the SPDX v2 spec nor by the NTIA minimum required elements for an SBOM. Loosening this constraint improves our ability to handle all 2.x SPDXs, including those produced by 3P tools that may not follow the same generation conventions as sbom-tool. In addition to removing the JsonRequired attribute from several fields, remove the test cases that check that the attribute is appropriately applied, since they are no longer relevant.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #572 +/- ##
=======================================
Coverage 58.41% 58.41%
=======================================
Files 250 250
Lines 7796 7796
Branches 916 916
=======================================
Hits 4554 4554
Misses 2826 2826
Partials 416 416 ☔ View full report in Codecov by Sentry. |
sfoslund
approved these changes
May 14, 2024
tarun06
pushed a commit
to tarun06/sbom-tool
that referenced
this pull request
Jul 21, 2024
* Previously, we have been using enums to model ExternalRepositoryType and RelationshipType in SPDX files. This worked acceptably when we only ever had to validate SPDXs that we ourselves created (so we controlled the possible range of values). However, this requires us to know and enumerate every possible legal value for each enum, and it is vulnerable to breaking changes between minor versions of SPDX when deserializing. For example, when processing 3P SBOMs that were produced by other tools, we may encounter values that are legal by the SPDX spec, but not defined in our enums; this prevents us from parsing those files successfully. It also is a factor preventing us from flexibly handling all 2.x SPDX rather than just 2.2.1, which is a feature we require for redaction. This change models RelationshipType and ExternalRepositoryType as strings, rather than enums. That allows us to tolerate a wide range of possible input values without worrying if they align with our known range. The SBOM generation code still uses the enum types to enforce expected output values, simply converting to string at serialization time. The test case that asserted known values for RelationshipType has been removed since it is no longer relevant; an unrecognized RelationshipType should not cause failure anymore. * We will no longer require license and copyright related fields on SPDXFile and SPDXPackage entities. It's not clear why we previously required them, but they are not required by the SPDX v2 spec nor by the NTIA minimum required elements for an SBOM. Loosening this constraint improves our ability to handle all 2.x SPDXs, including those produced by 3P tools that may not follow the same generation conventions as sbom-tool. In addition to removing the JsonRequired attribute from several fields, remove the test cases that check that the attribute is appropriately applied, since they are no longer relevant.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reduce the validation of input values and required fields that is performed on deserializing SBOM/SPDX files. Values previously deserialized as enums will now be deserialized as strings and non-essential attributes have had the JsonRequired attribute removed. These changes allow us to deserialize a wider range of 2.x SPDX files, instead of constraining us to 2.2.1 SPDX produced only by the sbom-tool.