We have a request for tweaking two silver requirements involving crypto (specifically TLS) from the Zephyr project.  Some details below.  We don’t have any particular text change proposals yet.  If you have thoughts about this, please comment or reply.

Thanks.

--- David A. Wheeler

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

The silver badge requirements include the following:

* The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select "not applicable" (N/A). [crypto_certificate_verification]

* The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select "not applicable" (N/A).[crypto_verification_private]

However, we have some interesting comments from the Zephyr team (who are working on a silver badge).

They note that, “Zephyr is an embedded operating system, and applications would be bound to it, to go on a device to provide specific functions.”  Zephyr includes a code library that implements parts of TLS, but it’s not *used* unless an application (running on top of Zephyr) calls this TLS-related code.  In Zephyr, the application needs to perform the verification for the TLS certificates.

Of course, our real goal is that the "system as a whole" perform certificate validation.  From a security viewpoint, as long as it's *done* it's okay… never mind *where* it’s done.

If Zephyr only provides the certificate information to something else, then I think Zephyr needs to *clearly* document that the "other piece" *must* complete the job of certificate validation, hopefully with clear warnings.  That's been a problem with Python, for example - people thought it was doing certificate validation when it was *not*.  IIRC, these criteria were developed in part based on the experience with the Python libraries.  But if Zephyr makes it clear that it only does *part*, and does *NOT* do certificate validation, then I think we should allow that kind of library design.  Basically, we want *apps* to do the full certificate validation… but a library might not be doing the validation internally.

That said, we’ll need to be careful about any relaxing, including this case.  And if that’s just a terrible idea, I’d like to know that too.

If you are a native/fluent Spanish speaker who’d be willing to do some translations for the best practices badge site, please contact me!  If you know someone trustworthy who fits that bill, please convince them to contact me.  We have some strings translated, but many aren’t done.

Thanks!

--- David A. Wheeler

The OWASP Juice Shop project has (after some time) gotten a badge, and I plan to let their application stand:

  https://bestpractices.coreinfrastructure.org/projects/223

This is an odd project for the badging application, because it is an *intentionally* insecure webapp, designed for security training.  You could certainly argue that it shouldn’t have a badge *because* it has known vulnerabilities that won’t be fixed (since that is its purpose).  They certainly had to provide extra text for some of the project justifications J.

However, in *context* I think it’s fine.  The project badge entry, and the project page itself, make it immediately clear that this is an "intentionally insecure webapp” – and thus the security expectations are different for it.  I understand from the description that they intend to leave vulnerabilities that are supposed to be there, and fix vulnerabilities that are not supposed to be there (or document them so that they're supposed to be there too).  That means they still have to deal with vulnerability reports.. it’s just that what they count as a vulnerability is a little different J.

In a broad sense this project helps our mission too, because we're all trying to help develop more secure software.  It’s very unlikely someone would field this project for “real” work (since it’s known to be vulnerable), so these vulnerabilities are unlikely to cause serious harm.  Indeed, the presence of these vulnerabilities should help train people.  Most industries have a variety of test objects & training materials that help people meet various objectives, and I think this project fits into that category.

I didn’t want people to think I’d ignored this issue, though.  If you have very strong objections, please let me know.

--- David A. Wheeler

Hi

I finding issue while trying to update the https link in the CII badging for the following project

https://bestpractices.coreinfrastructure.org/en/projects/1702

Under the section,

The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.

when we provide a https link (or keep it blank) , the website throws an error

// Given an http: URL.

This is effecting the score of the CII badging for ONAP SO project, request to help resolving the issue.

Best regards

Seshu Kumar M

Huawei Technologies India Pvt, Ltd.

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

A big “CONGRATS!” to the German translators, who just completed translating the BadgeApp into German.  Thank you very much!

We now have complete translations for German (de), French (fr), Japanese (ja), Russian (ru), and Chinese (zh-CN), in addition to English (en).

I am very grateful to all of our amazing and dedicated translators.  THANK YOU.

Also: We have some early work on Spanish (es) that *just* started up.  If any native Spanish speakers would like to help, please let me know!!

--- David A. Wheeler

I think we should switch from Common Vulnerability Scoring System (CVSS) version 2.0 to version 3.0 in the criteria.  Any objections?

We don’t need to do this quickly, but I’d like it to be in the queue.  If people have opinions on how fast we should do this, I’d like to know.  I want to be cautious about anything that would affect existing badge-holders, but I do not think this will affect any current badge-holders.

Details below.

--- David A. Wheeler

=== DETAILS ===

A very few of our criteria mention CVSS.  For example, [dynamic_analysis_fixed] says this:

CRITERION: “All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.”

DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

CVSS version 3 has been around for a while, but we didn’t use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data.  However, NIST has since added support for version 3.  More info:

https://nvd.nist.gov/vuln-metrics/cvss

This should have little effect in practice.  CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2).  That said, if a project has that many vulnerabilities where the CVSS version change matters, that’s a problem in itself.

I recently made some tweaks that seem to really bump up website performance.

By adding some “preload” statements and a fragment cache, the front page on the “master” branch is getting webpagetest.org median performance figures of load time 0.730s, start render 0.567s.  That’s with a fast Internet connection assuming the site is all-the-way-up, but that’s also from a cold start (“never-seen-site before”).  Once a user visits the site at all, much of the “big stuff” (like CSS and JavaScript) is cached, which makes performance even better.  Details here:

https://www.webpagetest.org/result/180214_2T_c03d80608ab7e2531d71a448613cb023/

The site doesn’t need to be blazingly fast, we just don’t want people to turn away because of interminable page loads.  I think ideal is under 1s, and we must be under 2s response in such conditions.  We’re easily meeting those requirements.

In the longer term I intend to replace the font-awesome font icon file, which is huge & doesn’t play nicely with dyslexic fonts, with loading specific SVGs (or maybe SVG sprites).  That should reduce the cold start page load time even further.

--- David A. Wheeler

I’d like to say a quick “THANKS!” to Borja Martín, who has volunteered to work on a Spanish translation of the BadgeApp.  He has already begun; once it’s further along, I look forward to adding to the list of selectable options.

While I’m at it: a BIG THANK YOU to all of you who’ve helped translate, or in any way helped in developing the BadgeApp or its criteria.  Like any OSS project, it takes a lot of hands to make something successful, and I’m grateful to everyone.

--- David A. Wheeler

I just posted a very short & simple video titled

“Quick demo on how to start getting a CII Best Practices badge”

  https://www.youtube.com/watch?v=dhLYLpsvvc0

There’s nothing fancy here – I didn’t even create a title screen or put in intro music.  But some people find it easier to learn by watching others, and this a start towards that.

--- David A. Wheeler

FYI, I thought I’d share some of the things that are going on in the CII best practices badge project.  I think it’s especially important because much of this may be otherwise invisible to you.  Details below.

The number of participating projects, and the number of projects with passing badges, continue to grow.  You can see the statistics & graphs here:  https://bestpractices.coreinfrastructure.org/project_stats

Of course, the *real* goal is to get projects to improve themselves, & help them show users that they’re well-run.  I think the badging project continues to do that, and I hope you do too.

Thanks!

--- David A. Wheeler

============= DETAILS =======================

We’ve improved our ability to provide data to others.  We’ve supported a REST API and JSON from essentially the beginning, but we’ve significantly improved the API documentation and created a separate page for it <https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/api.md>.  In addition, we’ve added support for CORS, so that JavaScript clients on browsers can access some of our data.  This should make it easier to create dashboards, analysis tools, and other such things that base themselves on tool data.  We *want* people to build on data as long as it doesn’t interfere with personal privacy.   We still don’t have the API defined using OpenAPI/Swagger, but we’d love the help: <https://github.com/coreinfrastructure/best-practices-badge/issues/129>

The master branch has a new form for those who want to delete projects.  Project entries aren’t deleted often, but when they are, we currently don’t know why.  The new form requires that there be some text that explains *why* they are deleting a project entry.  I’m sure we can’t please everyone, but if there’s a common issue we can resolve in the future, this will at least help us find out.  This also makes it harder to accidentally delete a project, which has happened.  Some people habitually say “yes” to any “are you sure” message, so having a special form should reduce the risk of accidental deletion.  If someone really does want to delete their project entry, we will of course honor that, but I think this change will make things better for all.

A number of projects are making slow & steady progress towards getting silver & gold badges.  These are (intentionally) much harder levels to achieve; even the “passing” level is challenging for many projects. This is very encouraging for the long term.

The league/commonmark project (which implements a Markdown processor) has received a silver badge!!

More details here:

  https://bestpractices.coreinfrastructure.org/projects/126

As always, if there’s a problem please let us know.  However, on a brief spotcheck it looks fine.  For example, they expressly note that they exceed the 80% statement coverage requirement.

Because of the *kind* of project it is, it’s a little easier for them to meet the criteria than some others.  They don’t do anything with cryptography, and they don’t produce compiled executables, so some criteria are no-ops.  Even so, getting silver is not an easy thing!!

I know a number of projects are pursuing the silver badge, but relatively few have achieved it, so congrats!!

--- David A. Wheeler