Re: Proposed spec for external packages

Sai Uday Shankar Korlimarla

Hi Kate,

Thanks a ton for the clarification. It definitely helps, I am sorry for this delayed response.

I have one more question/doubt though. In 2.2.1 Corpus Tags, What I infer is that either the distributor or software vendor produces the SWID tag. In the future, assuming SWIDs are prevalent, Are we considering SPDX tools to accommodate creation of SWID tags if a vendor does not do so?


On Tue, Aug 4, 2015 at 3:10 PM, Kate Stewart <kstewart@...> wrote:
Hi Uday,

On Tue, Aug 4, 2015 at 10:20 AM, Sai Uday Shankar Korlimarla <skorlimarla@...> wrote:
Hi Philippe, HI Yev 

Philippe, You are right about SWID.
Yev, I may be biased over using CPEs and not using SWIDs.

Proposal was to permit use of either.  It was not mandating that one or another needs be used.
Here are my points on SWID.

1. SWID looks nice to have for software asset management and identification. CPEs can do just the same job.

Also,  see appendix A in NIST-8060 where  CPE can be derived from SWID. 

2. SWID are not available in the open.

NIST-8060 is an emerging NIST standard, so are not present today, but if the standard is approved, they will be in the future.
I know that I currently can identify a minimum of 1902702 products by CPEs.

Instance: cpe:/a:google:chrome:43.0.2357.134 has CVE CVE-2015-5605. It is easy to perform cross-linked correlation from many sources as you pointed out. Here the below URL gives us "openSUSE-2015-513.nasl"

So we have "openSUSE-2015-513.nasl" "CVE-2015-5605"  and "cpe:/a:google:chrome:43.0.2357.134" all talking about one single product google chrome version 43.

I don't see how SWIDs will be able to help do this.

SWID's are the proposed standard to eventually replace CPEs in the infrastructure.
Adding the ability to reference to them as an external identifier in SPDX is a future proofing measure.    

3. If I consume SWID, unless I tie the SWID to a CPE, I will not be able to move forward and gain vulnerability information. I could just stick with CPEs then.

For your purposes,  use the CPEs.   see earlier comments about future proofing. 

4. Trusting a standard without paying $400 is going to be a bit difficult. Open standards are way better. I think it is easier to live with duplicates in CPE dictionary and still be able to accurately get CVE information using cross-linked information as philippe point out.

Completely agree CPE is what should be linked to today.  

From the NIST 8060 (which is open):
1532 At some point in the future, as SWID tags become widely used and available, SWID tags will be 
1533 able to supplant CPE names as the primary means of identifying software products and 
1534 correlating vulnerability reports with those products. Until that occurs, SWID tags need to 
1535 provide certain data values from which CPE names could be mechanically generated. These 
1536 generated CPE names can be used to populate the CPE dictionary and to allow for searching 
1537 repositories like the NVD. 

5. While ISO, Microsoft and Symantec may sound fancy, the real question is on how open is this tag information. If SWID is an open-tagging scheme, it would definitely be worth considering.

Its a standard that is in "public review" right now, from NIST.  

6. Anyone can read a CPE and know what it is and do not need a digital signature for integrity for that, i.e. CPEs are open and readable. SWIDs will contain information that is not consumable immediately. Either SWIDs are flawed or is duplication. As philippe points out, if SWIDs would be re-hash over CPE, it would definitely be worth consuming/exploring.

See Appendix A for the mapping. 

I may be wrong in my opinions but am open for learning more.

Hopefully the above clarifies.


Join to automatically receive all group messages.