Date   
CII Best Practices badge application not affected by EU GDPR "like" button issues

David A. Wheeler
 

The Court of Justice of the European Union (ECJ) has ruled that online websites that embed a Facebook "Like" button are responsible for the data they send to Facebook and are liable for the same penalties under EU data protection laws. There are many reports about this, e.g.:
https://www.theregister.co.uk/2019/07/29/eu_gdpr_facebook_like_button/
https://techcrunch.com/2019/07/29/europes-top-court-sharpens-guidance-for-sites-using-leaky-social-plug-ins/
https://www.cnet.com/news/websites-using-facebook-like-button-liable-for-data-europes-top-court-decides/
https://www.bloomberg.com/news/articles/2019-07-29/facebook-s-like-button-makes-websites-liable-top-eu-court-rules
https://www.theverge.com/2019/7/29/8934924/facebook-like-buttons-court-justice-eu-ruling-privacy-data-protection-tracking
https://www.zdnet.com/article/eu-court-of-justice-ruling-may-spell-the-death-of-social-like-and-share-buttons/

While it's true that the CII Best Practices badge application has "share" buttons (e.g., see the bottom of https://bestpractices.coreinfrastructure.org/en ), to my knowledge the CII badge website is *not* affected by this ruling. I explain why (in detail) below. Basically, instead of using the dangerous "Like" buttons, we use "Responsible Social Share Links" ... that means that users can see our web pages (even the ones with share buttons) without having that fact automatically reported to some social media site. Social media sites only receive information when the user specifically chooses to do this. We also don't send our information on "who accessed what" to anyone or accept payment to act on that information.

If there's an error or any other kind of security/privacy issue, please let us know so we can fix it. We've made serious attempts to counter exactly these kinds of problems, but we're human and it's possible we've missed something. We want our site to be secure & to respect the privacy of others.

Thanks!

--- David A. Wheeler


=== DETAILS ===

The "like" button that Facebook recommends that people use transfers personal data automatically when a non-Facebook page loads. That approach means that a user's visiting of that non-Facebook page is immediately revealed to Facebook without the user's knowledge or consent.

However, the "share" button we implemented in the CII Best Practices badge site has *never* worked that way. One of our requirements ( https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/requirements.md ) is to "Protect users and their privacy. In particular, we MUST comply with the EU General Data Protection Regulation (GDPR). Don't expose user email addresses, and don't expose user activities to unrelated sites (including social media sites) without that user's consent." As a result, we *never* accepted privacy-destroying constructs such as pages that transclude third party artifacts. We explain how we do this in https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md#Confidentiality . In particular, here's how we handle this:

"We do have links to social media sites (e.g., from the home page), but we do this in a privacy-respecting manner. It would be easy to use techniques like embedding images from external (third party) social media sites, but we intentionally do not do that, because that would expose to an external unrelated site what our users are doing without their knowledge. We instead use the approach described in "Responsible Social Share Links" by Jonathan Suh (March 26, 2015) https://jonsuh.com/blog/social-share-links/#use-share-urls , specifically using share URLs. In this approach, if a user does not press the link, the social media site never receives any information. Instead, a social media site only receives information when the user takes a direct action to request it (e.g., a click), and that site only receives information from the specific user who requested it."

This is part of a more general approach to supporting privacy. That same security section also notes that, "We directly serve all our assets ourselves, including JavaScipt, images, and fonts. Since we serve them ourselves, and never serve information via external third parties, external sites never receive any request from a user that might impact that user's privacy. This is enforced by our CSP policy.... We do not use any web analytics service that uses tracking codes or external assets. We log and store logs using only services we control or have a direct partnership with." Our CONTRIBUTING.md page (which provides instructions on contributions) says, "Avoid mechanisms that could be used for tracking where possible (we do need to verify people are logged in for some operations), and ensure that third parties can't use interactions for tracking."

We also ensure that the site's main functionality (displaying and editing project & user data) works even when JavaScript is disabled. From a security and privacy point-of-view, automatically running arbitrary code provided by all sites is more dangerous (due to malicious code, fingerprinting, and so on). Our site works better with JavaScript, but we ensure (and test) that the main parts work without JavaScript so that users can choose to enhance their security and privacy (by disabling JavaScript) if they desire to do so. This isn't possible to do for all web applications, but it's certainly possible for many web applications including ours.

