Hi Uday, On Tue, Aug 4, 2015 at 10:20 AM, Sai Uday Shankar Korlimarla < [email protected]> 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. > Agree. Also, see appendix A in NIST-8060 where CPE can be derived from SWID. see: http://csrc.nist.gov/publications/drafts/nistir-8060/nistir_8060_second_draft.pdf > 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"* > > http://www.security-database.com/detail.php?alert=CVE-2015-5605 > > 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 <http://csrc.nist.gov/publications/drafts/nistir-8060/nistir_8060_second_draft.pdf> (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. Kate
_______________________________________________ Spdx mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx
