Date   
"Why CII best practices gold badges are important":

David Wheeler
 

All - I thought you might like to know that I recently posted a blog
post titled "Why CII best practices gold badges are important":
https://www.linuxfoundation.org/blog/2020/06/why-cii-best-practices-gold-badges-are-important/

It's on the Linux Foundation's blog, so hopefully at least some others
will notice. The post emphasizes advantages of badges, including the
gold level.

People here already know this info, I think, but I thought you'd like
to know about efforts to let *others* know.

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation

Re: The Linux kernel has earned a gold badge!

Kate Stewart
 

Excellent news!   Kudo's to Greg and the other contributors to making this happen!


On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote:
All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
 https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation



Re: The Linux kernel has earned a gold badge!

Georg Link
 

This is fantastic news!
Congratulations to the Linux Kernel.

Thanks for highlighting this achievement.

Georg


On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote:
All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
 https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation





--
Georg Link, PhD
(he/him)

The Linux kernel has earned a gold badge!

David Wheeler
 

All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation

Should the badge app switch to a different translation management system (from translation.io)?

David Wheeler
 

Georg Link has proposed that we switch from the translation.io translation management system to a different system (in particular, Weblate). If you have thoughts on such a potential change, or information that could help in that decision, please add that information to this issue:

https://github.com/coreinfrastructure/best-practices-badge/issues/1430

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 2020-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 dates2020-04-292020-05-30
Total Projects31183171
In Progress Projects 25%+12331249
In Progress Projects 50%+10221034
In Progress Projects 75%+834844
In Progress Projects 90%+632639
Passing Projects434440
Passing Projects, 25%+ to Silver153157
Passing Projects, 50%+ to Silver106109
Passing Projects, 75%+ to Silver6869
Passing Projects, 90%+ to Silver3031
Silver Projects1515
Silver Projects, 25%+ to Gold106109
Silver Projects, 50%+ to Gold2525
Silver Projects, 75%+ to Gold1010
Silver Projects, 90%+ to Gold66
Gold Projects34

Here are the projects that first achieved a Passing badge in 2020-05:

  1. sonic-mgmt at 2020-05-01 23:55:10 UTC
  2. go-credentials at 2020-05-15 02:32:49 UTC
  3. worcs at 2020-05-19 15:03:07 UTC
  4. libBLS at 2020-05-23 15:24:41 UTC
  5. StackStorm at 2020-05-23 22:08:10 UTC
  6. googleAnalyticsR at 2020-05-28 10:02:28 UTC
  7. Meshroom at 2020-05-30 21:07:06 UTC
  8. PowerShellForGitHub at 2020-05-30 22:55:40 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: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

David Wheeler
 

Wow, unanimous agreement is rare! Thank you everyone for your comments.

While we’re changing this text, I propose that we make a few more tweaks:
- I checked, and GitLab-hosted project repos have the same protections. I confirmed this by viewing the Inkscape repo at https://gitlab.com/inkscape/inkscape . GitHub is a great service, but where possible I want to *not* imply that people must lock into any specific services.
- I think the text about static sites should be tweaked so that if headers are added/removed later it’ll still make sense, and also just to shorten it.
securityheaders.io is now a redirect to securityheaders.com (it seems to be otherwise the same). As always, we mention this service as an easy way to get useful information (“such as”), we don’t mandate its use.

So here’s one more tweak, turning this “details” text:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."

Into this:

"Note that GitHub and GitLab are known to meet this. Sites such as https://securityheaders.com/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Fully static web sites with no ability to log in via the web pages could omit some hardening headers with less risk, but there's no reliable way to detect such sites, so we require these headers for both the project home page and repository.”

The X-Frame-Options header’s mechanism can also be done via CSP. However, unlike X-XSS-Protection, it is basically universally supported (for DENY and SAMEORIGIN) and is still important in securityheaders.com. It even has an IETF RFC (RFC 7034, though note it’s just informational and not standards-track). More info here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options. So I think it’s reasonable to keep the X-Frame-Options header, at least for now, it seems to have far more support at this time.

This is also being tracked here:


--- David A. Wheeler

Re: [EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

Jason Dossett
 

This change makes perfect since.

Best,


Jason N. Dossett, Ph.D.
Research Staff Member
Institute for Defense Analyses
4850 Mark Center Drive, Alexandria, VA  22311
Phone:  703-578-2773
Email:   jdossett@...

-----Original Message-----
From: CII-badges@... <CII-badges@...> On Behalf Of David Wheeler
Sent: Tuesday, June 2, 2020 4:49 PM
To: CII-badges@...
Subject: [EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

*** This email originated outside of IDA. Please verify that you recognize the sender and know the content is safe before proceeding. ***


I propose that for the "hardened_sites" criterion we stop requiring the HTTP header X-XSS-Protection, and that we require CSP & explain why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values."
with these details: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not aged well. It's supposed to enable some heuristic protections. These protections are largely unnecessary in modern browsers (CSP is recommended instead), and it's increasingly obvious that this header will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the status of X-XSS-Protection, making it suddenly harder to see this header value for a site... and also providing additional evidence that X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on static sites, it's impractical to detect if a site is a static site or not, and we very much *do* want to encourage CSP use. So I propose keeping the main criterion unchanged, but changing these details:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."
To the following:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation

Re: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

Alton Blom
 

The change seems pragmatic, and makes sense to me.

On Wed, Jun 3, 2020 at 6:49 AM David Wheeler <dwheeler@...> wrote:
I propose that for the "hardened_sites" criterion we stop requiring
the HTTP header X-XSS-Protection, and that we require CSP & explain
why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if
accessible via the web), and download site (if separate) MUST include
key hardening headers with nonpermissive values."
with these details: "Note that GitHub is known to meet this. Sites
such as https://securityheaders.io/ can quickly check this. The key
hardening headers are: Content Security Policy (CSP), HTTP Strict
Transport Security (HSTS), X-Content-Type-Options (as "nosniff"),
X-Frame-Options, and X-XSS-Protection. Static web sites with no
ability to log in via the web pages may omit the CSP and
X-XSS-Protection HTTP hardening headers, because in that situation
those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not
aged well. It's supposed to enable some heuristic protections. These
protections are largely unnecessary in modern browsers (CSP is
recommended instead), and it's increasingly obvious that this header
will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the
status of X-XSS-Protection, making it suddenly harder to see this
header value for a site... and also providing additional evidence that
X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on
static sites, it's impractical to detect if a site is a static site or
not, and we very much *do* want to encourage CSP use. So I propose
keeping the main criterion unchanged, but changing these details:

> "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."

To the following:

> "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."

--- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation



Re: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

Dan Kohn
 

I endorse this change.
--
Dan Kohn <dan@...+1-415-233-1000
General Manager, LF Public Health, lfph.io
dankohn.com or book on my calendar: dankohn.com/c



On Tue, Jun 2, 2020 8:49 PM, David Wheeler dwheeler@... wrote:

I propose that for the "hardened_sites" criterion we stop requiring

the HTTP header X-XSS-Protection, and that we require CSP & explain

why.


Here's the background.


The Linux kernel is failing to meet the "hardened sites" criterion:

https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site


The reason is that those sites' HTTP headers do not include something like this:

X-XSS-Protection: 1


The criterion main text is: "The project website, repository (if

accessible via the web), and download site (if separate) MUST include

key hardening headers with nonpermissive values."

with these details: "Note that GitHub is known to meet this. Sites

such as https://securityheaders.io/ can quickly check this. The key

hardening headers are: Content Security Policy (CSP), HTTP Strict

Transport Security (HSTS), X-Content-Type-Options (as "nosniff"),

X-Frame-Options, and X-XSS-Protection. Static web sites with no

ability to log in via the web pages may omit the CSP and

X-XSS-Protection HTTP hardening headers, because in that situation

those headers are less effective."


This issue with the Linux kernel is discussed here:

https://github.com/coreinfrastructure/best-practices-badge/issues/1253


There are two problems. The first is that X-XSS-Protection has not

aged well. It's supposed to enable some heuristic protections. These

protections are largely unnecessary in modern browsers (CSP is

recommended instead), and it's increasingly obvious that this header

will never be standardized. Firefox won't add it, Edge has retired it.

Perhaps most importantly, securityheaders.io doesn't even *report* the

status of X-XSS-Protection, making it suddenly harder to see this

header value for a site... and also providing additional evidence that

X-XSS-Protection has outlived its purpose. Details here:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection


The second problem is that while CSP isn't really very helpful on

static sites, it's impractical to detect if a site is a static site or

not, and we very much *do* want to encourage CSP use. So I propose

keeping the main criterion unchanged, but changing these details:


> "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."


To the following:


> "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."


--- David A. Wheeler

Director of Open Source Supply Chain Security, The Linux Foundation




Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

David Wheeler
 

I propose that for the "hardened_sites" criterion we stop requiring
the HTTP header X-XSS-Protection, and that we require CSP & explain
why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if
accessible via the web), and download site (if separate) MUST include
key hardening headers with nonpermissive values."
with these details: "Note that GitHub is known to meet this. Sites
such as https://securityheaders.io/ can quickly check this. The key
hardening headers are: Content Security Policy (CSP), HTTP Strict
Transport Security (HSTS), X-Content-Type-Options (as "nosniff"),
X-Frame-Options, and X-XSS-Protection. Static web sites with no
ability to log in via the web pages may omit the CSP and
X-XSS-Protection HTTP hardening headers, because in that situation
those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not
aged well. It's supposed to enable some heuristic protections. These
protections are largely unnecessary in modern browsers (CSP is
recommended instead), and it's increasingly obvious that this header
will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the
status of X-XSS-Protection, making it suddenly harder to see this
header value for a site... and also providing additional evidence that
X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on
static sites, it's impractical to detect if a site is a static site or
not, and we very much *do* want to encourage CSP use. So I propose
keeping the main criterion unchanged, but changing these details:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."
To the following:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2020-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 dates2020-03-302020-04-29
Total Projects30443118
Projects 25%+11971233
Projects 50%+9931022
Projects 75%+808834
Projects 90%+615632
Projects passing421434

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

  1. github.io at 2020-04-01 18:52:36 UTC
  2. microservices-starter-kotlin at 2020-04-05 12:19:44 UTC
  3. microservices-starter-java at 2020-04-05 12:36:08 UTC
  4. api-router-go at 2020-04-07 02:48:20 UTC
  5. Hyperledger Caliper at 2020-04-08 16:53:48 UTC
  6. bain at 2020-04-11 11:08:04 UTC
  7. MapMaid at 2020-04-12 17:41:20 UTC
  8. HttpMaid at 2020-04-12 18:17:48 UTC
  9. QuantumMaid at 2020-04-12 18:49:27 UTC
  10. vector at 2020-04-15 04:28:41 UTC
  11. libcacard at 2020-04-20 05:54:20 UTC
  12. gemrb at 2020-04-23 09:18:41 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 2020-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 dates2020-02-282020-03-30
Total Projects29793044
Projects 25%+11691197
Projects 50%+967993
Projects 75%+788808
Projects 90%+600615
Projects passing413421

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

  1. go-malscraper at 2020-03-07 13:46:14 UTC
  2. Workcraft at 2020-03-11 14:14:54 UTC
  3. xgen at 2020-03-15 07:48:59 UTC
  4. dbparser at 2020-03-23 06:47:09 UTC
  5. Service Mesh Interface specification at 2020-03-23 18:33:41 UTC
  6. zenodo-upload at 2020-03-25 13:34:46 UTC
  7. Crypto++ at 2020-03-25 19:57:57 UTC
  8. git-cola at 2020-03-26 09:47: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!

I now work at the Linux Foundation!

David Wheeler
 

All: As of today, I am a full-time employee of the Linux Foundation. My official title is "Director, Open Source Supply Chain Security". Basically, I'm going to working full-time on various efforts to improve the security of open source software.

This doesn't affect my role on the badging projecct. However, if you want to contact me directly by email about best practices, then please use my new email address:
  dwheeler AT linuxfoundation DOT org

Thank you very much!

--- 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 2020-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 dates2020-01-302020-02-28
Total Projects29082979
Projects 25%+11391169
Projects 50%+944967
Projects 75%+769788
Projects 90%+583600
Projects passing404413

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

  1. ElasticsearchDSL at 2020-02-04 10:11:11 UTC
  2. httpretty at 2020-02-08 12:37:04 UTC
  3. luaunit at 2020-02-08 15:58:58 UTC
  4. xenon at 2020-02-10 14:57:19 UTC
  5. temper at 2020-02-19 22:44:47 UTC
  6. wwo at 2020-02-21 11:49:35 UTC
  7. rook at 2020-02-21 22:24:12 UTC
  8. glewlwyd at 2020-02-22 00:49:37 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!

More on spam countering efforts

David A. Wheeler
 

FYI, we have implemented some simple spam countering mechanisms on the best practices badge application.

Most trivially, whenever someone tries to create a project badge entry, they now see this:
Please tell us about your free/libre/open source software (FLOSS) project. This MUST be a FLOSS project; nothing else is permitted. Do NOT add an unrelated site to try to improve a site's search engine optimization (SEO). This spamming is forbidden because it harms users, and it will not help SEO anyway (all hyperlinks are marked with ugc and nofollow).
We've also made some changes because we've noticed that so far all spam attempts so far use "local" accounts:
* After creating a local account, we intentionally delay activation emails by 5 minutes. We have our mailer do this, so we don't have to worry about maintaining a job service just to do this.
* After activating a local account, we intentionally delay any login to the account for 1 hour, and explain that it's an anti-spam measure.

For local users these changes are mildly annoying, sorry about that, but it should be acceptable while discouraging some spammers. Our understanding is that many spammers are trying to add their junk to as many sites as possible, so little roadblocks should make the badge site less enticing. Obviously it's possible to work around this, the goal is to make it not worth it. We'll continue to remove spam, too.

--- 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 2020-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 dates2019-12-302020-01-30
Total Projects28522908
Projects 25%+11141139
Projects 50%+924944
Projects 75%+748769
Projects 90%+562583
Projects passing389404

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

  1. Choria.io at 2020-01-04 20:53:40 UTC
  2. KWasm at 2020-01-05 03:12:57 UTC
  3. milvus at 2020-01-07 10:22:53 UTC
  4. platformlabeler-plugin at 2020-01-07 22:36:34 UTC
  5. Meshery at 2020-01-08 16:33:10 UTC
  6. hammurabi at 2020-01-16 13:29:50 UTC
  7. e3-core at 2020-01-18 19:53:50 UTC
  8. batect at 2020-01-19 02:38:05 UTC
  9. pastebin.run at 2020-01-19 13:32:18 UTC
  10. warp at 2020-01-19 17:21:43 UTC
  11. prometheus-swarm-discovery at 2020-01-22 01:05:29 UTC
  12. stdgpu at 2020-01-25 13:01:35 UTC
  13. thanos at 2020-01-27 21:07:27 UTC
  14. php-legal-licenses at 2020-01-29 22:26:46 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: Need some advice addressing "unfixable" publicly known vulnerabilities

David A. Wheeler
 

Kevin Wall:

Most Software Compositional Analysis tools / services (e.g., OWASP Dependency Check, BlackDuck, SourceClear, etc.) also flag ESAPI as being vulnerable to CVE-2019-17571 because it uses log4j 1.2.17. However, the ESAPI development team has examined this CVE and the ESAPI source code and do not believe that this CVE is exploitable in the manner that ESAPI is using it because we do not use the affected vulnerable class nor any log4j 1.x class that invokes the vulnerable class. ...
Our problem is that because many Software Composition Analysis (SCA) tools and services now flag ESAPI as being vulnerable to CVE-2019-1757.
For the *badging* application this shouldn't be a big problem. I believe the criteria always talk about "exploitable" vulnerabilities of certain kinds as being unacceptable, not just vulnerabilities. (I think "vulnerability" always implies "exploitable" anyway, but saying things that way makes it clear.) Ignoring the distinction between vulnerabilities *in* the code & vulnerabilities in the code dependencies, let's look at criterion "static_analysis_fixed" as an example:
All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
Notice that this criterion only focus on *exploitable* vulnerabilities. If a tool (like a static analysis tool) finds a purported vulnerability, but it's not actually exploitable, that does *NOT* count as a true (exploitable) vulnerability. Nor should it. No tool is a substitute for thinking; tools are good at warning people about *possible* problems.

Even though we believe strongly that ESAPI's use of log4j 1 does not expose our users to this vulnerability, that belief--even if released as some official statement (which we are considering) is unlikely to help all that much. For some more details about some of these concerns, please see https://groups.google.com/a/owasp.org/forum/#!topic/esapi-project-users/XxKBjj3HuSw. (And yes, I know I forgot to erase the SMTP headers of the original poster's email resulting in his privacy not being not maintained; I've already apologized to him.)
So as ESAPI developers, what are our options here? I could write-up an official security bulletin and describe how we've analyzed the CVE in question and don't believe it is exploitable the way that ESAPI uses it as well as suggesting how to use alternatives such as SLF4J with either log4j 2 or logback, etc. We could build a "kill switch" that could be set in the ESAPI.properties file which would flat out disallow ESAPI to use log4j 1.x (discussed in the Google Groups URL above). But I'm not sure any of those would be useful or helpful to the masses which is why I am coming to my security conscious comrades and hoping that one of you will think of something that I haven't. We do plan on addressing this in our next release notes and as you can see, have already mentioned it in our Google Groups ESAPI Users list.
You should *definitely* do an official write-up. Publicly explain why it's *not* a problem in your case. I understand your skepticism, but it's still the right thing to do.

Looking at it from the other direction, it's perfectly reasonable for the SCA tools to flag ESAPI as vulnerable as long as they lack any other evidence. You need to provide the SCA suppliers with evidence that this should be squelched.

What probably needs to happen, long-term, is for there to be a standard way to report that "no, we're not vulnerable in this case". Then the SCA vendors can use that information in their tool. Here's a rough idea that I've thought about for 5 seconds (so no guarantees this is a *good* idea): There should be a standard directory name like "not-vulnerabilities". Its contents are files with the vulnerability id with a file format extension , e.g., CVE-2019-17571.md for a markdown file. That file includes a justification of WHY the default configuration (at least) is not vulnerable to that CVE, which may include inherited CVEs.


--- David A. Wheeler

Re: Need some advice addressing "unfixable" publicly known vulnerabilities

Hanno Böck
 

Hi,

Unfortunately I don't have a really good answer for your problem, but I
thought it might be interesting that I looked into a very similar issue
lately, which is bundled jquery.

Plenty of applications bundle either jquery 1 or jquery 2, including
major applications like wordpress. They are unsupported, but jquery 3
introduces breaking changes and thus updates aren't easy, if you have a
vast plugin ecosystem like wordpress then it becomes almost impossible.

There are a couple of obscure CVEs in these versions that from my lay
understanding matter only in very specific circumstances. But they are
there and tools may flag them. I'm actually developing a security tool
myself that is somewhat affected by this (freewvs, optional -3
parameter [1]), where I don't really know how to handle this best.

An easy way out would be if jquery would provide security-only-updates
for their old branches, but they don't want to do that [2] and also it
seems one of the issues can't be fixed without breaking things.


[1] https://freewvs.schokokeks.org/
[2] https://github.com/jquery/jquery/issues/4559
--
Hanno Böck
https://hboeck.de/

Need some advice addressing "unfixable" publicly known vulnerabilities

Kevin W. Wall
 

CII Badging community,

I just updated the ESAPI project on the CII Badges site to account for a newly discovered CVE. Specifically, I added this verbiage:

Most Software Compositional Analysis tools / services (e.g., OWASP Dependency Check, BlackDuck, SourceClear, etc.) also flag ESAPI as being vulnerable to CVE-2019-17571 because it uses log4j 1.2.17. However, the ESAPI development team has examined this CVE and the ESAPI source code and do not believe that this CVE is exploitable in the manner that ESAPI is using it because we do not use the affected vulnerable class nor any log4j 1.x class that invokes the vulnerable class. We have deprecated the use of log4j 1.x in ESAPI and changed the default logger to JUL, but we are unable to remove this dependency without potentially breaking client code. Therefore we intend to follow our ESAPI deprecation policy and keep this dependency (even though it is past end-of-support) until either 2 years or until the next ESAPI major release (which would be ESAPI 3.0). We do not fell this is an issue because SLF4J is also supported and can be used to provide similar functionality.

However, we are in a bit of a pickle really. The latest release, as well as all previous releases of ESAPI, used log4j 1.x as the default logger. As explained above, while we have recently made changes to deprecate this and replaced it with java.util.logging (JUL) as the default, there are thousands of clients out there who are still using ESAPI with log4j 1.x which unfortunately means it would not be prudent to break client applications by completely removing log4j 1 support. (We can also support log4j 2.x via SLF4J, which we also support but making a switch from log4j 1 to log4j 2 is not trivial and thus may not be an option for many of our users.)

Our problem is that because many Software Composition Analysis (SCA) tools and services now flag ESAPI as being vulnerable to CVE-2019-1757. Even though we believe strongly that ESAPI's use of log4j 1 does not expose our users to this vulnerability, that belief--even if released as some official statement (which we are considering) is unlikely to help all that much. For some more details about some of these concerns, please see https://groups.google.com/a/owasp.org/forum/#!topic/esapi-project-users/XxKBjj3HuSw. (And yes, I know I forgot to erase the SMTP headers of the original poster's email resulting in his privacy not being not maintained; I've already apologized to him.)

Anyhow, my concern--because I have observed it first-hand within my company--is that companies will no longer permit their projects to continue using ESAPI and migrate to something else, which is all well and good when their ESAPI dependencies are few and suitable replacements exist. (I even describe potential replacements here: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F) But for some things in ESAPI there are not ready made replacements (e.g., ESAPI Validators, ESAPI safe logging) and for many others, their ESAPI use is extensive so migrating to something else would be expensive.

So I am looking for suggestions of what I can do to relieve the fears about "Using Components with Known Vulnerabilities" when it comes to ESAPI. The SCA subscription services carry a lot of weight within companies and the FUD factor often takes over especially when they are spending big bucks on those SCA services. I've seen it first-hand.

The dilemma we have is we can't (well, won't; it is simply not good policy if you are an SDK provider) just immediately remove support for a potentially / presumably vulnerable dependency when that will break applications of potentially thousands of clients. (And in an ironic an eat-your-own dogfood sort of way, ESAPI logging is an integral core component of ESAPI so you are using it whatever other ESAPI component / feature you are using.)

So as ESAPI developers, what are our options here? I could write-up an official security bulletin and describe how we've analyzed the CVE in question and don't believe it is exploitable the way that ESAPI uses it as well as suggesting how to use alternatives such as SLF4J with either log4j 2 or logback, etc. We could build a "kill switch" that could be set in the ESAPI.properties file which would flat out disallow ESAPI to use log4j 1.x (discussed in the Google Groups URL above). But I'm not sure any of those would be useful or helpful to the masses which is why I am coming to my security conscious comrades and hoping that one of you will think of something that I haven't. We do plan on addressing this in our next release notes and as you can see, have already mentioned it in our Google Groups ESAPI Users list.

So if you have some ideas, please let me hear them.

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