If you see a remaining security / privacy issue, please let us know. For details on vulnerability reporting, please see:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/CONTRIBUTING.md

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-07.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-06-292019-07-30
Total Projects24412516
Projects 25%+927961
Projects 50%+765795
Projects 75%+612639
Projects passing316328

Here are the projects that first achieved a passing badge in 2019-07:

  1. openvdb at 2019-07-06 00:54:01 UTC
  2. cyborg at 2019-07-08 21:51:54 UTC
  3. Passbolt at 2019-07-09 16:29:39 UTC
  4. uber-poet at 2019-07-15 23:10:16 UTC
  5. mockolo at 2019-07-16 21:22:37 UTC
  6. Lite Byte Capsule at 2019-07-21 14:34:51 UTC
  7. classicdb_bot at 2019-07-23 22:30:03 UTC
  8. OpenColorIO at 2019-07-24 07:41:52 UTC
  9. volcano at 2019-07-26 12:49:16 UTC
  10. dockerserver at 2019-07-27 15:22:56 UTC
  11. kubeedge at 2019-07-29 03:39:03 UTC
  12. libtorrent at 2019-07-30 06:32:38 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-06.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-05-302019-06-29
Total Projects23812441
Projects 25%+902927
Projects 50%+743765
Projects 75%+594612
Projects passing309316

Here are the projects that first achieved a passing badge in 2019-06:

  1. gomplate at 2019-06-01 13:24:49 UTC
  2. imageproxy at 2019-06-10 00:58:01 UTC
  3. MapMate at 2019-06-12 14:14:31 UTC
  4. HttpMate at 2019-06-12 17:46:07 UTC
  5. NACHO at 2019-06-18 11:46:42 UTC
  6. Gwion at 2019-06-20 16:43:00 UTC
  7. Yarhl at 2019-06-22 12:50:00 UTC
  8. kubeone at 2019-06-27 13:05:06 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

FYI: BadgeApp & omniauth vulnerability CVE-2015-9284 resolved by third-party fix

David A. Wheeler
 

All, FYI.

 

One component we use (omniauth) has a publicly-known vulnerability (CVE-2015-9284) that is still not fixed.  To deal with this, we’ve taken unusual steps to eliminate the vulnerability’s effect in the BadgeApp.  Below are the details, in case you want to know more.

 

--- David A. Wheeler

 

=====================================================

 

As you know, the best practices badge is implemented by the “BadgeApp”.  Various mechanisms warn us when there’s a publicly-known vulnerability in a component used by the BadgeApp (directly or indirectly), and we normally quickly update, test, and ship the update.

 

Unfortunately, we’ve had a complication.  One component we use is “omniauth”, which has vulnerability CVE-2015-9284.  Unfortunately, while they continue to discuss it, they have *NOT* fixed it, and this vulnerability has become publicly known.  What’s more, as you can tell by the CVE number this was reported back in *2015*.  I think it’s embarrassing that it’s still not fixed.

 

My patience is exhausted.  This is not a trivial exploit to pull off, but it’s a dangerous one: it allows an attacker to take over another’s account.  And since the omniauth developers have failed to fix it for 4 years, I don’t have high hopes that they will fix it soon.  There is a third-party fix named omniauth-rails_csrf_protection.  I’m always leary of third-party fixes, but I think it’s our best option.  I reviewed its code & it appears okay.  I’ve incorporated the third-party fix by locking our download to the commit cryptographic hash that I reviewed; the hash lock counters tricks like “the RubyGems version is different from the one on GitHub” and “we silently upgraded/switched to a malicious version.”  So among our options I think this is the best one, and I think I’ve mitigated the biggest risks of this option.  We may look more seriously at removing omniauth in the longer term (since security components should be responsive to security issues), but for the moment I want to immediately resolve the *known* problem.

 

For more detail see:

 

https://nvd.nist.gov/vuln/detail/CVE-2015-9284

https://github.com/cookpad/omniauth-rails_csrf_protection

https://github.com/coreinfrastructure/best-practices-badge/pull/1298

 

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-05.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-04-292019-05-30
Total Projects22962381
Projects 25%+862902
Projects 50%+709743
Projects 75%+565594
Projects passing285309

Here are the projects that first achieved a passing badge in 2019-05:

  1. Predator: an open source performance testing platform for APIs at 2019-05-06 09:30:58 UTC
  2. dice at 2019-05-08 15:44:52 UTC
  3. OpenImageIO at 2019-05-08 22:19:14 UTC
  4. ONAP AAI UI (sparky-fe) at 2019-05-09 13:14:21 UTC
  5. ONAP SDNC (SDN Controller) at 2019-05-09 18:40:52 UTC
  6. railroader at 2019-05-11 15:50:27 UTC
  7. Orekit at 2019-05-13 11:05:04 UTC
  8. vvp at 2019-05-13 21:44:17 UTC
  9. CLAMP (Closed Loop Automation Management Platform) at 2019-05-14 13:44:42 UTC
  10. pki-lint at 2019-05-14 20:34:09 UTC
  11. ONAP Champ at 2019-05-15 13:35:49 UTC
  12. bug at 2019-05-16 19:17:03 UTC
  13. kuberhealthy at 2019-05-16 20:30:19 UTC
  14. A review helper script for openQA at 2019-05-20 11:23:24 UTC
  15. ONAP Gizmo at 2019-05-20 15:39:08 UTC
  16. IN COMMON at 2019-05-21 11:26:50 UTC
  17. ONAP Virtual Infrastructure Deployment (VID) at 2019-05-22 12:32:34 UTC
  18. snakecase at 2019-05-25 14:38:17 UTC
  19. Lychee-Laravel at 2019-05-28 12:58:22 UTC
  20. ONAP SDC (Service Design and Creation) at 2019-05-29 11:41:22 UTC
  21. usecase-ui at 2019-05-30 12:52:36 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-03-302019-04-29
Total Projects22162296
Projects 25%+831862
Projects 50%+683709
Projects 75%+540565
Projects passing273285

Here are the projects that first achieved a passing badge in 2019-04:

  1. tpm2-tss at 2019-04-01 19:29:20 UTC
  2. vinyldns at 2019-04-03 02:01:25 UTC
  3. TySug at 2019-04-08 06:42:58 UTC
  4. cryptor at 2019-04-13 20:35:35 UTC
  5. PRoot at 2019-04-18 01:35:35 UTC
  6. OpenSwitch (OPX) at 2019-04-19 15:53:14 UTC
  7. java-html-sanitizer at 2019-04-20 19:43:45 UTC
  8. ONAP External API at 2019-04-23 08:58:41 UTC
  9. react-kentico-blog at 2019-04-25 14:46:02 UTC
  10. ONAP ESR (External System Register) at 2019-04-26 15:10:34 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-03.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-02-272019-03-30
Total Projects21702216
Projects 25%+811831
Projects 50%+664683
Projects 75%+527540
Projects passing263273

Here are the projects that first achieved a passing badge in 2019-03:

  1. scripts-common at 2019-03-03 01:10:16 UTC
  2. Yocto Project at 2019-03-06 18:29:56 UTC
  3. SPDX Tools at 2019-03-10 01:22:25 UTC
  4. prosody at 2019-03-14 21:19:56 UTC
  5. readme-inspector at 2019-03-15 21:23:57 UTC
  6. TiKV at 2019-03-19 18:02:58 UTC
  7. go-github at 2019-03-21 18:49:11 UTC
  8. Hyperledger Indy at 2019-03-21 20:26:32 UTC
  9. hexo-theme-next at 2019-03-23 16:45:49 UTC
  10. ONAP DCAE at 2019-03-26 20:19:47 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

CII Badge project - some recent URLs that discuss it

David A. Wheeler
 

If you’re curious about the current status of the badge project, I have a useful summary in the presentation “Core Infrastructure Initiative (CII) Best Practices Badge in 2019” (2019-03-14) - https://events.linuxfoundation.org/wp-content/uploads/2018/07/cii-bp-badge-2019-03.pdf . This was a presentation at the Linux Foundation's Open Source Leadership Summit 2019 in Half Moon Bay, CA.

 

The badging project was also mentioned in some other recent places:

* A Sample Security Assurance Case Pattern (2018) - https://www.ida.org/idamedia/Corporate/Files/Publications/IDA_Documents/ITSD/2019/P-9278.pdf – this discusses how to create secure software by applying an assurance case, and uses the Badge Application's assurance case as an example.

* FLOSS Weekly 522: Railroader - https://twit.tv/shows/floss-weekly/episodes/522) primarily discussed the [Railroader](https://railroader.org) project, but it also touched on the continued progress of the CII Best Practices badge.

 

If you know of other places where the badging project is discussed, let us know, and/or update the Wiki page here:

https://github.com/coreinfrastructure/best-practices-badge/wiki/Publicity

 

Thanks!!

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-02.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-01-302019-02-27
Total Projects20912170
Projects 25%+789811
Projects 50%+645664
Projects 75%+511527
Projects passing249263

Here are the projects that first achieved a passing badge in 2019-02:

  1. newspaper-server at 2019-02-03 15:34:04 UTC
  2. restgoose at 2019-02-05 15:57:57 UTC
  3. Awesome Framework at 2019-02-05 16:03:52 UTC
  4. trickster at 2019-02-12 02:05:14 UTC
  5. Jastacry at 2019-02-12 14:07:53 UTC
  6. jtools at 2019-02-16 02:58:49 UTC
  7. BlurWal at 2019-02-19 21:30:01 UTC
  8. TransmogrifAI at 2019-02-19 22:35:23 UTC
  9. Gitano at 2019-02-20 07:57:44 UTC
  10. NetSurf Browser at 2019-02-20 08:47:57 UTC
  11. js-data-structure at 2019-02-22 03:33:34 UTC
  12. drace at 2019-02-26 10:12:49 UTC
  13. LinuxTV at 2019-02-27 15:18:02 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

FYI: Rails upgrade for BadgeApp

David A. Wheeler
 

FYI: In our effort to keep the Best Practices Badge website running smoothly, we just upgraded from the Rails 5.1 to Rails 5.2 (specifically version 5.2.2).

 

If you notice a problem, please let us know!!

 

Rail 6 will come out April 30 of 2019; at that time, Rails 5.1 will stop receiving guaranteed security updates.  So we really needed to upgrade at some point, and it’d be safer to do that now.  This required a few subtle changes, which were resolved.

 

Everything seems to be fine (so far) on the upgraded system.  We have a decent automated test suite; the test suite did detect some problems with a “naïve” upgrade, but we corrected those problems before we even merged it into our initial-test tier (“master”).  If desperate we can revert the running version & switch to a backup database, but hopefully it will never come to THAT J.

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-01.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2018-12-302019-01-30
Total Projects20412091
Projects 25%+770789
Projects 50%+630645
Projects 75%+497511
Projects passing240249

Here are the projects that first achieved a passing badge in 2019-01:

  1. landscapeapp at 2019-01-03 18:58:37 UTC
  2. BioCor at 2019-01-12 15:24:23 UTC
  3. svg-autocrop at 2019-01-13 00:36:53 UTC
  4. ticketguardian-python at 2019-01-15 23:36:27 UTC
  5. skipper at 2019-01-16 13:36:35 UTC
  6. PENTESTON at 2019-01-17 13:00:05 UTC
  7. TensorFlow at 2019-01-18 23:32:59 UTC
  8. SmartCar Shield at 2019-01-19 16:05:54 UTC
  9. busdater at 2019-01-20 06:44:03 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Re: C++ static analysis tools for CII badge

David A. Wheeler
 

Daniel Heckhenberg:

> Daniel and David, you've both clarified the essential point: analysis tools detect errors or potentially error-prone code which only become identified vulnerabilities in larger contexts.  Most of the projects in the ASWF domain are used for making images, typically in environments that are not open to general network access or arbitrary inputs from untrusted users.  As far as I'm aware, there are no existing published vulnerabilities (e.g. CVSS scored examples) from these projects.  This is partly why our community seems to be struggling a little to know how to adhere to the spirit of the CII badging requirements.

Yes.  I hope it’s clear that if you don’t have any published vulnerabilities, fixing them takes zero time J.

> So... we can't map CVSS medium and high to any specific set of analysis checks or even particular coding errors.

Right.  Whether or not a particular coding error is a medium or high vulnerability is very dependent on the intended use of the component, not just the kind of error it is.

> But we'd still like to be able to provide some good-practice examples of specific analysis configurations for our projects to follow. 
> Looking at the curl example, and specifically the clang-tidy checks:
https://github.com/curl/curl/blob/52e27fe9c6421d36337c0b69df6ca2b3b2d72613/src/Makefile.am#L145
> This appears to be just running the default set of clang-tidy checks with a few globally disabled to avoid false positives.  Similarly, the lgtm config seems to be just the default.  These would be very easy to add for our projects.  Is this a reasonable setup to guide our community?

Yes, that’d be just fine.  In the criterion “static_analysis” we even list some similar tools as examples (e.g., SpotBugs, FindBugs, lintr, and goodpractice).

It’s really hard to give specific guidance for checks.  Different languages are often best handled by different tools.  There’s also always a trade-off of how far to configure checkers: if you turn them up too much & too quickly you get flooded by reports.  What you should do is set up at least one checker, and then slowly increase the rigor it enforces.  Adding more checkers over time, and gradually increasing their pickiness, is far more practical than trying to turn on everything at once (unless you’re a brand new project).  The static analysis criterion is focused on making sure you’ve at least started down that path; once you have *some* tools in place, it’s a lot easier to gradually increase what they check.

Criterion “static_analysis_common_vulnerabilities” SUGGESTs that at least one be used to look for common vulnerabilities.  But this is SUGGESTed, not a MUST or SHOULD; there are a long list of reasons that it might not worth be it for your project.

Let me know if you have other questions!

--- David A. Wheeler

Re: C++ static analysis tools for CII badge

Daniel Heckenberg
 

Thanks again for the very helpful replies!

Daniel and David, you've both clarified the essential point: analysis tools detect errors or potentially error-prone code which only become identified vulnerabilities in larger contexts.  Most of the projects in the ASWF domain are used for making images, typically in environments that are not open to general network access or arbitrary inputs from untrusted users.  As far as I'm aware, there are no existing published vulnerabilities (e.g. CVSS scored examples) from these projects.  This is partly why our community seems to be struggling a little to know how to adhere to the spirit of the CII badging requirements.

So... we can't map CVSS medium and high to any specific set of analysis checks or even particular coding errors.  But we'd still like to be able to provide some good-practice examples of specific analysis configurations for our projects to follow. 

Looking at the curl example, and specifically the clang-tidy checks:
https://github.com/curl/curl/blob/52e27fe9c6421d36337c0b69df6ca2b3b2d72613/src/Makefile.am#L145

This appears to be just running the default set of clang-tidy checks with a few globally disabled to avoid false positives.  Similarly, the lgtm config seems to be just the default.  These would be very easy to add for our projects.  Is this a reasonable setup to guide our community?

Thanks!
Daniel

Re: C++ static analysis tools for CII badge

David A. Wheeler
 

On Thu, 10 Jan 2019, Daniel Heckenberg wrote:
A very specific CII badge aspect is that detection and timely remedy of CVSS
v2 medium and high severity issues is required.  coverity seems to
have a report generator which performs this, but I haven't seen any
direct or automatic way to map other C/C++ analysis tool outputs to
CVSS scores.  How is this usually done?
Daniel Stenberg:
I don't know about "usually", but I can tell you how we do it in curl (which incidentally also matches what I see in several other C/C++ projects).
In the curl project we run several static code analyzers, fuzzers etc on the code *before release* and we fix the issues we find, meaning that whatever these tools find never typically cause any CVSS scores at all. We fix those problems before release.
The security flaws we do get reported, are thus typically found by others (or tests that runs outside of our CI infra) or by our own developers on released code. They're not issued automatically by anyone and they're received and dealt with by humans.
I think that is the usual case. Use tools & tests so potential problems can be found & fixed before release. Since they aren't in a release, those normally potential problems do not normally get CVSS scores. Nowadays people often make continuous changes to a git master branch, and then use various ways to release it (put in in a package manager distro, tag it, and/or merge it into a production branch).

If a vulnerability is found in a *released* version of the software, organizations like NIST typically do the CVSS scoring for you. You can also calculate the CVSS score yourself, the CVSS base score is easy to figure out. The reason the criteria use the CVSS score is to ensure that at least the *important* vulnerabilities get fixed relatively quickly once they are known publicly, to reduce the risk to people using that software.

One point that may not be obvious: tool findings are not necessarily vulnerabilities. Many tools are based on heuristics, and they do not "know" the larger environment & expectations.

Hope that helps!

--- David A. Wheeler

Re: C++ static analysis tools for CII badge

Daniel Stenberg
 

On Thu, 10 Jan 2019, Daniel Heckenberg wrote:

A very specific CII badge aspect is that detection and timely remedy of CVSS v2 medium and high severity issues is required.  coverity seems to have a report generator which performs this, but I haven't seen any direct or automatic way to map other C/C++ analysis tool outputs to CVSS scores.  How is this usually done?
I don't know about "usually", but I can tell you how we do it in curl (which incidentally also matches what I see in several other C/C++ projects).

In the curl project we run several static code analyzers, fuzzers etc on the code *before release* and we fix the issues we find, meaning that whatever these tools find never typically cause any CVSS scores at all. We fix those problems before release.

The security flaws we do get reported, are thus typically found by others (or tests that runs outside of our CI infra) or by our own developers on released code. They're not issued automatically by anyone and they're received and dealt with by humans.

--

/ daniel.haxx.se

Re: C++ static analysis tools for CII badge

Daniel Heckenberg
 

Thanks for the informative replies, Daniel and Kevin.

I'd also seen the current outage with coverity -- hopefully that is resolved soon.
lgtm looks appealing and may be suitable for our projects.  

A very specific CII badge aspect is that detection and timely remedy of CVSS v2 medium and high severity issues is required.  coverity seems to have a report generator which performs this, but I haven't seen any direct or automatic way to map other C/C++ analysis tool outputs to CVSS scores.  How is this usually done?

Thanks,
Daniel

Re: C++ static analysis tools for CII badge

Daniel Stenberg
 

On Wed, 9 Jan 2019, Daniel Heckenberg wrote:

Are there any existing resources that demonstrate an automated static analysis of C++ code for CII badge requirements?  I'm hoping for something like a specific set of clang-tidy checks that covers the CVSS v2 medium and high severity vulnerabilities.  
In the curl project (which is C, not C++) we run clang-tidy on every commit/PR using travis [1] (search for "tidy") and analyze it using lgtm [2]. That's pretty easy to setup.

It can be noted that coverity is in my experience the undisputed leader of the static code analyzers for C/C++ - but isn't free, they offer a gratis service to scan code as a service for open source but that's not suitable for on-every-commit runs and since a few days ago the service "unexpectedly ceased operations" so we'll have to see where that goes in the future... Would be a hard blow to open source everywhere if it goes away.

[1] = https://github.com/curl/curl/blob/master/.travis.yml
[2] = https://github.com/curl/curl/blob/master/.lgtm.yml

--

/ daniel.haxx.se

Re: C++ static analysis tools for CII badge

Kevin W. Wall
 

On Wed, Jan 9, 2019 at 3:24 PM Daniel Heckenberg
<@dheck> wrote:

Hello!

Are there any existing resources that demonstrate an automated static analysis
of C++ code for CII badge requirements? I'm hoping for something like a
specific set of clang-tidy checks that covers the CVSS v2 medium and high
severity vulnerabilities.

Background:
I'm the current chair of the TAC for the recently formed Academy Software Foundation
https://www.aswf.io/
We're hoping to assist our projects to achieve CII badges by providing
examples of static analysis for C++ projects that can be incorporated in
normal build processes, as well as our CI systems.
Daniel,

The DHS SWAMP (https://www.dhs.gov/science-and-technology/csd-swamp)
might have some things. I recall talking to Kevin Greene (BCC'd) at an
AppSec USA conference maybe 3 or 4 years ago and I seem to recall that
they had some stuff for C and C++. Not sure if / how well it supports
Continuous Integration though. (Also, I'm not sure that Kevin is still
at DHS, but if he is, perhaps he will reply to you.)

On the commercial side, there are things like Microfocus' Fortify,
which is a SAST tool that does a pretty good job identifying lots of
vulnerabilities in both C and C++. It's a mature product and I have
used it for some sizeable (5M LOC) C++ projects.

Hope that helps.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/ | Twitter:@KevinWWallNSA: All your crypto bit are belong to us.

C++ static analysis tools for CII badge

Daniel Heckenberg
 

Hello!

Are there any existing resources that demonstrate an automated static analysis of C++ code for CII badge requirements?  I'm hoping for something like a specific set of clang-tidy checks that covers the CVSS v2 medium and high severity vulnerabilities.  

Background:
I'm the current chair of the TAC for the recently formed Academy Software Foundation 
https://www.aswf.io/  
We're hoping to assist our projects to achieve CII badges by providing examples of static analysis for C++ projects that can be incorporated in normal build processes, as well as our CI systems.  

Thanks!
Daniel

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2018-12.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2018-11-292018-12-30
Total Projects19962041
Projects 25%+754770
Projects 50%+617630
Projects 75%+485497
Projects passing234240

Here are the projects that first achieved a passing badge in 2018-12:

  1. Gardener at 2018-12-07 06:50:43 UTC
  2. go-lachesis at 2018-12-19 07:53:32 UTC
  3. Zowe - OpenSource for z/OS at 2018-12-20 14:54:45 UTC
  4. vipster at 2018-12-20 17:17:57 UTC
  5. ONAP SO at 2018-12-27 13:21:13 UTC
  6. kangaru at 2018-12-29 18:59:18 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!