RE: [EXT] Reviving an Old Discussion: Request for CWE: Improper Licensing (UNCLASSIFIED)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: [EXT] Reviving an Old Discussion: Request for CWE: Improper Licensing (UNCLASSIFIED)

Joe Jarzombek
Thanks Jon!  I agree.  You provide sound reasoning and relevant examples for how CWE could address licensing/regulatory/legal compliance issues.  This would certainly reinforce the use of CWE in Software Composition Analysis.

Regards,

   -Joe -

Joe Jarzombek, CSSLP 
Director for Government & Critical Infrastructure Programs
Email: [hidden email]  |  Mobile: 703 627-4644  |
https://www.synopsys.com/solutions/aerospace-defense.html


-----Original Message-----
From: Hood, Jonathan W CTR USARMY FUTURES COMMAND (USA) <[hidden email]>
Sent: Thursday, March 5, 2020 10:07 AM
To: CWE Research Discussion <[hidden email]>
Subject: [EXT] Reviving an Old Discussion: Request for CWE: Improper Licensing (UNCLASSIFIED)

CLASSIFICATION: UNCLASSIFIED

What's changed since last time this was brought up:
* CQEs are now incorporated into the CWEs.
* The release of CWE 4.0 includes hardware assurance and firmware.
* The growing fields of Origin and Composition Analysis do not map some types of findings to CWEs because they are not covered.

Question: Can we please revisit the justification for not including legal compliance as a CWE or set of CWEs in light of these changes?

Below is a summary of the changes that were requested and of specific examples that were discussed last time this came up. Regardless of if a general "regulatory violation" CWE is made or if specific CWEs are made (the following discussion is geared towards the later), I do understand the desire to set a line in the sand on the scope of CWEs.

General CWE (could be a category): Regulatory Issues

Specific CWEs: License Violation, Law/Regulation/Policy/Ordinance Violation, Invalid IP claims

Each of these CWEs affects the availability of an application and indicate a flaw in the supply chain/acquisition stage of the SDLC.

Example 1: License Violations: The software uses dependencies or incorporates resources in a way that violates licenses. This can be broken out into even more specific CWEs (eg: expired license, incompatible license, violation of license terms, overly-restrictive license)
Example 1.a: (incompatible license) using GPL software in a non-GPL-compliant software suite: compiling libavcodec (VLC) with --enable-gpl and including it as a library distributed with a closed-source proprietary product
Example 1.b: (expired license) Software relies on a commercially-licensed product, but the license for the dependent project has not been maintained or is invalid: software that resets the VMWare license every 15 days so that they can continue to use the demo without paying for the full license
Example 1.c: (violation of license terms) Software relies on a product that with license requirements that are not met: a tool implements dptfxtract from Intel, distributes it as a dependency, but does not retain the copyright notices of dptfxtract or provide information about it in their documentation
Example 1.d: (overly restrictive license) The software has a license or depends on licenses that are overly restrictive: Light++ copyright license (http://fiberbundle.net/doc/copyright.html), or any license that discriminates against a type of person (I respectfully refuse to link to examples of this here). NOTE: Please be careful on the wording of this one. This weakness does not (and I believe should not) differentiate or measure whether the author's discriminants are morally just. Most software licenses have some kinds of discriminants (eg: Light++ {no military}, OMNeT++ {Academic Public License}, CompCert {Academic, non-commercial}, “not Anish Kapoor” {you can only use if you're not associated with Anish Kapoor}), but protected-class and morally-repugnant discriminants in licenses do exist. I recommend keeping this one at a fairly high level.

Example 2: Legal Violation: Software violates laws, regulations, executive orders, and/or ordinances. This includes ITAR-restricted software, export controlled software, or using crypto in a prohibiting country (http://www.cryptolaw.org/).

Example 3: Invalid Intellectual Property Claim – The software uses patents, dependencies, or other software that is ineligible for the IP claim made. An example would be approving a new herald or insignia through The Institute of Heraldry for use as an application's logo, then marking it as copyrighted and proprietary rather than in the public domain.

Thanks!
Jon


CLASSIFICATION: UNCLASSIFIED