Hi Philippe, HI Yev Philippe, You are right about SWID. Yev, I may be biased over using CPEs and not using SWIDs. 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. 2. SWID are not available in the open. 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. * 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. 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. 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. 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. I may be wrong in my opinions but am open for learning more. Regards Uday Regards Uday On Tue, Aug 4, 2015 at 9:15 AM, Sai Uday Shankar Korlimarla < [email protected]> wrote: > Regards > Uday > > > -------- Original Message -------- > *Subject:* Fwd: Re: Proposed spec for external packages > *From:* Thomas T Gurney <[email protected]> > *Sent:* Tuesday, August 4, 2015, 09:14 > *To:* Sai Uday Shankar Korlimarla <[email protected]> > *CC:* > > > > > Date: 4. Aug 2015 08:34 > From: [email protected] > To: [email protected] > Cc: [email protected] > Subject: Re: Proposed spec for external packages > > On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn > <[email protected]> wrote: > > Here is the spec for the proposed EternalPackage element. While I touch on > usage in the beginning, I'll discuss some specific use cases in the context > of SpdxTools on the call. > > > https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing > > > Yev: > I guess you meant External and not Eternal.... > > I provided a few comments to your proposed spec in the doc at > > https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit# > <https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit> > > The gist of my feedback: > - SWID tags are a nice concept but look to me at best new and may be > emerging, and at worst an unknown quantity fraught with many issues: > - no open neutral registry (like a IANA); > - little or no known usage in the FOSS world and no known usage by > any Linux distro as far as I know; > - a de-jure standard backed primarily by commercial entities for > commercial licensing compliance, with a closed and pay-walled-garden > called tagvault.org; > - little general adoption that I could find beyond a few commercial > vendors of asset management tools and a few (albeit large) commercial > software vendors like Microsoft; > - and yet another new standard on top of another standard: based on > the NIST discussion draft you provided the ambition of SWID tags seems > to be a rehash on top CPEs. > > - Why limit the purpose to security? identification has a rather > general purpose. > > - Why limit an external id to CPE and SWID tags? There are several > other sources of (rather widely used) globally unique ID: > - Linux distros package name/version > - other package managers name/version such as npm, rubygems, pypi, maven, > etc > - repo or project names on hosting sites such as Github, Google Code > (RIP), Apache, Eclipse, Sourceforge and several others. > > All these should be supported and are IMHO far better and more widely > used that SWID tags. Hence my suggestion for something more inclusive > and generic. > > An interesting question is how you map these to one another: for > instance what is the corresponding Debian package for a Fedora RPM? > What would be the common id for the upstream of these two packages? > What is the corresponding CPE if any? > > -- > Cordially > Philippe Ombredanne > _______________________________________________ > Spdx mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx > >
_______________________________________________ Spdx mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx
