-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize the SWID field meaning #17
Comments
SWID files are XML, I am a fan of avoiding anything that isn't JSON whenever possible |
I want to resurrect this discussion. I'm trying to put an advisory into json format to see what I think of the schema, here is my current content The versions are going to be the sticking point I suspect. In my case it's not even that complex I'm asking the purl crew if they have suggestions disclaimer: I really like purl I'm open to any other suggestions if anyone has any Thanks in advance |
This issue and #28 are highly related IMO. It should just be combined into one issue to discuss. |
I don't have permission to close this issue, but I'll move my comment over to #28 |
@joshbressers want me close this in favor of continuing this discussion in #28? |
Yes please |
We need to decide on what the SWID field in the schema refers to.
One way to perform a query against the NVD is by using the tagId. Another way is probably by submitting the swid document itself. In most circumstances, the tagId would likely suffice. However, until the NVD actually releases details about how specifically the two types of SWID queries will work, we cannot be sure.
It would be valuable to reach out to David Waltermire at NIST for clarification before standardizing on the meaning.
The text was updated successfully, but these errors were encountered: